This topic is for a discussion about whether and how we should have Trustless reviewed by third parties for protocol security purposes. I will list some resources and suggestions below, but feel free to share your ideas in response.
A few important notes first
- No amount of audits, economic modeling, or bug bounties will guarantee the safety of any project.
- Each of these require time and money, in differing amounts.
- Not all of these have to be done before Trustless launches. While it is better to do them prior to launching, some could be done sooner and some later. Some details regarding future decisions could be delegated to the Trustless foundation and/or the DAO once the foundation treasury is able to support it.
- Not all auditors will have the expertise to perform the best type of audits for Trustless. The options must be curated.
Auditing services have varying reputations, limited availability, and different pricing. Screening for an auditing firm with a good reputation and relevant specialization is key. For example, Trail of Bits and OpenZeppelin are generally viewed with high esteem as far as security audits go (and come with hefty price tags + time commitments), whereas some others which are mentioned in the links below have a lesser reputation.
Lists of auditing services
Other relevant audit links
Generally speaking, bug bounties are used after a private security firm has audited a project. However, others may refer to bug bounty platforms as “crowdsourced auditors”, suggesting they are equal to the category of audits themselves. Their practicality depends on the projects’ goals. The projects themselves should decide what categories to reward, what the payout range will be, how long to keep the bug bounty running for, and what (if any) services they will use.
The benefit of these is that the turnaround time can be much faster when using bug bounty platforms compared to using private auditing services. For example, this earlier article mentioned that lead times for Code4rena can be as short as 48 hours. A pro or con, depending on the project’s perspective, is that there will be many public eyes on the code. I believe I read that Trustless is not planning to make the codebase open source until after the public launch, and I understand that this will have an impact on the decision to use bug bounties. Projects may also decide to have an ongoing bug bounty listed on their website, such as what zkSync has.
Some of the well-known bug bounty platforms for DeFi:
This is sometimes done in-house by team members or advisors, and sometimes can be performed by auditing firms. For example, Liquity had a market risk assessment performed by Gauntlet, as well as a separate research report performed by what seems to be an independent researcher.
Edit 9/14 - Adding a newcomer Chaos Labs to the economic modeling category. They perform agent and scenario based modeling to help with risk management and guide protocols through difficult market conditions. They claim to work with teams “across all sizes and stages” and have an impressive pedigree for their relatively short lifespan. They wrote a relevant deep dive on Uni v3 TWAP oracles.
There is some crossover between economic modeling and tokenomics, which will also involve the DAO.
General links of importance
Suggested next steps
Determine how much time and resources are available, and what Trustless’ needs are.
Choose potential services/solutions to use now and later.
Contact those services to begin the risk assessment process, and/or begin developing solutions.