A Detailed Explanation of the Decision-Making Principles of Aave Governance V2, the Leader in DeFi Lending
Why is the Aave Governance V2 decision-making system so efficient after processing 272 proposals over two years of activation?Original Title: Understanding Aave Governance V2: The Decision System Behind DeFi's Largest Lending Platform
Original Author: Callen
Translated by: Qianwen, ChainCatcher
Aave Development History
- Starting from ETH Lend in 2017, Aave has achieved significant growth in protocol usage and governance participation, becoming one of the largest protocols in DeFi, with $5.891 billion in deposits.
- With the deployment of Aave V2 and Aave V3, as well as the launch of Aave Governance V2, Aave has undergone multiple upgrades to its lending architecture.
- Aave Governance V2 introduces a fully decentralized governance system for the DAO, meaning the DAO no longer relies entirely on Aave's Genesis team to approve on-chain proposals.
- Aave Governance V2 introduces new governance features such as the separation of voting rights and proposal rights, voting strategies, multiple execution entities, and a community-elected multi-signature known as guardians.
- Aave Governance V2 consists of four core smart contracts: AaveGovernanceV2, Short Executor, Long Executor, and GovernanceStrategy. They are responsible for creating, voting on, and executing "Aave Improvement Proposals" (AIPs) on the Ethereum mainnet and other chains.
- The usage rate of Aave Governance V2 is very high, with 272 proposals submitted, driving significant changes in Aave, such as the successful deployment of Aave V3 on eight chains and the launch of GHO, Aave's decentralized stablecoin.
Introduction to Aave
Aave is the largest decentralized lending protocol and the third-largest DeFi protocol, with $5.891 billion in deposits across eight blockchains. Aave started as ETHLend during the initial token issuance frenzy in 2017, raising $16.2 million as a decentralized P2P lending platform in exchange for their LEND tokens. In 2018, ETHLend was rebranded to Aave, marking the protocol's transition from a P2P model to a liquidity pool model. In January 2020, Aave V1 was released, and a few months later, the token migrated from LEND to AAVE.
The liquidity pool model allows the pooling of depositors' tokens to provide instant liquidity to borrowers, who no longer need to wait for ideal counterparties as in the P2P model. This way, depositors can passively earn token yields from the interest paid by different borrowers over time.
As of 2023, with the release and deployment of Aave V2 and the recent Aave V3 across multiple blockchains, Aave has seen tremendous growth in usage and deposits.
In addition to upgrading Aave's lending architecture, we have also seen a comprehensive reform of Aave's governance system with the launch of Aave Governance V2, which is a fully decentralized on-chain governance system with updated functionalities.
With the launch of Aave Governance V2, the DAO has entered a new era of fully decentralized on-chain governance, and the new governance system has experienced significant activity since its launch; it has handled the creation of 272 proposals, including the launch of Aave V3, GHO (Aave's decentralized stablecoin), and the listing of new assets.
What is Aave Governance V2?
Aave Governance V2 is a collection of smart contracts whose parameters determine how the Aave protocol and Aave DAO operate. It was initially proposed by Marc Zeller and activated under AIP-4 in December 2020, introducing four key governance innovations for Aave:
Separation of voting rights and proposal rights: Aave/stkAAVE holders can choose to delegate only their proposal rights while retaining their voting rights; vice versa is also possible.
Voting strategies: Different forms of governance-approved Aave tokens can vote on proposals, for example, depositing aAAVE -- AAVE into the Aave market.
Multiple execution entities: Short-term and long-term execution entities allow for different voting requirements based on the significance of the proposed changes.
Guardians: This is a multi-signature elected by the community, which individuals can use to veto or cancel proposals with malicious code.
Aave Governance V2 is inspired by an authorized governance model that mimics representative democracy but is not enforced. These new features combine to provide Aave with a more inclusive, efficient, and powerful governance system.
However, it can be said that the most critical change in Aave Governance V2 is that anyone can submit and implement AIPs. This was not possible in Aave Governance V1 (the predecessor of V2).
Specifically, V2 bypasses step 4 of the V1 governance process, which only allowed the Aave Genesis team to submit AIPs as binding governance proposals. Now with V2, anyone with sufficient AAVE/stkAAVE** can submit and implement AIPs in a fully decentralized manner.
Both V1 and V2 have a similar initial phase in the proposal lifecycle, which is to propose amendments and discuss them with the community. However, step 3—Aave Request for Final Comments (ARFC)—is the final version of the proposal that seeks opinions from the DAO's risk service providers. Step 4 requires the community to vote on whether they are satisfied with the final amendments, and finally, step 5 approves these amendments on-chain using the formal Aave Improvement Proposal (AIP) of Aave Governance V2.
How It Works
Aave Governance V2 consists of four core smart contracts: AaveGovernanceV2, Short Executor, Long Executor, and GovernanceStrategy. These core smart contracts handle the AIP process from start to finish and provide three key functions:
Proposal creation: Any community member with sufficient proposal rights can create proposals under any subcategory of Aave policy. The policy that needs to be changed will determine the time, power, and community consensus required for voting.
Proposal voting: Once a proposal is live, AAVE/stkAAVE holders can vote on the proposal outcome using the YAE or NAE voting options.
Proposal execution: If a proposal is approved by token holders, it will enter a delay period (Timelock) so that users opposed to the changes can opt out of the system (e.g., exiting lending positions due to stricter risk controls). After the delay period ends, the proposal will enter a grace period, during which any Ethereum address can execute the proposal by calling the execution function in the short/long executor smart contracts, or in adverse cases, the guardians can veto/cancel the proposal.
Specifically, Aave Governance V2 handles the creation of AIPs and requires users to submit information indicating which executor will be used and what changes are desired for the protocol. It is also responsible for setting the length of the review period.
The Short Executor is used for minor changes to the protocol, meeting faster and more lenient consensus requirements, such as parameter changes, asset listings, etc.
The Long Executor is used for significant changes to the core codebase of the protocol that affect governance consensus and require a lengthy and extensive consensus process, such as changes to the AAVE token, V2 governance parameters, and itself.
The Governance Strategy handles the logic for measuring user proposals and voting rights. It also defines which tokens can be used for voting (i.e., AAVE and stkAAVE).
To further understand how these smart contracts interact, let’s look at the recent proposal by Llama to list LDO on Ethereum AAVE V3. Given that this proposal is for asset listing and does not involve critical governance consensus parameters, Llama used the Short Executor to submit all relevant information and list LDO through the Aave Governance V2 smart contracts.
At the same time, Aave Governance V2 read the consensus requirements from the Short Executor smart contract and cross-referenced them with the Governance Strategy to first determine how to calculate Llama's proposal rights and then confirm whether it exceeded the required threshold of 80,000 AAVE proposals. Given that Llama had sufficient voting rights, the proposal was successfully created and entered a 1-day review period.
After 3 days of voting, the Short Executor used the Governance Strategy to verify whether the requirements of 320,000 AAVE quorum and 80,000 AAVE vote margin were met. In this case, Llama successfully passed both parameters, receiving 459,700 AAVE approval votes and 0 opposition votes.
Then, the proposal entered a 1-day delay period, allowing users to respond to the changes before entering a 5-day grace period. During the 5-day grace period, users need to call the execution on the Short Executor to approve the changes on-chain. If no one executes the proposal before the grace period ends, the proposal will expire, and the changes will not be enacted. Finally, if the guardians find that the code is malicious, they can veto the proposal to protect the protocol.
Aave's Multichain Governance System
Given the continuous development of the multichain DeFi ecosystem, we continue to see more and more blockchains deploying DeFi protocols to attract new users and cater to fee-sensitive audiences. Aave has been at the forefront of the multichain movement, with its V3 product deployed across 8 chains. However, this also brings new challenges to governance, such as ensuring that token holders can still control cross-chain deployments in a non-fragmented and familiar manner.
Aave's cross-chain governance architecture is similar to other major protocols like Uniswap and Compound. In Aave's case, only the V3 deployments on Polygon, Arbitrum, and Optimism are directly controlled from the Ethereum mainnet through Aave's cross-chain governance bridge.
Each supported V3 deployment outside the Ethereum mainnet requires a bridging receiver and a local executor contract on its chain (Arbitrum and Optimism require an additional L2BridgeExecutor contract to ensure L2 compatibility).
For example, on Polygon, Aave V3 has a Polygon Bridge Executor that listens for messages passed from the Polygon Bridge, which come from successful governance votes on the Ethereum mainnet. The Polygon Bridge Executor then forwards the messages to the local executor contract on Polygon (Bridge Executor Base), which can execute changes during the grace period if anyone on Polygon initiates changes.
Similar to the Ethereum mainnet, cross-chain proposals exhibit the same delay and grace period behavior; if a guardian address is specified, the proposal can also be vetoed by the guardian address. One issue with multichain governance is that utilizing bridges can introduce security risks, such as trusting bridge validators to relay transactions from the Ethereum mainnet to other chains in a censorship-resistant manner. Additionally, there is the risk of bridge outages and cross-chain proposals failing to be relayed to other chains.
Conclusion
Since the launch of AIP-4, Aave Governance V2 has approved 272 on-chain proposals, providing the community with a secure, efficient, and decentralized platform for proposal creation, voting, and execution.
