Introduction

Permissionless money markets, this is the core of what Aave created. Aave is one of the pioneers in developing mechanisms that allow users to lend or borrow digital assets without the involvement of a bank or similar intermediary. The interplay of disruptive technology and game theory helped Aave, Compound, Euler and many others attract billions in user deposits. They opened a world of possibilities to users who suddenly had a great alternative to having their funds sitting idly in their wallet.

‍

Core Differences between Governance V2 and V3

One of the motivations behind the development of Aave's Governance V3 was to reduce the cost of voting¹. With V2, the first decentralized governance system at Aave, on-chain voting took place exclusively on the Ethereum mainnet. I believe it's safe to say that we are all aware of the relatively high transaction fees on Ethereum. Few of us have the ability to pay $5 or more purely for voting or submitting a proposal. This creates a barrier to a large user base from participating in governance. This is counter to Aave’s goal of making participation in governance as inclusive as possible.  

Aave’s innovative solution to this was to move on-chain voting on V3 to different networks where gas fees are lower such as Polygon, Avalanche, Arbitrum or Optimism².

‍

Who can Participate in Governance Decisions?

Anyone who holds one or more of the following tokens³ on the Ethereum mainnet:  

• Aave: the native token of the Aave protocol.

• stAave: represents staked Aave.

• aAave⁴: represents staked AAVE tokens on the Aave V3 Ethereum market.  

The sum of the balances of the three tokens corresponds to the voting or delegation power of a wallet.  

As mentioned above, the voting itself can be performed on various networks, depending on your preference, but the tokens must be held on the Ethereum mainnet.

‍

The Role of Policies

While Policies are not necessarily a core part of the general governance process, I believe it's still valuable to mention them. They are the result of governance decisions and are the framework on how the Aave protocol is operated. While other protocols publish constitutions (or similar manifests), Aave has policies.  

At Aave, policies are defined “as a set of governance-defined rules controlling specific aspects of the protocol or the individual markets on Aave”⁵. There are two types of policies which can be further broken down:

• Protocol Policies: Governing the overall behavior of the Aave protocol

• Risk Policies: Ensuring the safety of the protocol and security for its users. I.e., the risk policy includes the list of assets supported on Aave, the parameters for overcollateralization and liquidations, acceptance in new liquidity markets and more.

• Improvement Policies: Defining the rules and processes for implementing improvements in the ecosystem. Improvement policies cover a broad spectrum, from general smart contracts related to Aave to governance processes and the Aave Token Contract.

• Incentives Policies: Definition of the rules for issuing Aave token incentives. This includes incentivizing desired behaviors to keep the protocol secure, cost-efficient and to drive innovation.  

• Market Policies: Aave will eventually allow anyone to create a money market. For a market to benefit from protocol incentives, it must be created within the rules outlined in the Risk Policies. Market Policies can be seen as a checklist⁶ market creators must follow to set up their own market.

‍

Proposal Lifecycle

1. Introduction

Each proposal starts with an idea that is presented to the Aave community. Either on the official Discord server or in the Governance forum. The main goal of this step is for the proposal creator to receive initial feedback and support.  

This step can also be seen as an unofficial temperature check.

‍

2. Temperature Check

After presenting the proposal to the community and getting an idea of the community's view of it an official temperature check is carried out. This takes place in Aave's SnapShot space. A positive result of the temp check is not binding for the proposal's success. But it qualifies it to move to the next stage of the proposal lifecycle.

‍

3. ARFC

After a proposal has passed the temperature check, the Aave Request for Final Comments ("ARFC") invites relevant stakeholders to provide feedback on the proposal. If it is a proposal that involves changes to the chain, it must detail the exact changes which will be made to Aave's smart contracts.

The ARFC will then be moved to SnapShot (comp. forum post⁷) for an official vote. If the proposal is not related to any on-chain changes, it will be implemented after successful voting. For proposals related to smart contracts changes the step below is required.  

‍

4. AIP

A proposal suggesting changes to Aave's smart contracts must follow successful on-chain voting. However, it must also have passed the aforementioned SnapShot vote.  

This vote is called an AIP which stands for Aave Improvement Proposal. When the on-chain vote is created it contains a proposal payload. This proposal payload contains the changes to the smart contracts. The payload is deployed on the network where the improvements shall be made.

‍

5. Voting

The AIP is submitted on-chain, where the governance participants can vote for or against the proposal. In V3, the proposer must select a network where the voting will take place.  

After the proposal is submitted, it is "pending" for one day before it becomes "active" and thus ready for voting.  

‍

6. Execution

An accepted AIP must wait a certain amount of time before it is implemented. Depending on the proposal, the time lock period is either one day or seven days. The one-day time lock period applies to most proposals that suggest minor protocol changes while the seven-day time lock period applies to proposals updating core permissions.

Without getting too technical, Aave uses an innovative cross-chain governance infrastructure to distribute payloads on the relevant networks while voting is performed on another network. If you are curious, read more about a.DI (“Aave Delivery Infrastructure”) here⁹.

‍

Aave Guardians

The Aave Guardians are a group of people elected by the community. They are key holders of a multi-signature wallet and have certain roles and responsibilities, including but not limited to:

• Secure the Aave protocol by raising a veto against payloads that may be malicious.

• Execute successful proposals on V3 markets where the cross-chain governance bridge is not yet active.  

If you would like to find out more about the Aave guardians and who the currently elected guardians are, please read this article.

‍

Conclusion

Aave's ambitions to decentralize its protocol governance took a massive step forward through the implementation of V3. Aave demonstrates this by dedicating resources to building an innovative governance system that lowers the barriers to participation. One of the main reasons for developing Aave Governance V3 was to make voting across the network chain more effective and cost-efficient. It allows users to cast their vote on their preferred networks, while still holding the governance tokens (Aave, stAave, aAave) on the mainnet. This innovation is especially unique because of the sophisticated communication between the voting network and the network where the changes should be implemented.  

‍

‍

Sources:

1: https://governance.aave.com/t/bgd-aave-governance-v3/12367#non-optimal-aspects-of-v2-3  

2: https://governance.aave.com/t/bgd-aave-governance-v3/12367#high-level-differences-v2-vs-v3-5

3: https://docs.aave.com/aavenomics/governance#protocol-governance-architecture  

4: https://docs.aave.com/governance/master/aave-governance-v3#new-governance-token-aaave  

5: https://docs.aave.com/aavenomics/policies  

6: https://docs.aave.com/aavenomics/policies#market-policies  

7: https://governance.aave.com/t/arfc-arfc-and-temp-check-framework/13828

8: https://docs.aave.com/aavenomics/terminology#aave-improvement-proposals-aip

9: https://governance.aave.com/t/bgd-a-di-aave-delivery-infrastructure/13951