Aave Governance V2 Explained: A More Inclusive and Efficient Decision-Making System
TechFlow Selected TechFlow Selected
Aave Governance V2 Explained: A More Inclusive and Efficient Decision-Making System
Since 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.
Navigating Web3 tides with focused insightsAuthor: CALLEN
Translation: TechFlow
Summary
-
Since ETHLend in 2017, Aave has experienced significant growth in protocol usage and governance participation, becoming one of the largest DeFi protocols with deposits reaching $5.891 billion.
-
Aave has undergone multiple upgrades to its lending architecture, deploying Aave V2 and Aave V3, and launching Aave Governance V2.
-
Aave Governance V2 introduced a fully decentralized governance system for the DAO, meaning the DAO no longer relies entirely on Aave’s founding team to approve on-chain proposals.
-
Aave Governance V2 introduced new governance features such as separation of voting and proposal powers, voting strategies, multiple execution entities, and a community-elected multisig Guardian.
-
Aave Governance V2 consists of four core smart contracts: AaveGovernanceV2, Short Executor, Long Executor, and GovernanceStrategy. These handle the creation, voting, and execution of Aave Improvement Proposals (AIPs) on Ethereum and other chains.
-
Aave Governance V2 has seen substantial adoption, with 272 proposals submitted, driving major changes including successful deployment of Aave V3 across eight chains and the launch of GHO—the decentralized stablecoin by Aave.
Introduction to Aave
Aave is the largest decentralized lending protocol and the third-largest DeFi protocol, with total deposits across eight blockchains amounting to $5.891 billion. Originally launched in 2017 as ETHLend, it raised $16.2 million during the initial coin offering boom by exchanging its LEND token. In 2018, ETHLend rebranded to Aave, marking a shift from a peer-to-peer (P2P) lending model to a liquidity pool model. Aave V1 launched in January 2020, followed shortly by a token migration from LEND to AAVE.
The liquidity pool model allows depositors' tokens to be pooled together, providing immediate liquidity to borrowers without requiring them to wait for ideal counterparties as in the P2P model. This enables depositors to passively earn yields over time from interest paid by various borrowers.
Fast forward to 2023, Aave has seen massive growth in both usage and deposits, releasing and deploying Aave V2 across multiple blockchains, and most recently launching Aave V3.
In addition to upgrades in Aave’s lending architecture, we have also seen a complete overhaul of Aave’s governance system with the introduction of Aave Governance V2—a fully decentralized on-chain governance system with enhanced functionality.
With the introduction of Aave Governance V2, a new era of fully decentralized on-chain governance has opened for the DAO. Since its launch, the new governance system has experienced significant activity—processing the creation of 272 proposals, including the rollout of Aave V3, the launch of GHO—Aave’s decentralized stablecoin—and listings of new assets.
What is Aave Governance V2?
Aave Governance V2 is a set of smart contracts whose parameters support the operation of the Aave protocol and Aave DAO. Initially proposed by Marc Zeller and activated under AIP-4 in December 2020, it introduced four key governance innovations to Aave:
-
Separation of voting and proposal powers: Holders of Aave/stkAAVE can choose to delegate only their proposal power while retaining their voting power, or vice versa.
-
Voting strategies: Different forms of Aave tokens approved by governance can be allowed to vote on proposals.
-
Multiple execution entities: Short Executor and Long Executor allow different voting thresholds based on the significance of proposed changes.
-
Guardian: A community-elected multisig account whose members can veto or cancel proposals containing malicious code.
Inspired by a delegated governance model, Aave Governance V2 mimics—but does not enforce—representative democracy. At the same time, these new features provide Aave with a more inclusive, efficient, and robust governance system.
Nevertheless, one could argue that the most important change under Aave Governance V2 is that anyone can now submit and implement an Aave Improvement Proposal (AIP)—something impossible under its predecessor, Aave Governance V1.
Specifically, V2 bypasses Step 4 of the V1 governance process, which previously restricted binding governance proposals (AIPs) to submissions solely by the Aave Genesis Team. Now, anyone holding sufficient AAVE/stkAAVE can submit and implement AIPs in a fully decentralized manner.
The initial stages of the proposal lifecycle are similar between V1 and V2—proposing changes and discussing with the community. However, Step 3—the Aave Request for Comments (ARFC)—represents the final version of the proposal, incorporating input from DAO risk service providers. Step 4 involves a community vote to determine approval of the final change, and finally, Step 5 formalizes these changes on-chain via an official Aave Improvement Proposal (AIP), executed using Aave Governance V2.
How Does It Work?
Aave Governance V2 consists of four core smart contracts: AaveGovernanceV2, Short Executor, Long Executor, and GovernanceStrategy. These core contracts manage the entire AIP process from start to finish and provide three key functions:
-
Proposal creation: Any community member with sufficient proposal power can create a proposal under any subcategory of Aave policy. The required voting duration, power threshold, and community consensus depend on the type of policy being changed.
-
Proposal voting: Once a proposal begins, AAVE/stkAAVE holders can vote on its outcome using either YAE or NAE options.
-
Proposal execution: If a proposal is approved by token holders, it enters a delay period (time lock), allowing users who oppose the change to exit the system (e.g., exiting borrowing positions due to stricter risk controls). After the delay, the proposal enters a grace period and can be executed by any Ethereum address calling the execute function in the Short/Long Executor smart contract—or, in adverse cases, the Guardian can veto/cancel the proposal.
More specifically,
-
AaveGovernanceV2 is responsible for creating AIPs and requires users to submit information specifying the executor to use and the desired protocol changes. It also sets the length of the review period.
-
Short Executor is used for minor protocol changes and allows faster, less stringent consensus requirements (e.g., parameter adjustments, asset listings).
-
Long Executor is used for major changes to the protocol’s core code that affect governance consensus and require a lengthy and rigorous consensus process (e.g., changes to the AAVE token, V2 governance parameters, or the executors themselves).
-
GovernanceStrategy handles the logic for measuring users’ proposal and voting power. It also defines which tokens can be used in voting (i.e., AAVE and stkAAVE).
To better understand how these smart contracts interact, let's examine a recent on-chain proposal by Llama to list LDO on Ethereum Aave V3. Since this was an asset listing proposal that did not involve critical governance consensus parameters, Llama used the Short Executor when submitting all relevant information through the AaveGovernanceV2 smart contract to list LDO.
Meanwhile, AaveGovernanceV2 reads the consensus requirements from the Short Executor smart contract and cross-checks with GovernanceStrategy to first determine how Llama’s proposal power is calculated, and second whether it exceeds the required 80,000 AAVE proposal threshold. Given that Llama had sufficient voting power, the proposal was successfully created and entered a 1-day review period.
After three days of voting, the Short Executor verified via GovernanceStrategy whether the 320,000 AAVE quorum and 80,000 AAVE vote differential were met. In this case, Llama passed both thresholds, receiving 459.7k AAVE votes in favor ("YAE") and zero "NAE" votes.
The proposal then entered a 1-day delay period, allowing users to react before entering a 5-day grace period. During this 5-day grace period, any user must call the execute function on the Short Executor to finalize the on-chain changes. If no one executes the proposal before the grace period ends, it expires and the changes do not take effect. Finally, if Guardians detect malicious code, they can veto the proposal to protect the protocol.
Aave’s Cross-Chain Governance System
Given the growing multi-chain DeFi ecosystem, we continue to see DeFi protocols deploying across an increasing number of chains to attract new users and serve gas-sensitive audiences. Aave has been at the forefront of the multi-chain movement, deploying its V3 product across eight chains. However, this introduces new governance challenges, such as ensuring token holders retain control over cross-chain deployments in a non-diluted and familiar way.
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 via Aave’s cross-chain governance bridge.
Each supported V3 deployment outside 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 for messages relayed from the cross-chain bridge, originating from successful governance votes on Ethereum mainnet. The PolygonBridgeExecutor forwards the message to Polygon’s native executor contract (BridgeExecutorBase), which can then execute the changes during the grace period upon initiation by anyone on Polygon.
Similar to Ethereum mainnet, cross-chain proposals exhibit identical delay and grace period behaviors; proposals may also be vetoed by the Guardian address if specified.
A concern with multi-chain governance is that using cross-chain bridges introduces security risks, such as trusting bridge validators to relay transactions from Ethereum mainnet to other chains in a censorship-resistant manner. There is also the risk of bridge outages, potentially preventing cross-chain proposals from being delivered to other chains.
Conclusion
Since activation under 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.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@wintermute_t
