Risk Assessment: Audits, Bug Bounties, and Economic Modeling

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

  1. No amount of audits, economic modeling, or bug bounties will guarantee the safety of any project.
  2. Each of these require time and money, in differing amounts.
  3. 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.
  4. Not all auditors will have the expertise to perform the best type of audits for Trustless. The options must be curated.

Security Audits

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

Bug Bounties

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:

Economic Modeling

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

  1. Determine how much time and resources are available, and what Trustless’ needs are.

  2. Choose potential services/solutions to use now and later.

  3. Contact those services to begin the risk assessment process, and/or begin developing solutions.

1 Like
  • Be kind to your fellow community members.
  • Does your reply improve the conversation?
  • Constructive criticism is welcome, but criticize ideas, not people.

For more, see our community guidelines. This panel will only appear for your first 2 posts.

Your Ideas are quite good. But in my opinion I’d say there’s no need for a third party audit, I mean the sole purpose of Trsutless is to trust no one only the code which the project was built on. Secondly, we’re already testing out the capabilities and capacity of the project through testnet and so far from my experience I haven’t seen or noticed any bugs. Great idea tho :+1:

This is an extremely useful summary of the options, thanks for laying them out @jaypow! Especially looking through the audit firm rankings. Also thank you for laying out the bug bounty platforms, the only one I have head of before is ImmuneFi

For next steps:

  1. Time and money are not available now, but will be if Trustless is successful at raising money.
  2. Once funds are in the door, Trustless should engage the top tier in each category
  3. Will be done once ready.