An In-depth Analysis of Aave Governance V2 A More Inclusive and Efficient Decision-making System

A comprehensive analysis of Aave Governance V2 a more inclusive and efficient decision-making system.

Author: CALLEN; Source: wintermute; Compilation: Deep Tide TechFlow

Summary:

• Starting with ETHLend in 2017, Aave has achieved significant growth in protocol usage and governance participation, becoming one of the largest protocols in DeFi with a total deposit of $5.891 billion.

• Aave has undergone multiple upgrades in its lending architecture, deploying Aave V2 and Aave V3, and launching Aave Governance V2.

  • Coinbase is in talks with Canadian banking giant to promote cryptocurrencies
  • LianGuai Morning News | ARK Invest and 21Shares Submit Ethereum ETF Application
  • How far can Friend.tech, the new darling of Web3 social, go in the future?

• Aave Governance V2 introduces a fully decentralized governance system for the DAO, which means the DAO no longer relies solely on Aave’s founding team to approve on-chain proposals.

• Aave Governance V2 introduces new features to governance, such as the separation of voting and proposal power, voting strategies, multiple execution entities, and multi-signature accounts Guardians elected by the community.

• Aave Governance V2 consists of 4 core smart contracts: AaveGovernanceV2, Short Executor, Long Executor, and GovernanceStrategy. They are responsible for creating, voting, and executing Aave Improvement Proposals (AIPs) on the Ethereum mainnet and other chains.

• Aave Governance V2 has achieved significant usage, with 272 proposals and has facilitated some major changes in Aave, such as the successful deployment of Aave V3 and the launch of GHO on 8 chains – Aave’s decentralized stablecoin.

Aave Introduction

Aave is the largest decentralized lending protocol and the third largest DeFi protocol, with a total deposit across 8 blockchains reaching $5.891 billion. Aave started as ETHLend in 2017, raising $16.2 million in the initial token issuance frenzy, as a decentralized peer-to-peer (P2P) lending platform with its LEND token exchange. In 2018, ETHLend was rebranded as Aave, marking the protocol’s shift from the P2P model to the liquidity pool model. In January 2020, Aave V1 was launched, and a few months later, a token migration from LEND to AAVE took place.

The liquidity pool model allows the pooling of depositors’ tokens to provide instant liquidity to borrowers, eliminating the need to wait for an ideal counterparty as in the P2P model. This allows depositors to earn token returns through interest paid by various borrowers that increase over time.

Fast forward to 2023, Aave has achieved significant growth in usage and deposits, and has also released and deployed Aave V2 on multiple blockchains, with Aave V3 recently launched.

In addition to the upgrade of the Aave lending architecture, we have also seen a thorough overhaul of Aave’s governance system with the launch of Aave Governance V2 – a fully decentralized on-chain governance system with improved functionality.

With the introduction of Aave Governance V2, a new era of fully decentralized on-chain governance has unfolded for DAOs. Since its launch, the new governance system has undergone significant activity, handling 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 set of smart contracts that support the operation of the Aave protocol and Aave DAO. It was originally proposed by Marc Zeller and activated under AIP-4 in December 2020, introducing 4 key governance innovations for Aave:

1. Separation of voting and proposal power: Aave/stkAAVE holders can choose to delegate only their proposal power while retaining their voting power, and vice versa.

2. Voting strategy: Different forms of Aave tokens approved by governance can be allowed to vote on proposals.

3. Multiple execution entities: Short-term executors and long-term executors allow for different voting requirements based on the importance of the proposed changes.

4. Guardian: A multi-signature account elected by the community, where individuals can veto or cancel proposals with malicious code.

Aave Governance V2 is inspired by the delegated governance model, which mimics but does not enforce representative democracy. At the same time, these new features provide Aave with a more inclusive, efficient, and powerful governance system.

Nevertheless, some may consider the most important change for Aave under Aave Governance V2 is that anyone can submit and implement AIPs (Aave Improvement Proposals). This was not possible with the predecessor V1 of Aave Governance.

Specifically, V2 bypasses the 4th step in the governance process of V1, which only allowed AIPs submitted by the Aave Genesis team as binding governance proposals. Now, anyone with enough AAVE/stkAAVE can submit and implement AIPs in a fully decentralized manner.

V1 and V2 share similarities in the initial stages of the proposal lifecycle, which involve proposing changes and discussing with the community. However, the 3rd step, Aave Request for Comment (ARFC), is the final version of the proposal that includes the opinions of DAO risk service providers. The 4th step requires community voting to determine if they are satisfied with the final changes, and finally, the 5th step approves these changes on-chain through the formal Aave Improvement Proposal (AIP) using Aave Governance V2.

How does it work?

