Detailed explanation of the Aave governance module V3 functions and process introduction

The blue-chip lending protocol AAVE officially launched its latest governance module - Aave Governance V3 on December 27th, bringing significant advantages such as reducing voting costs, adding automated bots, and improving cross-chain infrastructure, setting a new paradigm for on-chain governance. Learn more.

Value Reference of Aave Governance Module

As of the deadline, the Aave lending protocol has approximately $6.5 billion in funds, ranking it among the top three DeFi products alongside Lido and Maker. Therefore, any updates must be approached with great caution. Hence, even the governance has a very detailed set of rules and contract executions to minimize human errors and centralization risks as much as possible.

Unlike other project governance models that rely on multi-signature control of protocol backdoor functions, or may not even have multi-signature, the Aave protocol has a relatively secure mechanism. It is very valuable for imagining ideal governance mechanisms in the future.

On the other hand, AAVE Governance V2 has been running since 2020, and its feasibility has been fully validated. It even completed the issuance of GHO stablecoin and protocol integration through this complex engineering process, all managed by the governance module, which is indeed very interesting.

Introduction to Aave Governance Module V2

The existing AAVE Governance V2 module will be discontinued, but V3 will inherit its overall structure and undergo optimization, hence requiring a basic understanding.

Basic Structure

The operating goal of AAVE Governance V2 is to achieve complete decentralization, with DAO automatically updating protocols based on on-chain governance results, without relying on the founding team to approve on-chain proposals.

In practice, Aave Governance V2 can be broken down into the following components:

• AaveGovernancev2: Responsible for handling the creation of AIPs, information submission, parameter settings, etc.
• Short Executor: Used for minor protocol changes, responsible for executing proposals with lower threshold approval to achieve rapid iteration, such as proposals to add or remove assets from the protocol's acceptable asset list.
• Long Executor: Used for major changes to the core protocol code, responsible for executing proposals with higher threshold approval, such as proposals to modify the logic rules of the protocol itself.
• GovernanceStrategy: Handles the operation logic of user proposals and voting, defines which tokens can be used for voting, with AAVE and stkAAVE Stake AAVE available for voting in V2.

There is also a set of contracts called Aave Guardian, controlled by a multi-signature of ten addresses, primarily responsible for emergency contract modifications to protect the protocol in critical situations. It can cancel malicious proposals and even shut down protocol operations as needed.

Aave Protocol Security Breach｜Funds Are Safe, Waiting for Community Vote to Restart the Market

Operational Process

The basic structure of the governance process of the AAVE Governance V2 module in the past is as follows:

1. Proposal Submission: Proposals are discussed in the community forum and subjected to a Temperature check, followed by an on-chain Snapshot vote.
2. ARFC: Proposals approved by on-chain voting are compiled into complete AIPs, with full code submission, followed by another on-chain Snapshot vote.
3. Submit AIP: Usually, the team submits the proposal approved in the second on-chain vote as an AIP to the governance contract, but in reality, anyone can submit an AIP.
4. Delay Period: After a day or so of delay, the governance contract completes a token snapshot to confirm voting rights.
5. On-chain Voting: Different proposals have varying thresholds for approval based on their impact.
6. Proposal Execution: After approval, there is a locking period before using the Short Executor or Long Executor to execute code updates based on the proposal's impact, triggered by external addresses.
7. Cross-chain Execution: If the proposal is on a network other than Ethereum, cross-chain transactions and execution of the corresponding network's execution contract are necessary, also triggered by external addresses.

Existing Issues

Issues discovered by AAVE Governance V2 after three years of operation:

• High Voting Costs: The current design incurs high gas fees, especially for small users. Aave and stkAAVE token voting rights are decentralized, with over 150,000 Aave holders and 20,000 stkAAVE holders, many of whom hold small amounts of tokens and voting rights. Even at relatively low Ethereum gas price levels of around 20 gwei, voting still costs around $5, not to mention that during network congestion, voting costs could increase by five to ten times.
• Conflict between Governance and Token Interests: To accommodate the existing governance module, tokens need to be queryable by the contract to verify the voting rights of AAVE and stkAAVE token holders. This additional balance history recording requirement increases the transfer gas fees for AAVE and stkAAVE token holders, indirectly raising the operating costs for token holders.

Introduction to Aave Governance Module V3

A Quick Comparison of Aave Governance V3 and V2

