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.
Processes
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.
Proposal Lifecycle
Governance Forum The proposal process begins with an idea introduced to the Aave Governance Forum. This is where initial discussions take place and feedback is gathered. The community helps refine the proposal before moving to the next stage.
Temp Check (Snapshot Voting) After discussion, the proposal proceeds to a TEMP CHECK via the Aave Snapshot Space. This informal vote gauges community sentiment. TEMP CHECK votes are non-binding but help determine if there is sufficient interest in moving forward. Proposals in this stage do not require detailed technical specifics.
ARFC (Aave Request for Final Comments) If the TEMP CHECK passes, the proposal moves to the ARFC stage, where it undergoes more formal scrutiny. Service providers and community members contribute detailed feedback on how the proposal would impact the protocol, preparing it for the AIP stage. ARFC voting also occurs on the Aave Snapshot Space.
AIP (Aave Improvement Proposal) The AIP stage is where the proposal becomes a formal, onchain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Aave's governance contracts, primarily on the Ethereum Mainnet.
Voting Once submitted, the AIP enters a PENDING status before becoming ACTIVE for voting. Voting is conducted onchain through Aave governance contracts. A proposal succeeds if it meets quorum and vote differential requirements. If these thresholds aren’t met, the proposal fails.
Execution A successful proposal moves to the execution phase, where it is enacted via Aave's governance infrastructure. Depending on the type of proposal, a timelock delay (either one day or 7 days) is imposed before the changes are implemented. Cross-chain proposals are executed using Aave's Delivery Infrastructure (a.DI).
Voting Overview
Off-chain Voting (Snapshot)
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.
Onchain Voting (Governance Interfaces)
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.
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.
Proposal Frameworks
Aave has predefined frameworks for common types of proposals, simplifying the governance process:
Caps Update Framework: Direct-to-AIP process for adjusting caps or freezing reserves.
Asset Onboarding Framework: Standardised lifecycle for onboarding new assets to the protocol.
New Chain Deployment Framework: Guidelines for deploying Aave on new blockchains.
Emission Manager Framework: Simplified process for adding emission admins to reserves.
These frameworks streamline governance and allow the community to focus on more complex issues while maintaining the protocol's security and adaptability.
Community
Delegates
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
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
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
Service providers offer essential services to the protocol, such as risk management, financial oversight, security, and development. Examples of service providers include:
Chaos Labs (Risk)
Llamarisk (Risk)
Karpatkey (Finance)
Certora (Security)
Tokenlogic (Finance)
BGD Labs (Development)
ACI (Growth and Business Development)
Aave Labs (Development)
Guardians
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.
Protocol Emergency Guardian
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:
Chaos Labs (risk service provider)
Llamarisk (risk service provider)
Karpatkey (finance service provider)
Certora (security service provider)
Tokenlogic (finance service provider)
BGD Labs (development service provider)
ACI (growth and business development service provider)
Ezr3al (Aave DAO delegate)
Stable Labs (Aave DAO delegate)
Governance Emergency Guardian
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:
Seb (Zapper)
Mounir (Paraswap)
Gavi Galloway (Standard Crypto)
Nenad (Defi Saver)
Fernando (Balancer)
Roger (Chainlink community)
Mariano Conti (DeFi OG)
Marin (Lido)
Certora (security service provider)
Stewards
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.
GHO Bucket Steward
| Parameter | Description | |
|---|---|---|
| Facilitator Bucket Capacity | Up to 100% increase |
GHO Aave Steward
| Parameter | Description | |
|---|---|---|
| GHO Borrow Cap | Up to 100% increase or decrease | |
| GHO Borrow Rate | Up to 5% change to optimalUsageRatio, baseVariableBorrowRate, variableRateSlope1, and variableRateSlope2 with maximum of 25% | |
| GHO Supply Cap | Up to 100% increase |
GHO CCIP Steward
| Parameter | Description | |
|---|---|---|
| Bridge Limit | Up to 100% increase or decrease | |
| Rate Limit | Up to 100% increase or decrease |
GHO Stablility Module Steward
| Parameter | Description | |
|---|---|---|
| GSM Exposure Cap | Up to 100% increase | |
| GSM Buy/Sell Fees | Up to 0.5% increase or decrease |
Risk Steward
| Description | Value | |
|---|---|---|
| Frequency of change | 5 days | |
| Maximum supply cap increase | 50% | |
| Maximum borrow cap increase | 50% |