We present to the community Aave Governance v3, the next iteration of the Aave decentralized governance to control the whole ecosystem: multi-chain native and minimizing voting cost.
The whole Aave ecosystem is controlled in a decentralized way by version 2 of the Aave governance smart contracts.
It works the following way:
- Addresses with AAVE proposition power can create proposals on an AaveGovernanceV2 Ethereum smart contract.
- AAVE holders or recipients of voting delegation participate by voting on the same AaveGovernanceV2 Ethereum smart contract.
- If a proposal fulfills the success thresholds (more than X Yes votes, and more than Y difference between Yes/No), it gets queued into a time-lock.
- After the delay on the timelock ends, the Ethereum governance contracts or 1) execute a payload (executable code) on Ethereum itself, OR 2) using the existing Aave cross-chain governance system, “forwards” the decision to a target network (e.g. Polygon) to a payload to be executed there.
Current architecture and flow on Aave Governance v2
While being a production-grade system, and covering the needs of one of the most active on-chain governances in the broad DeFi field (and blockchain in general), same as with all other Aave components, the strategy is to always identify points of improvement, and iterate over them.
Some aspects to improve around Governance v2 were:
Cost of voting. Simply too high. Aave/stkAAVE voting power is quite distributed with more than 150’000 holders of Aave and 20’000 of stkAAVE, with a lot of them holding small amounts.
Even when Ethereum gas price levels are relatively low (~20gwei), and depending on the ETH price, the cost of voting on a governance proposal is around $5. If the network is slightly congested, this can easily be multiplied by 3x, 5x, or 10x.
It is just not scalable for holders of small amounts of AAVE to pay even $5 for voting on 1 proposal.
- Important coupling between governance and tokens. For the governance to be able to “query” the voting power of an AAVE/stkAAVE holder, the tokens themselves need to record a history of balances, which makes transfers of AAVE/stkAAVE pretty expensive. This is accentuated by having proposition and voting power, which hints at too much need to weigh the features of the system versus the cost of introducing them.
So the question is, keeping the same or more level of decentralization, can the Aave Governance be improved? The answer is yes.
Proposal creation. Fundamentally, nothing major. Proposal creation happens on a governance smart contract on Ethereum and can only be done if the address has enough proposition power (balance and/or delegation).
The only difference is that now the governance will be payload-contract oriented: before creation, the proposer or somebody else will need to deploy and register in an Aave contract the payload/s smart contract with the logic to be executed if/when the proposal passes, in the network/s where the changes will be executed if the proposal passes. This will be common for both Ethereum and non-Ethereum networks, and the proposer will only need to pass on the creation stage the id of said payload/s, and on which network they are deployed.
Pre-voting delay. Almost the same as on v2: there will be a 1-day delay between proposal creation and the start of voting, with the “snapshot” of voting power to be taken just when that delay passes. For some technical reasons, on v3 this delay will not really always have the exact same duration, but it will mainly increase in the order of 1h difference.
Voting. We will expand on this later on, but this is the main difference between v2 and v3, in what affects governance participants: to vote, AAVE holders/delegators will not be doing it on Ethereum in the big majority of the cases, voting will happen in other networks like Polygon, Avalanche, Arbitrum or Optimism, of which initially we will recommend Polygon and Avalanche to start with. An important aspect is that for each proposal, voting will happen in only 1 network, not in multiple in parallel, but the proposer can choose where exactly to do it, depending on his preferences or other community decisions.
So proposal 201 could be voted on Avalanche, while proposal 202 could be on Polygon.
Execution. Technical differences apart, that will be explained later, the time-lock and execution phases of proposals will be exactly the same as before, and initially, any network on which the Aave ecosystem is present will be covered, including the ones not so possible right now, like Avalanche.
Extremely cheap to vote, DAO potentially makes voting completely free for participants. Even if highly dependent on the voting network of the proposal and its congestion, it we take a current example of gas prices on Polygon, the voting cost would be in the range of $0.05-$0.10. For reference, this is approximately 100 times cheaper than voting in the current Aave Governance v2.
Considering this low cost, and in order to take the voting UX experience and participation to the next level, we will propose for the DAO to cover the voting cost of all participants, by using the meta-transactions capabilities included in Governance v3. This seems potentially reasonable, as with a cost of 7.5 cents per vote, and 10’000 participants, the cost would be a total of $750, to pay for 10’000 on-chain votes!**
We are in contact with Gelato Network as an option for voting relaying.
Future proof. The modularity of the system and how components are agnostic from each other allows us to really improve it, whenever new opportunities or models pop up.
For example, it will be pretty straightforward to add new assets with voting power, like a different flavor of AAVE.
Another future option is to even expand to non-EVM networks if they fulfill the infrastructural requirements (bridging infrastructure, efficient and compatible storage-proofs over Ethereum state).
New voting assets from day 0. Apart from AAVE and stkAAVE, stkABPT and aAAVE (v3 Ethereum) will be supported at launch.
Other flavors of AAVE like those bridged to non-Ethereum networks will not be possible at the start, as the complexity is higher.
No more history snapshots of balance on AAVE/stkAAVE. The new voting system doesn’t require any historic balances of the voting assets like AAVE. In practice, this means that after the upgrade of the token’s smart contract to be included on the release of Aave Governance V3, transfers of AAVE & stkAAVE will become approximately 75% cheaper.
Permissionless automation under the hood. Aave Governance V3 will have some additional state transitions compared with V2, in addition to the well-known queue() and execute(). But both these and the new ones will be completely automated (and still fully permission-less) by using Chainlink Automation, on our new tool: Aave Robot.
During the last year, and probably only accelerating, the trend is for Ethereum to become the top blockchain security and settlement layer, with more and more “roll-up”-style technologies connecting to it.
Aave Governance V3 follows this approach too. Even if described as multi-chain, the most precise definition would be as Ethereum-anchored: all types of validations and access control live on smart contracts in Ethereum, aligned with the utility of the AAVE token being majorly on Ethereum at the moment.
So the responsibilities of the Ethereum smart contracts of V3 are:
- Validate that those proposal creators have enough AAVE proposition power.
- Whitelist Voting Portals, which represent other networks where voting happens and their voting strategies (which tokens are counted).
- Decide from which Ethereum block a “snapshot” will be taken to consider balances for voting.
- Enforce certain time duration and expiry requirements.
- Enforce “success” metrics: count of YES votes, vote differential.
- Manage queueing of proposals once voting was successful.
- Decide where to “forward” proposals once ready for execution: to other Ethereum smart contracts or different networks.
- Cancel capabilities via Guardian for malicious proposals.
In more technical terms, the Ethereum contracts of Aave Governance V3 could be defined as a controller (deciding how, where, and when proposals “move” to other components) and access control contract (deciding who can do certain actions like creation of proposals, or whitelisting all other components, like voting networks or voting strategies).
As everybody in the community knows, Aave is a really inclusive ecosystem, always one of the first protocols to support new networks and technologies expanding there. We have seen this for example with the v2 liquidity protocol, being the first DeFi player to expand to Polygon and Avalanche, Aave v3 expanding on launch to optimistic roll-ups like Arbitrum and Optimism, or even the first version of the Aave cross-chain governance, currently controlled the previously mentioned systems.
With regards to Aave Governance V3, this ethos is followed by what we denominate as Aave Voting Networks.
An Aave Voting Network is any blockchain network where the Aave Governance allows eligible governance voters (holders of voting assets or delegatees) to participate in voting, for a certain proposal.
An Aave Voting Machine is the smart contract deployed on each Voting Network that contains all the logic for validation and accounting of votes in proposals.
Voting Networks/Machines work the following way:
Voters don’t have a balance of voting assets of delegation on the Voting Network. The balance/delegations of for example AAVE stays on Ethereum.
Ethereum block hashes as the source of information for votes; storage proofs as the core mechanism for validation. For a certain proposal, and even on Governance v2, in practice, the system takes a “snapshot” of voting token balances/delegations at exactly 1 point in time: the Ethereum block just before the delay post-creations ends.
On Governance v3 this is exactly the same, but the (big) change is that the system 1) takes the block hash of Ethereum when proposal voting should start 2) forwards it to an Aave Voting Network 3) sets it as the main source of balances/delegation to validate against whenever an address submits a vote there.
Simplifying the technicalities, Ethereum block hashes contain the so-called state tree of the network, which in turn contains all the data of all the smart contracts existing on the Ethereum network at that exact block. Amongst those contracts, AAVE, stkAAVE, and other voting assets are present, and within them, the balances and delegations of all Ethereum addresses. So the system “has” all the data needed to verify if somebody has voting power to participate in a proposal.
On the other hand, Storage Proofs are a mechanism allowing to cryptographically proving that a piece of data is contained in a tree. In this case, they allow proving that a specific address has voting balance/delegation on the state tree of an Ethereum block. So what happens in practice when somebody votes is that the voter itself inputs how much balance of the voting asset/s he had at that Ethereum block (instead of the system reading it), together with a storage proof over the Ethereum block hash for that proposal. The voting Machine only takes care of cryptographically verifying the storage proof against the Ethereum block data, together with all extra validations (e.g. no double-voting) and accounting.
In summary, the Ethereum storage layout and underlying cryptography provide the perfect mechanism for voting power aggregation and proving.
The Voting Machine doesn’t deal with the proposal “success” validations. The Machine only cares about voting duration: simplifying, whenever the block hash of Ethereum is received, the voting starts and will remain open for a defined duration. Once that time period ends, voting is closed and YES/NO count is forwarded back to the Ethereum side of the Governance.
Full circle with Ethereum as an Aave Voting Network in case of emergency. Even if not expected and not optimal cost-wise, if a catastrophic scenario would not allow any other Voting Network to operate, Ethereum itself will have its own Voting Machine, allowing the whole system to mirror Aave Governance V2.
Execution of payloads is one of the components on which the changes only slightly improve the current Governance V2. The main differences with the execution stage of v2 are:
More cohesion of permissions, same granularity. Currently, the Aave governance has 2 types of proposals: Level 1 and 2, each one with its own success & vote requirements, as they hold permissions of the ecosystem with different criticality.
On Aave Governance v3, the system still keeps the same granularity of Levels, but in addition, it allows to have in the same proposal, payloads with different Levels, by understanding which is the maximum level within the set and enforcing it. This was not possible on V2, which caused cases like proposals 165/166 of the rescue mission to be voted separately, even if being conceptually part of the same project.
Pre-register payloads before creation. To make the rest of the system work better, now the payloads, apart from being deployed before proposal creation, need to be registered in the Payloads Controller.
This allows getting an identifier of each payload that the proposer needs to submit on the creation transaction in Ethereum.
But how exactly the whole flow of a governance proposal works on Aave Governance V3?
Step-by-step flow on Governance v3
An address (can be the proposer or anybody else) creates the proposal payload/s, containing the logic that will be executed if the proposal passes, and registers it into the Payloads Controller of the target network.
For example, if the proposal will list an asset on Aave v3 Avalanche, the payload will need to be deployed on Avalanche, and registered on the Payload Controller of Aave present there.
Important to highlight that this is a permissionless action, as by registering the payload, there is no obligation of creating any final governance proposal using it.
It is possible to deploy & register multiple payloads in multiple networks to be used on the same proposal.
When registering the payload on the Payload Controller of the target network, this will return a sequential identifier: 1 for the first payload registered, 2 next, and so on. This will be used on Ethereum to reference the payload to be executed on a proposal.
On Ethereum, the proposer with the required AAVE proposition power, creates the proposal by transacting with the core governance smart contract. The proposer will input in that transaction the payloads (and their networks) to execute, together with the Voting Network for the proposal.
After the delay period is over, the Aave Robot (more on this later) or any other Ethereum address will be able to activate the proposal. In practice, this means that the Ethereum block just before this action is taken as a “snapshot” of the Ethereum blockchain state, is to be sent to the Voting Network and used as a source of the voting power.
By using the Aave Cross-chain Infrastructure (more on this later), the information about the vote (Ethereum block hash mainly) gets forwarded to the Voting Network.
In parallel with step 5), on the Voting Network, a permissionless “settlement” of global data to be used for vote validation will need to be done, by the Aave Robot, or any other address: the Ethereum block hash, its state tree, and the state roots of the voting assets.
Voting starts on the Voting Network.
Everybody with voting power on Ethereum is able to vote on the Voting Network, via the Voting Machine smart contract.
After the voting period passes, the Aave Robot or any address can call a function on the Voting Machine to close the vote, not allowing anybody else to participate.
Voting results in the form of a count of Yes and No are sent to Ethereum, via the Aave Cross-chain Infrastructure.
Voting results arrive at the core governance contract on Ethereum, which after validating its success requirements, will queue them for execution.
Aave Robot or any other address will initiate the execution of the payloads.
This will send the payload to the corresponding Executor contract on Ethereum or any other compatible network (in this case, via Cross-chain Infrastructure), and start a time lock.
If the proposal is on a non-Ethereum network, the payload will be queued on the corresponding Payloads Controller.
Execution by Aave Robot or any other address, once the time-lock is finished.
Aave Governance V3 relies heavily on good cross-chain infrastructure, and during the development, we noticed that the existing cross-chain governance system v1, even if fully functional, could be heavily improved and generalized, so we created a new cross-chain communication layer for Aave: Aave Cross-chain Infrastructure.
As the new system is a project by itself, we will publish a separate document presenting all its details to the community during the following days, but in anticipation of that:
- Bi-directional communication. The Aave Governance V3 is by itself bi-directional, with for example initiation of proposal’s votes being Ethereum → Voting Network, while notification of voting results being Voting Network → Ethereum. The new Aave Cross-chain Infrastructure enables this, being direction-agnostic.
Multi-bridge. The bridging ecosystem has and is evolving really fast during the last year, but still, it is quite new technology and Aave should have complete control at least in the selection of underlying bridges and replacement if required.
The new system will add big flexibility and customization on which underlying (1 or more) bridges are authorized by Aave, with the possibility of defining consensus rules.
- Emergency escape. Without sacrificing decentralization, Cross-chain Infrastructure will include a newly designed mechanism to mitigate any potential lock-up caused by malicious underlying bridges.
Behind the scenes, we have been working on the automation of permissionless actions around the Aave ecosystem, specifically on those related to governance, for which it is completely natural to have decentralized infrastructure whose cost is covered directly by the Aave DAO.
Given that it is already proven technology (e.g. used on Aave Proof of Reserve) and coming from a long-term partner, we have chosen Chainlink Automation as the backbone of this project, which we call Aave Robot.
We will release more extensive specifications soon, but in the case of Aave Governance V3, Aave Robot will take care of all the actions of permissionless nature around the system, being:
- Activation of the vote on the Ethereum core governance. After the delay post-proposal creation (1 day), an address needs to trigger the “activation” of the vote, which implies sending the corresponding block hash from Ethereum to the chosen Voting Network.
- Settlement of data on Voting Network from block hash. To make available to the Voting Machine on the Voting Network the state roots of tokens and other smart contracts used for voting power validation.
- Close voting on Voting Network. Once the voting period finishes on the Voting Machine, an address needs to trigger the “closing” of the vote, which implies sending the results back to Ethereum.
- Execution of payloads. Same as with Governance v2.
- Cancel of proposal not fulfilling proposition power requirements. Aave Robot will monitor continuously if a proposer has enough proposition power during the proposal lifetime, and if not, cancel it.
- Voting from smart contracts (Gnosis Safe or other multi-sigs, protocols integrating the Aave governance). Voting from smart contracts on Ethereum will be entirely possible, but differently to the normal procedure of EOA addresses, voting will need to be done by calling an Ethereum smart contract, and the Aave Cross-chain Infrastructure will bridge the vote to the Voting Machine in the corresponding Voting Network.
AAVE/stkAAVE optimization. Currently, the smart contracts of the AAVE and stkAAVE tokens include the logic required for the proper functioning of Aave Governance v2, mainly the recording of historic snapshots of balance and delegations.
This will not be required anymore on Aave Governance V3, so part of the project is to upgrade these tokens, making all operations (e.g. transfer) way cheaper gas-wise.
- Meta-transactions focused. In order to be relayer-friendly, the smart contracts of Aave Governance V3 have been designed with actions-by-signature in mind (meta-transactions).
Aave Governance V3 is a system touching an important part of the smart contracts of the Aave ecosystem, so its activation if/when approved by the community consists of multiple steps, which will most probably be grouped together.
A summary of what needs to be done before having it fully functional in production is the following:
Discussion of the community on the forum and Snapshot vote to signal for the upgrade.
Audit of the codebase by the security providers of the community, Certora, and SigmaPrime. This will include the following items:
- Aave Governance V3 smart contracts.
- Aave Cross-chain Infrastructure
- Upgrade of AAVE/stkAAVE/stkABPT/aAAVE
Additionally, given its criticality for the whole ecosystem, we would like to request the community to engage in some extra security firms/researchers that BGD will evaluate and negotiate the budget with, even if the Aave DAO will cover the cost.
Once all security procedures are finished, BGD will deploy the necessary smart contracts.
Governance v2 proposal to activate the system, consisting of transferring all the permissions of the Aave ecosystem to V3.
We will keep publishing extra information and the codebase of the system in the following weeks. In the meantime, we appreciated all the feedback from the community!