TL;DR
Proposal for the development and introduction of Aave Governance V3, based on storage-proofs, rollup-optimised (Starknet), with free (or almost) voting and fully integrated with the new SnapshotX system by Snapshot Labs.
DISCLOSURE. This is a draft proposal to present the idea and gather feedback from the community, so several aspects should be analysed further.
Architectural changes from V2
V2
V3
-
AaveGovernanceCore. Replacement of the current AaveGovernanceV2 contract, lighter as it only handles communication with bridge and permissions.
-
Short and Long timelocks. Most probably un-changed from v2. They allow the queueing and execution of proposal’s payloads and they own the different permissions of the Aave ecosystem.
-
DecisionExecutor (SnapshotX). Handling the bridging of a proposal resolution from Starknet to Ethereum.
-
BalanceReader (SnapshotX). Smart contract handling the proposition/voting validations on the Starknet side, establishing how much proposition/voting weight the different assets have, same as the current GovernanceStrategy on Ethereum.
-
VotingContract (SnapshotX). Core component of the Starknet side of the protocol, it registers proposals, stores Merkle roots for them, and handles vote submissions and their validations via the BalanceReader.
-
VoteAuthenticator (SnapshotX). Smart contract validating user’s Ethereum signatures.
-
Snapshot. User interface and additional services facilitation user to create and vote on proposals.
Advantages compared with V2
-
Voting cost. Currently, voting on the Aave Governance on Ethereum is what can be considered as pretty expensive, in a range of $20-$200 depending on the network’s congestion. This is clearly affecting the on-chain voting turnout and becomes evident when comparing with the turnout on the Snapshot proposals.
On V3, voting will be free, with the Aave DAO settling a posteriori the transaction cost of all participants with the entity/s acting as relayers on the Snapshot system.
-
Voting experience. Same as on V1 and V2, V3 will allow voting without locking assets, just by having them in the wallet address when the proposal vote starts. Ideally, it will also unify the point on interaction with proposals via Snapshot, compared with the current fragmentation between Snapshot (off-chain) and on-chain votes.
Voting/proposition delegation introduced on V2 is retained.
-
Potential optimisation upgrade of all voting assets. Currently, both AAVE and stkAAVE have a mechanism of snapshots of voting/proposition powers which makes the operations over those assets pretty expensive. With the introduction of V3, the governance system will be self-sufficient to understand voting and proposition powers, removing the need of snapshots on the assets’ smart contracts, which brings additional gas savings on token transfers and reflecting these savings on all interactions in which AAVE and stkAAVE are involved in the ecosystem. Important to highlight that this is only applicable if the full censorship protection is not included, or when it will be removed.
Proposal flow
- Proposal is submitted via Snapshot, or directly to the VotingContract on Starknet.
- The proposal is linked with the Ethereum block hash of the creation’s moment. This will be enabled by Snapshot, running a service bridging block hashes continuously from Ethereum to Starknet, but permissionless, open to other entities to trigger the bridging.
- Same rules on proposition power on V2 apply for the proposal creation.
- The block hash of the proposal creation moment is the key component, as it is calculated by hashing together multiple block data, including the root of the state tree, which will be used for proposing/voting via storage proofs on Starknet.
- Proposal data is stored on the Voting contract on Starknet, storing the block hash, proposal id and any other metadata needed.
- Voting starts.
- Via the Snapshot user interface (or directly to the SnapshotX contracts), wallets with valid voting assets on Ethereum can submit their votes by sending the proposal id, vote type (YES/NO), voting balance (e.g. 10 AAVE) and a storage proof that will allow to verify that the signing wallet effectively held that voting balance at the moment when the vote started.
- For every vote, an accumulator of the voting type is increased.
- Vote ends.
- The system “forwards” to Ethereum the accumulators of YES and NO votes, that will allow the governance contract on Ethereum to decide if the vote passed or not, taking into account the different thresholds.
- If the vote passed, same as on V2, anybody can queue the proposal and later on execute it.
Snapshot/SnapshotX integration
As previously described, this idea of Aave V3 is built on top of the work of Snapshot Labs with SnapshotX.
The main points of integration are:
- Voting and proposing. Both will happen by signing messages on the Snapshot user interface, exactly as they do right now on off-chain proposals, without any gas cost. All the “heavy lifting” in terms of storage proof generations and relayers will be managed by Snapshot.
- Voting/proposing rules. Managed on the SnapshotX side (smart contracts), with Aave being able to customise the proposition/voting logic as it is currently on V2.
- Execution of proposals. SnapshotX will only forward to Ethereum the result of the voting on Starknet, so same as with V2, the final queueing/execution of proposals will happen on the Aave governance contracts on Ethereum.
It is important to highlight that the SnapshotX (smart contracts) system if fully decentralised, so there is no hard dependency on the off-chain running services of Snapshot.
More information about SnapshotX can be found here.
Misc aspects
Proposal delay
A proposal delay is the period of time from the creation of a proposal until it is open for voting. This is usually important because it allows voters to mobilise voting assets for then participate on the governance process.
Currently, on the Aave governance there is no voting delay set, even if the smart contracts has the capabilities for it. However, it was proposed in the past to set a delay of 2 days, but the high quorum requirements were not reached, even if there was clear off-chain consensus about it.
On the Aave V3 governance, it is possible to still keep the option of a proposal delay, managed (logic-wise) exactly the same as it would be currently on V2, just adapted to the SnapshotX proposition model.
Voting by smart contracts
At the current moment, there are multiple examples of smart contract systems holding Aave voting assets (AAVE, stkAAVE) on Ethereum, which participate on governance by doing smart-contract-to-smart-contract interactions.
This is a really important part of the ecosystem, which will probably grow in the future as more platforms integrate the Aave governance. So it is mandatory for a V3 to keep this feature, trying to be as much back-compatible as possible.
To achieve this, the easiest solution is to create an extra voting bridge which will work the following way:
- The smart contract A that wants to vote will trigger a voting transaction with the proposal id, vote type (YES/NO) and any other necessary information on a bridge smart contract on Ethereum.
- The vote will be forwarded to Starknet, and registered on the Starknet’s side.
- As the vote at this point is already “immutable” on the Starknet side, anyone can execute the vote by submitting a transaction with the storage proof showing that smart contract A had the voting assets valid for the proposal. Considering the low cost of transactions on Starknet, it should be straightforward for the DAO to compensate this last step, or even parties associated with the project behind smart contract A could take care.
It is important to highlight that delegation for voting will be kept as it is, opening another way for smart contracts to factually vote, just by delegating to an EOA (Externally Owned Account).
Full censorship protection
Currently and until the plan to decentralize the Starknet sequencers comes to fruition during 2022, theoretically (even if not likely) it is possible to have a scenario where governance participants try to vote on Starknet, but their transactions are not included.
Further analysis is needed, but a potential solution for this would be the following:
- When the vote ends on Starknet, apart for the YES/NO accumulators, include a Merkle Tree root (important to allow non-inclusion proofs) to be forward to the Ethereum governance smart contract.
- Once the previous voting outcome is on the Ethereum smart contract, open extra days of voting directly on Ethereum for everybody holding valid voting assets and who didn’t vote on the Starknet phase. Each vote should be verified on-chain with a non-inclusion proof on the tree of votes that happened on Starknet.
- After this extra direct-voting period ends, the proposal queuing and execution proceeds normally.
Multi-chain proposals
One of the main advantages of the current Snapshot system is the possibility to create voting strategies and the flexibility of including balances/delegation of different ERC20 assets (or other types) across multiple chains at the same time.
This allows in the case of the Aave Snapshot space to vote with AAVE from both Ethereum and Polygon at the same time, together with more assets like stkAAVE on Ethereum.
On the context on the proposed new architecture, the system is agnostic to the storage proofs used to Starknet, so theoretically it could be possible to forward multiple Merkle roots, one per network, being able this way to aggregate voting balances across chains on a point of time X.
Naturally, this would involve a bit more complexity, so it is probably a better idea to not introduce the feature in an initial iteration.
Next steps
- Get feedback on the idea by the Aave community.
- If the feedback is positive, create a working group and a budget for the project.
- Analyse more in detail the model, defining a precise architecture and migration strategy.
- Implementation of the system and security procedures.
Acknowledgements
Thanks for the discussions/contribution to the idea from @Andyko o, @Emilio and the Snapshot and Starkware teams.