TL;DR
We have released Aave Seatbelt, a governance proposal’s validation tool to increase the trust of AAVE voters on the validity of such proposals.
Aave governance, currently
The Aave governance system allows governing the Aave protocol: using AAVE tokens, community participants can create proposals that can be approved or declined by the rest of the community.
Proposals are commonly used to list new assets of Aave pools, alter parameters of listed assets, fund projects contributing to Aave, and, in general, anything that implies any kind of change in all the Aave systems. That said, a proposal can contain almost any arbitrary content that can be executed within the EVM.
While voting for or against a proposal is trivial, the proposal creation process needs a certain degree of expertise (understanding of the Aave systems) and can be error-prone. Technically, there is also some degree of “manual” labor involved, on-chain governance is in its early technological days, and more importantly, a proposal is a translation from an AIP (Aave Improvement Proposal) written in English, to an arbitrary set of transactions encoded and submitted to a smart contract.
So one core assurance on proposals is for voters to understand that it does what it says it does, and only what it says it does.
The problem
Unintended errors in the governance process can have severe ramifications, and while there are always people reviewing proposals, it still can happen that some mistake slips trough in the code review.
A proposal might be supposed to alter reserve X on an Aave pool, but instead alters reserve Y because of a simple copy/paste error. Another proposal might be trying to set the LTV (Loan-to-Value) of a reserve to 80% but instead sets it to 800% or 0.8%.
When looking a bit further there is also the possibility of someone disguising a heist in an otherwise reasonable proposal.
These kinds of issues and threats are not easily solvable or not completely solvable at all: there is no strict ruleset to determine if a proposal is erroneous. While an 800% configuration might be an error on DAI, it might be the desired rate for AMPL and so on. Therefore all we can do is add more lines of defense to manage the risk without reducing flexibility.
Aave Seatbelt as a solution
As a first step to increase transparency and giving more assurance to AAVE voters, from BGD we started a public reviewing process of newly created proposals which you can find here GitHub - bgd-labs/aave-proposals-reports
But even if we think they are really useful, our reports are human interpretations using expertise, and ideally, there should be a completely automated report generated every time a proposal gets created.
That is why we present today the Aave Seatbelt. Taking as base the Seatbelt tool by Uniswap and modifying it for the specialties of the Aave governance system, the Aave Seatbelt provides the following:
- It dramatically simplifies the review process for human reviewers, including voters, but also security reviewers like ourselves in BGD.
- It is a fully automated tool. Removing any dependency on for example our BGD reports being ready exactly when the proposal gets created.
How does it work?
In practice, Aave Seatbelt is a tool for executing and interpreting governance simulations: it forks Ethereum mainnet (where the Aave governance lives), it simulates the execution of a proposal, and finally generates a report containing human-readable information on what effects a proposal will have.
The generated report will contain:
- All the state changes were caused by the proposal execution.
- Events triggered.
- Compilation report of all contracts affected, to check for potential warnings.
- It runs Slither (static analysis tool) over all touched contracts to find potential issues.
Some of those checks are initially generic, but in addition, we also added extra “interpretations” for particularities of the Aave ecosystem. For example, when an Aave Pool contract is affected, we can automate a deeper interpretation of the effect, making it more human-readable.
Just some bored ghosts simulating proposals
Continuous integration in Github Actions will run once every hour to scan for new proposals to simulate, and re-simulating still pending proposals based on the current chain state. The results of these simulations are stored inside the reports directory on the repository.
What comes next?
The current seatbelt project covers a lot of ground, but there are still things that can be improved, namely:
- Integration of the Aave interface.
- Better state interpretation of state changes on proxy contracts.
- Simulation of cross-chain proposals (currently only the Ethereum Mainnet part is simulated).
- Use slither to diff storage layout on implementations.
Credits
Aave Seatbelt took as base the Uniswap Seatbelt and we have collaborated closely with Tenderly. So huge props to the work done by both teams 