Understanding Aave Governance V2: The Decision System Behind DeFi’s Largest Lending Platform

23 AUG 2023 | RESEARCH | AUTHORED BY CALLEN

Summary

• Beginning as ETHLend in 2017, Aave has seen tremendous growth in both protocol usage and governance participation and is one of DeFi’s largest protocols with $5.891b USD in deposits.


• Aave has received numerous upgrades to its lending architecture with the deployment of Aave V2 and Aave V3; accompanied by the launch of Aave Governance V2.


• Aave Governance V2 introduced a fully decentralized governance system to the DAO, meaning the DAO was no longer fully reliant on Aave’s Gensis Team to ratify on-chain proposals.


• Aave Governance V2 introduced new features to governance such as the segregation of voting and proposal power, voting strategies, multiple executor entities, and a community-elected multisig called the Guardian.


• Aave Governance V2 consists of 4 core smart contracts: AaveGovernanceV2, Short Executor, Long Executor, and GovernanceStrategy. Which are responsible for the creation, voting, and execution of Aave Improvement Proposals (AIPs) on Ethereum Mainnet and across other chains.


• Aave Governance V2 has seen tremendous usage boasting 272 proposals and facilitated some of Aave’s largest changes such as the successful deployment of Aave V3 across 8 chains, and the launch of GHO – Aave’s decentralized stablecoin.

A Brief Introduction to Aave

Aave is the largest decentralized lending protocol and third largest DeFi protocol with $5.891b USD in deposits across 8 blockchains. Aave began as ETHLend in 2017 during the Initial Coin Offering (ICO) mania, raising $16.2M USD as a decentralized peer-to-peer (P2P) lending platform in exchange for their LEND token. In 2018, ETHLend was rebranded to Aave signalling the protocol’s shift from a P2P model to a liquidity pool model. In January 2020 Aave V1 was launched, accompanied by a token migration from LEND to AAVE a couple of months later.

The liquidity pool model allowed the pooling of depositors’ coins, providing instant liquidity for borrowers who no longer needed to wait for an ideal counterparty as required in the P2P model. This allowed depositors to passively earn a yield on their tokens from the interest paid by various borrowers over time.

Fast forward to 2023, Aave has seen tremendous growth in both usage and deposits alongside their release and deployment of Aave V2 and more recently, Aave V3, across multiple blockchains.

On top of upgrades to Aave’s lending architecture, we saw Aave’s governance system receive an overhaul with the launch of Aave Governance V2 – a fully decentralized on-chain governance system with improved features.

With the introduction of Aave Governance V2, a new era of fully decentralized on-chain governance unfolded for the DAO with the new governance system experiencing tremendous activity since its launch; handling 272 proposal creations 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 with parameters that underpin how the Aave protocol and Aave DAO are allowed to operate. It was initially proposed by Marc Zeller and activated under AIP-4 in December 2020, introducing 4 key governance innovations to Aave:

1. Segregation of voting and proposal power: Aave/stkAAVE holders can choose to delegate only their proposition power while retaining their power to vote; vice versa.

2. Voting strategies: Different forms of governance-approved Aave tokens can be allowed to vote on proposals e.g., aAAVE – AAVE deposited into the Aave market.

3. Multiple executor entities: The Short and Long Executors allow for different voting requirements based on the significance of the proposed change.

4. The Guardian: A community-elected multisig with individuals who can veto or cancel proposals with malicious code.




Aave Governance V2 was inspired by delegation-based governance models which mimic but do not enforce a representative democracy. In conjunction, these new features provide a more inclusive, efficient, and robust governance system for Aave.







Although, one could argue that the most pivotal change for Aave under Aave Governance V2 was the ability for anyone to submit and implement an AIP (Aave Improvement Proposal). This was not possible with Aave Governance V1, V2’s predecessor.




Specifically, V2 bypasses Step 4 in the V1 governance process which only allowed the Aave Genesis Team to submit AIPs as binding governance proposals. Now with V2, anyone with enough AAVE/stkAAVE is able to submit and implement an AIP in a fully decentralized manner.







Both V1 and V2 have similar initial stages of a proposal’s lifecycle i.e., proposing a change and discussing it with the community. However, Step 3: Aave Request for Final Comments (ARFC), is the final version of the proposal with input from the DAO’s Risk Service Provider. Step 4 requires the community to vote on whether or not they are happy with the final changes, and finally, Step 5 ratifies these changes on-chain through a 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, GovernanceStrategy. These core Smart Contracts handle the AIP’s process from start to finish and serve 3 key functions:




