Governance#Copy

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 introduces the ability to vote on lower transaction fee networks such as 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 implement approved changes through a transparent, structured process, as an AAVE, stkAAVE, or aAAVE delegate.

Every type of governance action falls into one of three processes, based on who implements it:

As Steward roles are introduced, a growing share of routine upgrades shifts from the Direct-to-AIP process to the Steward Process. Token holders retain key decision-making power and delegate daily operations to trusted actors who operate the Steward roles.

The ARFC vote is binding. This allows the Aave DAO to make commitments before deploying technical resources for larger initiatives, such as deploying Aave Protocol instances, entering new markets within an existing instance, or committing to payment upon delivery of work scopes.

The Long Executor (Level 2) governs the most sensitive parts of the protocol, those that define governance itself. It controls upgrades to the AAVE, stkAAVE, and aAAVE tokens, changes to the governance contracts and their permissions, and modifications to the executors and timelocks themselves. In short, it covers any change that could affect voting or proposition power.

Because these changes carry the highest impact, the Long Executor applies stricter requirements than the Short Executor (Level 1), which handles day-to-day protocol matters such as asset listings, parameter updates, and treasury operations. A Level 2 proposal runs a longer 10-day voting period, requires a higher quorum and vote differential, and passes through a 7-day timelock before execution, compared with the 3-day vote and 1-day timelock of a Level 1 proposal.

The Direct-to-AIP process is a streamlined 2-step process: a forum post followed by an AIP. By removing the Snapshot vote, it shortens governance by 4 days and reduces governance burden. It is intended to expedite minor changes and can only be proposed by active Aave DAO Service Providers.

An active Service Provider can submit a Direct-to-AIP proposal that addresses one of the following areas:

Stewards assist the DAO in mitigating risk by making controlled, incremental exposure adjustments and responding quickly to changing market conditions without the delay of the full governance process. See Stewards for the current set of Steward contracts.

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

Each proposal must satisfy the public criteria of the Aave Risk Framework and the Technical Asset Listing Framework before it can advance.

New asset listings use the Standard Process and are expected to take 13 days. During the ARFC stage:

New listing candidates must deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.

The Existing Asset framework applies only to assets already listed on the Aave Protocol. Extending an existing asset to another instance follows the Direct-to-AIP process and can take as little as 5 days. The same Business Case, Risk Analysis, and Technical Analysis requirements apply before an AIP is published, with Risk and Technical Service Providers commenting on the proposed parameters and highlighting concerns such as bridges and liquidity. The same $150 deposit requirement applies.

New network deployments follow the Standard Process. The initial ARFC presents the business case and overall strategy, details the initial assets to be listed, and proposes a tentative market configuration. Given the early stage of most networks, some risk considerations, such as DEX liquidity assessments, are based on commitments made ahead of launch.

A single ARFC Snapshot authorises the deployment and can trigger up to three separate onchain AIP votes:

The a.DI and CCIP GHO Lanes votes are completed before the Protocol Activation AIP is published. A deployment without GHO omits the CCIP GHO Lanes vote. At least $150 worth of each listed asset must be deposited into the Aave Short Executor before the market goes live.

Voting in the Aave DAO allows AAVE, stkAAVE, and aAAVE holders to participate directly or delegate their voting power to representatives. Voting takes place both off-chain and onchain.

Off-chain votes take place in the Aave Snapshot Space and are binding on a proposal before it moves onchain. They allow token holders to participate without transaction fees, and enable the Aave DAO to make a public commitment to deliver something when there is a difference in timing or payment between when the commitment is made and when it is fulfilled.

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 through the Aave Governance Portal and other governance interfaces, including Boardroom. With Governance v3, it is possible to vote across multiple chains and cast gasless votes.

The onchain voting process has four stages:

For a proposal to succeed, at least 320,000 AAVE, stkAAVE, or aAAVE must participate in the vote, and the winning option must receive at least 320,000 votes.

The process includes several safeguards:

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 performed 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 be 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 community members who have received voting power from other community members or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have entrusted them with their voting power. Delegates are not compensated.

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 are specialised entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:

The Aave Guardians safeguard the protocol and the integrity of its governance. They operate as two independent multisigs with distinct mandates: the Protocol Emergency Guardian, which can pause markets and act in a protocol emergency, and the Governance Emergency Guardian, which can cancel malicious or erroneous governance proposals.

Across the DAO's emergency and treasury SAFEs, individual signer identities are increasingly withheld and held within organisation-controlled nested SAFEs, a deliberate practice to reduce attack surface.

The Protocol Emergency Guardian holds the EMERGENCY_ADMIN role in Aave V3 and equivalent roles in V2 and related systems, and is the failsafe emergency actor for cross-chain messaging in Emergency Mode. Its purpose is to act quickly in an emergency to protect the protocol, for example by pausing a market.

The Protocol Emergency Guardian is a 4 of 7 multi-signature wallet consisting of the following signers:

The Governance Emergency Guardian cancels governance proposals detected as malicious or containing errors, typically identified during the onchain verification stage by Certora. Speed is less critical for this role, since governance proposals unfold over several days, allowing adequate time for issues to be identified and addressed.

The Governance Emergency Guardian is a 4 of 7 multi-signature wallet consisting of the following signers:

Stewards enable high-cadence operational updates within tightly controlled bounds. Each steward is a DAO-owned contract with delegated authority over a narrow set of parameters or operations, bounded in magnitude and frequency by hard-coded and governance-set limits. Governance owns every steward and can revoke it at any time. The current stewards span risk parameters, the GHO stablecoin, treasury and finance operations, cross-chain bridging (in development), bad-debt maintenance, and oracle migration. The source code for GHO Steward contracts can be found on GitHub.

The current design is GHO Steward v2, a set of four modular contracts. Each is gated by a one-day timelock and a maximum change per update, and is callable only by the GHO Risk Council multisig 0x8513e6F37dBc52De87b166980Fa3F50639694B60, whose signers are TokenLogic, LlamaRisk, and Aave Labs.

Risk Stewards manage risk parameters within bounds defined by the Aave Risk Framework. They may tighten or calibrate only within these limits; loosening beyond them or releasing a freeze requires governance. The manual Risk Steward is operated by LlamaRisk together with Aave Labs, with a progressive migration to Chainlink Runtime Environment (CRE) automation. The Aave DAO retains full control of the automation.

The Risk Steward can adjust supply and borrow caps, collateral parameters (LTV, liquidation threshold, liquidation bonus), interest-rate parameters, CAPO price-cap and Pendle discount parameters, and e-mode collateral parameters. It cannot set caps, LTV, LT, or liquidation bonus to zero, change an e-mode's isolated flag or label, or act on restricted assets and oracles (for example, GHO on Ethereum).

The Freezing Steward can freeze a reserve immediately, blocking new supply and borrow while existing positions may still repay and withdraw. It cannot unfreeze; that requires governance.

Finance Stewards execute pre-approved, budgeted treasury operations on behalf of the DAO through contracts that act as admins of the Collector, without a full onchain vote. They are operated by the Aave Finance Committee (AFC), the 2 of 3 organisation-controlled multisig 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa. The DAO retains ownership and can revoke the role.

Horizon is configured through a delegated model rather than standard governance. The Executive role is assigned to Aave Labs, which manages day-to-day risk parameters, asset listings, oracle configuration, and supply and borrow caps directly, without an AIP vote for each change. The Aave DAO retains ownership of the contracts and controls upgrades, and still configures the GHO facilitator and credit line by governance vote.