Aave Governance V2 consists of 4 core smart contracts: AaveGovernanceV2, Short Executor, Long Executor, and GovernanceStrategy. These core smart contracts are responsible for handling the process of AIP from start to finish and provide 3 key functionalities:

1. Proposal creation: Any community member with sufficient proposal power can create proposals under any subcategory of Aave policies. The time, permissions, and community consensus required for voting are determined based on the policy being changed.

2. Proposal voting: Once a proposal begins, AAVE/stkAAVE holders can vote on its outcome using the YAE or NAE voting options.

3. Proposal execution: If a proposal receives approval from token holders, it enters a delay period (time-lock) to allow users opposing the changes to exit the system (e.g., exiting borrowing positions due to stricter risk controls). After the delay period ends, the proposal enters a grace period and can be executed by any Ethereum address by calling the execute function in the Short/Long Executor smart contract or, in adverse situations, can be vetoed/canceled by the Guardian.

Specifically,

• AaveGovernanceV2 is responsible for creating AIPs, requiring users to submit information, specifying the executor to be used, and the changes they would like to make to the protocol. It is also responsible for setting the length of the governance period.

• Short Executor is used for minor changes to the protocol and allows for faster and less strict consensus requirements (e.g., parameter changes, asset listings, etc.).

• Long Executor is used for major changes to the protocol’s core code that affect governance consensus and require a lengthy and extensive consensus process (e.g., changes to the AAVE token, V2 governance parameters, and itself).

• GovernanceStrategy handles the logic for measuring user proposals and voting power. It also defines the tokens (i.e., AAVE and stkAAVE) that can be used for voting.

To further understand how these smart contracts interact with each other, let’s look at a recent on-chain proposal made by Llama to list LDO on Ethereum AAVE V3. Since this proposal is an asset listing proposal and does not involve critical governance consensus parameters, Llama used the Short Executor and the AaveGovernanceV2 smart contract to list LDO while submitting all relevant information.

At the same time, AaveGovernanceV2 reads the consensus requirements from the Short Executor smart contract and cross-checks them with GovernanceStrategy to first determine how Llama’s proposal power is calculated, and then determine if it exceeds the required 80,000 AAVE proposal threshold. Given that Llama has sufficient voting power, the proposal is successfully created and enters a 1-day review period.

After 3 days of voting, the Short Executor uses GovernanceStrategy to verify if the 320,000 AAVE quorum and 80,000 AAVE vote differential are met. In this case, Llama successfully passed both parameters, receiving 459.7k AAVE “YAE” votes and 0 “NAE” votes.

Then, the proposal enters a 1-day delay period, allowing users to react to the changes before entering a 5-day grace period. During the 5-day grace period, users need to call the execute function on the Short Executor to approve these changes on-chain. If no one executes the proposal before the grace period ends, the proposal expires, and the changes will not take effect. Finally, if the Guardians determine that there is malicious behavior in the code, they can veto the proposal to protect the protocol.

Aave’s Multi-Chain Governance System

Considering the growing multi-chain DeFi ecosystem, we continue to see DeFi protocols being deployed on more and more chains to attract new users and cater to fuel-sensitive audiences. Aave has been at the forefront of the multi-chain movement, deploying its V3 product on 8 chains. However, this brings new challenges to governance, such as ensuring token holders still have control over cross-chain deployments in a decentralized and familiar manner.

The cross-chain governance architecture of Aave is similar to other major protocols such as Uniswap and Compound. In the case of Aave, only the V3 deployments on Polygon, Arbitrum, and Optimism are controlled directly from the Ethereum mainnet through Aave’s cross-chain governance bridge.

Each supported V3 deployment outside the Ethereum mainnet requires a “cross-chain bridge receiver” and a native “executor” contract (Arbitrum and Optimism require a second L2BridgeExecutor contract to ensure L2 compatibility).

For example, on Polygon, Aave V3 has a PolygonBridgeExecutor that listens to messages passed from the Polygon cross-chain bridge, which are sent from successful governance votes on the Ethereum mainnet. Then, the PolygonBridgeExecutor forwards the messages to the native executor contract (BridgeExecutorBase) on Polygon, where any changes can be executed by anyone on Polygon within the grace period.

Similar to the Ethereum mainnet, cross-chain proposals exhibit the same delay and grace period behavior; proposals can also be vetoed by Guardian addresses if specified.

One concern with multi-chain governance is that introducing cross-chain bridges raises security issues, such as trusting bridge validators to relay transactions from the Ethereum mainnet to other chains in an uncensorable manner. There is also a risk of cross-chain bridge downtime, which would prevent cross-chain proposals from being delivered to other chains.

Conclusion

Since its activation in 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.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!