Governance

The Aave DAO is a decentralised collective of AAVE token holders and contributors who work together to shape the future of the protocol through a structured governance process. This community-driven model enables participants to propose, discuss, and vote on critical changes, guiding the evolution of the protocol and aligning with the collective goals of its members.

The Aave Protocol is governed by the AAVE token holder community (AAVE, stkAAVE, and aAAVE token holders on Ethereum mainnet) through procedures, voting, and smart contract execution, collectively known as Aave Governance.

Aave Governance V3, developed by BGD Labs, introduces the ability to vote on lower transaction fee networks such as Polygon POS and Avalanche C-Chain while token balances remain on Ethereum mainnet.

Aave Governance V3 is designed with a modular architecture to meet the comprehensive needs of an on-chain DAO like Aave. The system is divided into three main components, each corresponding to different stages in the proposal lifecycle:

Communication between these components is facilitated by the Aave Delivery Infrastructure (a.DI), providing secure and efficient cross-chain interactions. Additionally, the Aave Robot automates permissionless actions in Aave Governance such as queueing and executing proposals.

Aave's governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and execute approved changes through a transparent and structured process.

Aave has predefined frameworks for common types of proposals, simplifying the governance process:

These frameworks streamline governance and allow the community to focus on more complex issues while maintaining the protocol's security and adaptability.

Off-chain votes are used to measure community sentiment during the early stages of proposal development (Temp Checks and ARFCs). These non-binding votes take place on Snapshot and last for three days, allowing token holders to participate without transaction fees.

Once a proposal reaches the AIP stage, onchain voting is required. Token holders, delegates, or delegators vote on proposals using their AAVE, stkAAVE, or aAAVE tokens. The process is secured through various governance interfaces, including Aave Labs, BGD Labs, and Boardroom.

In Governance V3, each proposal specifies a voting network and all voting for the proposal occurs on this network. The Governance V3 activation enables Polygon POS, Avalanche C-Chain, and Ethereum Mainnet (backup) as initial voting networks. Since voting can occur on multiple networks, this can create limitations for smart contract wallets that only exist on one network. To accommodate this, governance interfaces can be used to setup voting representatives, which allows a separate voting address to be designated for each network.

Voters do not need to migrate funds to the voting network, all governance token balances and delegations are still stored on Ethereum mainnet, and are validated on the voting network using storage proofs.

Voting is performing by calling the submitVote() function on the VotingMachine of the corresponding proposal’s voting network.

An aave-cli has been developed to generate the necessary storage proof parameters, or voting can performed with the GovernanceV3Helpers Foundry script.

AAVE, stkAAVE (AAVE staked in protocol safety module), and aAAVE (aToken representing AAVE supplied to Ethereum V3 market) token holders receive governance powers proportional to the sum of their balances on Ethereum mainnet.

There are two powers associated with each governance token:

Governance powers can be either jointly or separately delegated to any Ethereum address.

Smart contract wallets cannot sign messages for storage proof voting and may not exist on all networks, this creates a challenge to interact with the cross-chain voting contracts.

To accommodate cross-chain voting for smart contract wallets and allow greater flexibility for all governance participants, wallets have the ability to link a representative address on other chains.

To choose a representative, an address in Ethereum should call the updateRepresentativesPerChain() function on the GovernanceCore smart contract.

This representative address is able to vote on the specified network, using the delegators balances and received delegations on Ethereum Mainnet. An address can be the representative of multiple other addresses.

Aave Governance V3 uses block hashes on the Core network (Ethereum Mainnet) as the source of information for voting balances, and storage proofs as the core mechanism for validation.

For any proposal, the system takes a “snapshot” (block hash of the block before activateVote method gets called) of voting token balances/delegations on the Core network, forwards it to an Aave Voting Network and sets it as the main source of balances/delegation to validate against whenever an address submits a vote there.

Ethereum block hashes contain the state tree of the network, which in turn contains all the data of all the smart contracts at that exact block. Amongst those contracts: AAVE, stkAAVE, and other voting assets are present, and within them, the balances and delegations of all Ethereum addresses.

Storage proofs are a mechanism allowing to cryptographically prove that a piece of data is contained in a tree. In this case, they allow proving that a specific address has voting balance/delegation on the state tree of an Ethereum block.

What happens in practice when an address votes is that the voter inputs the balance of the voting assets they hold at the proposal's Ethereum block, together with a storage proof over the Ethereum block hash for that proposal. The Voting Network then cryptographically verifies the storage proof against the Ethereum block data, along with all additional validations (e.g., no double-voting), and stores the results accordingly.

Delegates are entrusted with voting power by other community members or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have delegated their voting rights. Some delegates are compensated through the Orbit program for their contributions.

Delegators are community members who hold AAVE, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another individual or entity. This allows them to have their interests represented in governance without directly participating in every vote.

Contributors dedicate time and resources to the Aave DAO by engaging in working groups, completing bounties, building on the protocol, or working through grants. These efforts help maintain and improve the Aave ecosystem.

Service providers offer essential services to the protocol, such as risk management, financial oversight, security, and development. Examples of service providers include:

The Aave Community Guardians are a group of community-elected signers authorized to execute limited emergency protections.

The Aave Guardians have responsibilities divided between two multi-signature wallets, with roles and signers listed below.

The Protocol Emergency Guardian is the holder of the EMERGENCY_ADMIN role for Aave protocol markets and failsafe emergency actor for cross-chain messaging in Emergency Mode.

The Protocol Emergency Guardian is a 5 of 9 multi-signature wallet consisting of the following community-elected signers:

The Governance Emergency Guardian is tasked to protect the Aave Protocol against potential governance takeovers by having the ability to “veto” an onchain payload if it is deemed malicious.

The Governance Emergency Guardian is a 5 of 9 multi-signature wallet consisting of the following community-elected signers:

Stewards have delegated responsibility over specific protocol parameters, allowing the DAO to quickly respond to market changes. Stewards manage areas such as the GHO stablecoin and liquidity parameters. This system streamlines governance by reducing the need for frequent votes on minor adjustments, promoting efficiency. The source code for GHO Steward contracts can be found on GitHub.