• Proposal Creation: Governance rules in V3 require proposers to deploy executable and valid contract code in the Aave contract before creating proposals and completing registration for proposal approval.
• Voting Delay: Similar to V2, there will be a 1-day delay between proposal creation and voting start, with a snapshot taken at the end. However, due to technical reasons, the delay time in V3 may vary by hours.
• Proposal Voting: In most cases, voters will not vote on Ethereum but on other networks such as Polygon, Avalanche, Arbitrum, or Optimism, with more networks to be opened in the future. Note: Voting for a proposal will only take place on one network, not simultaneously on multiple networks. Proposers can choose the specific network for voting based on preference or other factors.
• Proposal Execution: The time lock and execution phase of proposals will be identical to V2 and will be extended to other networks.
• Acceptance of More Assets for Voting Rights: AAVE, aAAVE, stkAAVE, and stkABPT will all receive voting rights.

Implementation Structure: Governance Operation Process

All future proposals in the AAVE governance module will go through the following process:

1. Code Submission: The proposer creates and submits the proposal and registers it in the controller contract of the target network. For example, if the proposal is to add asset classes on Aave v3 Avalanche, the proposal needs to be submitted on Avalanche and the code deployed, all without permission.
2. Return of Proposal ID: After the proposer completes the proposal creation process, they receive an ID sent by the target network.
3. Proposal Creation: Qualified proposers with IDs and sufficient proposal rights create proposals on Ethereum through the core governance contract and select the network for the submitted code.
4. Proposal Activation: After the delay period, the Aave bot or any other Ethereum address can activate the proposal and complete the blockchain state snapshot.
5. Submission of Block Hash: The governance core contract submits the proposal information, Ethereum block hash, to the Aave cross-chain infrastructure.
6. Settlement of Target Network Status: On the target voting network, settlement of the global state for voting verification is completed by the Aave bot or other addresses, including Ethereum block hash, its state tree, and the state tree of voting assets.
7. Start of Voting: Voting begins on the target network.
8. Proposal Voting: Every user with voting rights on Ethereum can vote on the target network through the voting contract.
9. Close Voting: The Aave bot or other address calls the voting mechanism to close voting.
10. Result Settlement: Voting results are sent in a count of "yes" and "no" through the Aave cross-chain infrastructure to the Ethereum mainnet.
11. Execution Waiting: When the voting results reach the core governance contract on Ethereum and after verification confirmation, execution is awaited.
12. Proposal Execution: The Aave bot or other address executes the code update.
13. Cross-chain Execution: For updates outside Ethereum, they are queued on the corresponding controller.
14. Proposal Execution: Once the locking period ends, the Aave bot or other address executes the code update on the target network.

Implementation Structure

Through the above operational structure, we can better understand the core modules of Aave Governance V3, which include the following components:

• Ethereum Core Governance Contract: Responsible for settlement determination of all governance modules, verifying user voting rights, snapshotting state, determining voting tokens and rules, canceling malicious proposals via Guardian, forwarding proposals to the target network, retaining most of the Aave Governance V2 operational principles.
• Target Network Governance Contract Aave Voting Machine: Responsible for governance operations on the target network, including accepting proposers' code and interactions, executing voting logic, returning voting results, etc.
• Cross-chain Communication Infrastructure: A brand-new cross-chain communication infrastructure to bridge various networks in the future. Its main functions include bidirectional communication, customization, and emergency backdoor mechanisms.
• Aave Robot: Automates most governance functions, with interaction costs borne directly by the Aave DAO, choosing Chainlink Automation as the core operation. Main functions include triggering proposals after the delay period, providing state proofs to the target network, executing code updates on Ethereum and target networks, etc.

Furthermore, due to significant changes in the overall governance framework rules, users need access to voting machines on each network. Therefore, the core team BGD Labs has redesigned the open-source frontend interface and provided users with the ability to create their own copies of the code.

Advantages of Aave Governance V3

• Significant Reduction in Voting Costs: By voting on external networks, for example, at the current gas fee levels on Polygon, voting costs will be between $0.05 and $0.1. This is about 100 times cheaper than the voting costs in the current Aave Governance V2. It may even make it possible for participants to vote completely for free, and it is suggested that the DAO bears all participants' voting costs. If there are 10,000 participants, the total cost would be only $750, which is affordable.
• Reduced Native Token Operating Costs: AAVE and stkAAVE will no longer have balance history snapshots. In Aave Governance V3, these token smart contracts will be upgraded, reducing the cost of transferring AAVE and stkAAVE by about 75%.
• Permissionless Automation: Although there are many stages that require interaction with the blockchain to generate state transitions in Aave Governance V3, these can all be automatically executed by the Aave bot, making it much more convenient than V2, which required manual triggering by users.