AAVE, the blue-chip lending protocol, officially launched its latest governance module – Aave Governance V3, today (12/27). This brings significant advantages, including a substantial reduction in voting costs, the addition of automated bots, and the improvement of cross-chain infrastructure, setting a new paradigm for on-chain governance.

Table of Contents:

Reference Value of Aave governance module

The Aave lending protocol holds approximately $6.5 billion in funds as of the time this article is written, ranking among the top three on-chain products (with Lido and Maker being the first and second, respectively). Therefore, any updates must be approached with great caution. Even the governance can follow a robust set of regulations and contract executions to minimize human errors or centralization risks.

In contrast to other project governance models that rely on multisig control of protocol backdoor functions (some may not even have multisig), Aave protocol has a relatively secure mechanism. It provides valuable insights into the ideal governance mechanism for the future.

On the other hand, AAVE Governance V2 has been operational since 2020, and its feasibility has been thoroughly validated. It even facilitated the issuance of the GHO stablecoin and protocol integration, handling such a complex engineering feat solely through the operation of the governance module, which is indeed intriguing.

Introduction to Aave Governance Module V2

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

Basic architecture

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

Aave 治理 V2 架构(资料来源)
Aave Governance V2 architecture (source)

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

• AaveGovernancev2：Responsible for handling the creation, information submission, parameter setting, etc. of AIP.
• Short Executor: used to make smaller changes to the protocol, responsible for executing the content of proposals passed with a lower threshold to complete rapid iterations, such as proposals to increase or decrease the list of acceptable assets in the protocol.
• Long Executor: used to make significant changes to the core code of the protocol, responsible for executing proposals that pass with a higher threshold, such as proposals to modify the logic rules of the protocol itself.
• GovernanceStrategy：Process the operational logic of user proposals and voting, and define which tokens can be used for voting. The tokens that can be used for voting in V2 are AAVE and stkAAVE (Stake AAVE).

There is also a set of contracts called Aave Guardian, which is controlled by multi-signatures of ten addresses. Its main responsibility is to modify the contract of the protocol in emergency situations, so as to protect the security of the protocol. Depending on the situation, malicious proposals can be canceled, or even the protocol operations can be shut down.

(Aave security vulnerability explodes｜Funds are no longer at risk, waiting for community vote to restart the market)

Operation flow

In the past, the basic structure of the governance process of the AAVE Governance V2 module was as follows:

1. Proposal submission: The proposal is discussed in the community forum, and Temperature check is performed, followed by off-chain Snapshot voting.
2. ARFC: Compile the proposals that pass off-chain voting into a complete proposal (AIP), submit the complete code at the same time, and conduct off-chain Snapshot voting again.
3. Submitting AIP: Usually, the team submits AIP to the governance contract for proposals that pass the second off-chain vote, but anyone can submit AIP.
4. Delay period: After a delay period of about one day, the governance contract completes the token status snapshot and confirms voting rights.
5. On-chain voting: There are different passing thresholds for proposals with different levels of impact.
6. Proposal execution: After the proposal is passed, there will be a lock-in period. After the end, Short Executor or Long Executor will be used to execute the update code according to the proposals with different levels of impact. This part needs to be triggered by an external address.
7. Cross-chain execution: If the proposal is on a network other than Ethereum, it is necessary to execute cross-chain transactions and execute the execution contract of the corresponding network, which also needs to be triggered by an external address.

Existing problems

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

• High Voting Costs: The current design incurs significant gas costs, particularly impacting small users. Both Aave and stkAAVE token voting rights are decentralized, with over 150,000 Aave holders and 20,000 stkAAVE holders. Many users hold a small amount of tokens and corresponding voting power. Even in scenarios where Ethereum gas fees are relatively low (e.g., 20 gwei), completing a vote still costs around $5. During network congestion, voting costs could escalate five to ten times.
• Governance and Token Interest Conflict: To accommodate the existing governance module, tokens need to be queryable by contracts to verify the voting rights of AAVE and stkAAVE token holders. The tokens themselves require recording additional balance history, leading to increased transaction fees for AAVE and stkAAVE transfers. This indirectly raises operational costs for token holders. These challenges highlight the need for improvements in the AAVE Governance V2 model to address voting costs, enhance decentralization, and mitigate conflicts between governance and token interests.

Introduction to Aave Governance Module V3

A quick look at the similarities and differences between Aave Governance V3 and V2