1. Proposal Creation: Any community member with sufficient proposal power can create a proposal under any subcategory of Aave Policies. Depending on which policy is changing will determine how much time, power, and community consensus is needed for the vote.

2. Proposal Voting: Once a proposal is live, AAVE/stkAAVE holders can vote on its outcome through YAE or NAE voting options.

3. Proposal Execution: If a proposal is approved by token holders, the proposal enters into a delay period (Timelock) so that users against the change can exit the system if they choose (e.g., exiting a borrowing position due to stricter risk controls). Once the delay period is over, the proposal then moves into a grace period and can be executed by any Ethereum address by calling the execute function within the Short/Long Executor Smart Contract, or in the adverse case, the Guardian can veto/cancel the proposal.







Specifically,





• AaveGovernancev2 handles the creation of the AIP and requires the user to submit information specifying which executor to use and the changes they wish to make to the protocol. It’s also responsible for setting the length of the review period.


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


• The Long Executor is used for critical changes to the core code base of the protocol that affect governance consensus and requires a lengthy and large consensus process (e.g., changes to the AAVE token, V2 governance parameters, and itself).


• GovernanceStrategy handles the logic that measures users’ proposition and voting power. It also defines which tokens can be used in a vote (i.e., AAVE and stkAAVE).








To further understand how these Smart Contracts interact with one another let’s look at a recent on-chain proposal by Llama to list LDO on Ethereum AAVE V3. Given the proposal is an asset listing and does not touch critical governance consensus parameters, Llama used the Short Executor alongside submitting all relevant information to list LDO via the AaveGovernanceV2 Smart Contract.




At the same moment, AaveGovernanceV2 reads the consensus requirements from the Short Executor Smart Contract and cross-checks with GovernanceStrategy to determine firstly, how to count Llama’s proposition power, and secondly, whether it’s greater than the required 80k AAVE proposal threshold. Given that Llama had sufficient voting power the proposal was successfully created and entered into the 1 day review period.







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

The proposal then entered its 1-day delay period, allowing users to react to the change if needed before entering the 5-day grace period. During the 5-day grace period, a user is required to call execute on the Short Executor to ratify the changes on-chain. If no one executes the proposal before the grace period ends, the proposal expires and the changes are not enacted. Lastly, if the Guardians identify the code to be malicious they are able to veto the proposal to protect the protocol.




Aave’s Multichain Governance System




Given the evergrowing multichain DeFi ecosystem, we continue to see DeFi protocols deploying across an increasing number of chains in pursuit of capturing new users and catering to gas-sensitive audiences. Aave has been at the forefront of the multichain movement boasting 8 chain deployments for their V3 product. However, this introduces new challenges to governance, like ensuring token holders still have control over 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 V3 deployments on Polygon, Arbitrum, and Optimism, are controlled directly from Ethereum Mainnet through Aave’s Cross-Chain Governance Bridges.




Each supported V3 deployment outside of Ethereum Mainnet needs a “bridge receiver” and a local “executor” contract on its chain (Arbitrum and Optimism require a second L2BridgeExecutor contract to ensure L2 compatibility).




For instance, on Polygon, Aave V3 has a PolygonBridgeExecutor that listens for messages passed from the Polygon Bridge that were sent from a successful governance vote on Ethereum Mainnet. The PolygonBridgeExecutor then relays the message to Polygon’s local executor contract (BridgeExecutorBase), which can then execute the changes during the grace period if initiated by anyone on Polygon.







Similarly to Ethereum Mainnet, cross-chain proposals exhibit the same delay and grace period behaviour; proposals can also be vetoed by a Guardian address if specified.

One concern with multichain governance is that utilising bridges introduces security concerns, such as trusting bridge validators to relay transactions from Ethereum Mainnet to alternative chains in a censorship-resistant manner. There is also the risk that a bridge experiences downtime and the cross-chain proposal cannot be relayed to other chains.




Conclusion




Since its activation in AIP-4 Aave Governance V2 has ratified 272 on-chain proposals, providing the community with a secure, efficient, and decentralized platform for proposal creation, voting, and execution.