Security Solutions for DAOs
Overview
We live in a new world where more and more DAOs are in control of a project. Ensuring that safe choices are made is a major challenge and DAOs have been exploring different approaches. According to current proposals, Compound would effectively outsource their security to a vendor who would take care of various security-related needs.
We believe that this approach is not the route to take. The chosen audit company would become a critical dependency for the protocol. The suggested solutions with their intransparent, quarterly, lump-sum payment for a mix of services do not focus on the most effective tools. Hence, we would like to suggest a process that can leverage the strength of the security community.
The main security challenge for a protocol like Compound is the growing complexity that needs to be taken into account with every change:
- Due to upgradability, Compound needs to ensure compatibility with previous versions. Failure to do so can have significant consequences.
- As cTokens are used in various other DeFi protocols, these integrations must not be affected by the proposed changes.
- While certain governance votes are being voted on, others are in development or under review. This creates complicated dependencies.
- As the Compound protocol grows and starts to consist of more contracts it must be ensured that all contracts still interact correctly. A current compound liquidation involves roughly ten contracts and roughly fifty calls between these contracts.
Overall, we conclude that such systems exhibit quadratic complexity growth. To tackle this, we aim for scalability. Furthermore, we believe that the security can best be ensured by a broad base of security providers. This prevents any form of vendor lock-in and conflicts of interest, while allowing to combine the strengths of different providers.
Suggested Process in a Nutshell
Our suggested process is as follows and acts on different stages of the DAO:
In detail our process has the following steps:
-
Early feedback during RFP stage with code reviewers adding security consideration paragraphs
- This often reduces review cycles and hence development costs, review costs and time-to-market as code reviewers can foresee likely issues
- Example: Security considerations for RFP 8: Balancer V2 liquidity as collateral | $25k
The RFP aims to allow Balancer V2 liquidity as collateral. Recent attacks against cream.finance have shown that repeated borrowing can create an extremely leveraged position. When reviewing the security, special care must be taken to ensure that the value of the liquidity tokens cannot be artificially inflated. This would cause the protocol to lose funds as the collateralization ratio is insufficient to compensate for the price change. An attacker could extract these protocol losses and hence retroactively finance the artificial inflation of the liquidity token values.
-
Perform thorough code review of newly developed code
- Thorough expert code review of to-be-deployed code is still the most effective tool available today.
- Code reviewers inform the developers about all shortcomings related to security, efficiency or design.
- During code review, code reviewers jointly contribute to an audit suite by encoding all successful attacks as well as attacks that are currently not possible but might work in the future.
-
Develop an audit suite
- Composed primarily of extensive tests executable against forked mainnet at any point in time, allowing to continuously evaluate the security of the protocol and new proposal
- The audit suite is open source under the same license as Compound Smart Contracts (BSD-3). It must be executable publicly without restriction by having suitable licenses in place for potentially proprietary components.
-
Leverage tool-based analysis where efficiently possible
- Program Verification Tools currently cannot show correctness for a protocol as complex as Compound.
- Use tools selectively with more complicated techniques to validate correct behavior of subsystems, e.g., formal verification, static analysis or fuzzing.
-
Perform the Proposal Verification
- Once the development has completed, the proposal is prepared on-chain.
- The extended test against forked mainnet of the audit suite allow anyone to verify the compatibility of the proposal. In particular they can check that the proposal does not break any integrations and is compatible with previous versions.
- As the proposal includes the concrete parameters chosen, these parameters can be verified as part of this step.
In contrasts to other suggested processes, we focus on prevention. While monitoring is certainly nice to have, Compound already has some monitoring and attacks often take place in one (large) transaction. Hence monitoring and alerting have limited effectiveness, especially considering the present timelocks.
Finding Suitable Code Reviewers
The biggest hurdle for code reviewers getting into a new complex system is the required initial investment to understand it. Fluctuation and internal availability of employees also require any review companies to constantly invest into training, which can reduce either quality in times of high demand.
To tackle these problems, we propose the following general solution:
-
Compound Governance votes in several code reviewers each year to onboard into auditing through a paid training phase.
-
Auditors apply to become wardens of Compound by providing:
- An example of how a code review for the Comptroller and the cToken would be performed, detailing methods and time required.
- The cost and amount of hours reserved for Compound per quarter, which are if accepted guaranteed to be paid by Compound.
- The expected compensation for the training phase.
-
On-boarding code reviewers can also greatly benefit from the existing audit suite which contains many relevant attack scenarios.
- Any time reserved for Compound not spent on reviewing code or RFPs is used to improve this audit suite.
-
Auditors who are selected by Governance and complete the training take shared ownership of the audit suite and collectively improve the coverage.
- Delivering good work in improving the Compound Audit Suite will likely be used to evaluate the quality of the auditor which aligns interests long-term by increasing the likelihood of being voted in again next year.
Benefits of the Audit Suite
- Auditors think of many cases, most of which are not exploitable currently. Putting them in the suite helps to test for this case going forward. It aggregates knowledge from multiple code reviews and companies.
- Expert know-how of the system and the possible attacks against it are captured for future auditors.
- With testing against forked mainnet it is possible to simulate the effects of all the currently open proposals independently as well as combined.
- The Audit Suite enforces the definition of explicit value ranges, making code reviews more effective and simplifying certain governance proposals which just update parameters within those ranges.
- It provides extremely good feedback for developers reducing review cycles and thereby financial and temporal overhead.
- Auditors will gain confidence in having audited the system holistically even when reviewing seemingly small changes.
- Tasks that needs to be performed repeatedly, such as the compatibility check with past versions, can be automated once and efficiently repeated.
- The suite ensures the correctness of on-chain proposals including correctly chosen parameters which are generally not part of the code review.
- Given its design the audit suite provides a decentralized and permissionless mechanism for community members to inspect the state of the protocol and to evaluate ongoing proposals.
Considering all these benefits, we believe that the audit suite can provide the necessary scalability by capturing a lot of the growing complexity. It requires an initial investment to build it up, but we consider it worthwhile.
Summary
Our suggestion incentivizes broad participation from small to large security companies. Thereby, it broadens the base of experts in Compound and leverages proven techniques. Using the audit suite, we can aggregate the knowledge and insights from multiple audits (instead of only relying on the last audit) and thereby tackle the growing complexity. We believe that this provides a viable long-term solution.
While even a single audit company chosen to shepherd the protocol could write such an audit suite, only by having multiple companies who rely on each other to have covered critical parts of the system enforces that a public, high-quality audit suite gets created. It also allows every security provider to play to their strengths when contributing. Lastly, it allows a decentralized verification of proposals by any community member.