• Proposal creation:The governance rules of V3 require proposers to deploy executable and valid contract code in the Aave contract and complete registration to obtain proposal recognition before creating a proposal.
• voting delay: Almost the same as V2, there will be a 1-day delay between proposal creation and the start of voting, with a snapshot of voting rights taken after the end. However, due to some technical reasons, the latency on v3 will vary by hours.
• Proposal voting: Voters will in most cases not cast their votes on Ethereum, but on other networks such as Polygon, Avalanche, Arbitrum or Optimism, with more networks to be opened in the future. Supplement: Voting for a proposal will only be conducted on one network, rather than on multiple networks simultaneously. The proposer can choose which network to vote on based on preferences or other factors.
• Proposal execution: The time lock and execution phase of the proposal will be exactly the same as in V2, with execution extended to other networks.
• Accept more asset recognition 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:

Aave Governance V3 operation process(source)

1. Code Submission: The proposer creates a proposal and submits the code, registering it with the controller contract on the target network. For example, if the proposal aims to add asset classes on Aave v3 Avalanche, the proposal must be submitted and the code deployed on Avalanche, requiring no permission throughout the process.
2. Return Proposal ID: After completing the proposal creation process, the proposer receives an identification certificate from the target network.
3. Proposal Creation: Eligible proposers (holding an identification certificate and sufficient proposal rights) create proposals on Ethereum using the core governance contract, selecting the network for the submitted code.
4. Initiate Proposal: After the delay period, Aave bots or any other Ethereum address can initiate the proposal and complete a snapshot of the blockchain state.
5. Submit Block Hash Value: The governance core contract submits proposal information (Ethereum block hash) to the Aave cross-chain infrastructure.
6. Target Network State Settlement: On the target voting network, Aave bots or other addresses finalize the settlement of the global state used for voting verification. This includes Ethereum block hash values, their state tree, and the state tree of voting assets.
7. Start 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: Aave bots or other addresses call the voting mechanism to close the vote.
10. Result Settlement: The voting results, in the form of “yes” and “no” counts, are sent to the Ethereum mainnet via the Aave cross-chain infrastructure.
11. Wait for Execution: The voting results reach the core governance contract on Ethereum. After verifying and confirming the information, it waits for execution.
12. Proposal Execution: Aave bots or other addresses execute the updated code.
13. Cross-Chain Execution: The code is transmitted to the corresponding execution contract on Ethereum or another network, initiating a time-lock period.
14. Wait for Execution: For updates outside Ethereum, the content queues on the respective controller.
15. Proposal Execution: Once the lock period ends, Aave bots or other addresses execute the updated code on the target network.

Implementation Architecture

With knowledge of the above operational framework, we can better understand core components of Aave Governance V3:

• Ethereum Core Governance Contract: Responsible for the settlement determination of all governance modules. It verifies user voting rights, state snapshots, decides voting tokens, determines voting rule logic, cancels malicious proposals through Guardian, forwards proposals to the target network, and maintains most of the operational principles of Aave Governance V2.
• Target Network Governance Contract (Aave Voting Machine): Responsible for governance operations on the target network. It includes accepting proposers’ code and interactions, executing voting logic, and returning voting results.
• Cross-Chain Communication Infrastructure: A new cross-chain communication facility designed to address the bridging needs of various future networks. Its main features include bidirectional communication, customized functionality, and emergency backdoor mechanisms.
• Aave Robot: Implements most governance functions automatically, with both its interaction costs and network interactions borne directly by Aave DAO, choosing Chainlink Automation as its core. Main functions include triggering proposals after the delay period, providing state proofs to the target network, and executing code updates on both Ethereum and the target network.

Additionally, due to significant changes in the overall governance architecture rules, users need access to voting machines on various networks. Therefore, the core team at BGD Labs has rebuilt an open-source front-end interface and provided users with the code to create their own copies.

There are currently no proposals for this front-end interface(source)

Advantages of Aave Governance V3

• Significant Reduction in Voting Costs:

By voting on external networks, using the current fee level on Polygon as an example, the voting cost will be between $0.05 and $0.1. This is approximately 100 times cheaper than the current voting cost in Aave Governance V2. It may even enable participants to vote completely free of charge. In the future, it is suggested that the DAO cover all participants’ voting costs. If there are 10,000 participants, the total cost would be only $750, which is affordable.

• Reduced Native Token Operational Costs:

There will no longer be balance history snapshots for AAVE and stkAAVE. With the smart contract upgrades in Aave Governance V3, it is expected that the transfer of AAVE and stkAAVE will be approximately 75% cheaper.

• Permissionless Automation:

Although Aave Governance V3 involves many stages that require interaction with the blockchain to generate state transitions, these stages can be automated through the Aave Robot. This is much more convenient than V2, which requires manual triggering by users.

Disclaimer：

1. This article is reprinted from [链新闻]. All copyrights belong to the original author [Kyle]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.