Governance

The Aave Protocol is governed by the AAVE token holder community through procedures, voting, and smart contract execution, collectively known as Aave Governance.

All instances of the Aave Protocol are governed by the AAVE, stkAAVE, and aAAVE token holders on Ethereum mainnet. 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.

Architecture

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:

  • Core Network: Acts as the settlement and security layer where voting power resides. It handles high-level validations on proposals and manages governance token balances. Ethereum Mainnet serves as the Core Network.

  • Voting Networks: Environments where voting occurs based on storage proofs. These networks are typically lower-cost environments like Polygon POS and Avalanche C-Chain, enabling users to vote without migrating funds from the Core Network.

  • Execution Networks: Networks where proposal payloads are registered and executed. They handle the execution of approved proposals across various networks, including all Voting Networks and the Core Network.

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.

Voting

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.

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.

Voting Power

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:

  • The proposal power that gives access to creating a proposal.

  • The voting power which is used to vote for or against active proposals.

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

Voting Representatives

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.

Storage Proofs

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.

Proposal Lifecycle

  1. Payload Registration: Proposal payloads containing executable logic are deployed and registered on the PayloadsController of the target Execution Network. This process is permissionless.

  2. Proposal Creation: A proposer with sufficient proposal power creates the proposal on the Core Network (Ethereum Mainnet) by interacting with the Governance contract. The proposer specifies the payload IDs and target networks.

  3. Proposal Activation: After a cooldown period (coolDownBeforeVotingStart), the proposal is activated. This involves taking a snapshot of the Core Network's state and forwarding it to the specified Voting Network using a.DI.

  4. Voting Setup: On the Voting Network, the necessary data (Ethereum block hash, state tree, voting asset roots) is settled in the DataWarehouse contract. This step is permissionless and can be performed by any address.

  5. Voting Period: Voting occurs on the Voting Network. Voters submit their votes by calling submitVote() on the VotingMachine, providing their token balances at the snapshot block along with storage proofs.

  6. Vote Closure: After the voting duration (votingDuration) elapses, voting is closed. The VotingMachine contract sends the voting results (YES and NO counts) back to the Core Network via a.DI.

  7. Result Validation: The Governance contract on the Core Network validates the voting results against success metrics, such as minimum thresholds and vote differentials.

  8. Proposal Queuing: If the proposal meets the success criteria, it is forwarded to the PayloadsController on the Execution Network, where it is queued in a timelock mechanism.

  9. Proposal Execution: After the timelock expires, any address can execute the proposal by calling executePayload() on the PayloadsController, which forwards it to the appropriate Executor for execution.

Deployed Contracts

Ethereum

Arbitrum

Avalanche

BNB

Base

Binance

Gnosis

Metis

Optimism

Polygon

Scroll

ZkSync

Aave.com provides information and resources about the fundamentals of the decentralised non-custodial liquidity protocol called the Aave Protocol, comprised of open-source self-executing smart contracts that are deployed on various permissionless public blockchains, such as Ethereum (the "Aave Protocol" or the "Protocol"). Aave Labs does not control or operate any version of the Aave Protocol on any blockchain network.