title: [ARFC] Governance Framework v2
author: @TokenLogic
created: 2026-07-20
Summary
This publication presents an overview of the Aave DAO’s Governance Process v2 and, upon implementation, replaces the current Governance Process Document v1. v2 consolidates the governance process, presently spread across v1 and several newer frameworks, into a single canonical reference.
The mandatory TEMP CHECK stage of the governance process has been removed, and all role, guardian, and steward mandates have been refreshed to reflect the 2026 service provider landscape. Upon implementation, this framework streamlines the current 19-day process to 13 days, while ensuring risk and technical standards are upheld.
Motivation
Overview
Aave’s governance has matured into a lean, Service Provider model built for transparency and speed. This publication provides a holistic overview of Aave DAO’s governance processes and frameworks, designed to keep the DAO efficient, nimble, and structured. A focused group of service providers now delivers the core functions: Aave Labs on development and growth; LlamaRisk on risk; Certora on security; and TokenLogic on finance and growth.
This document supersedes the Governance Process Document v1 and shall be maintained over time, always reflecting the community’s current operational structure.
Rationale for retiring TEMP CHECK
One of the most significant efficiency improvements to the overall governance process presented here has been the retirement of TEMP CHECK from the standard path. With an emphasis on refining the economics of sequential adjustments in overall market risk, the initial intent to reduce workload on Risk and Technical service providers has been addressed. The process now begins with a business case to determine whether new assets or markets should be deployed.
Furthermore, since the Governance Process Document v1 was written, the DAO has adopted structured evaluation frameworks, notably the Aave Risk Framework and the Technical Asset Listing Framework, providing clear public criteria that each proposal must satisfy before it can advance. The ARFC stage provides a public discussion window followed by a binding Snapshot vote, providing the community retains a clear opportunity to shape, support, or reject a proposal without running two sequential sentiment rounds.
A notable distinction: the ARFC vote is binding, allowing 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.
Governance Process
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.
The processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE, stkAAVE, or aAAVE delegate. For more details, please refer to the official documentation.
Every type of governance action falls into one of three processes, based upon who they are implemented by:
- Standard Process: The default governance process consists of an ARFC governance proposal, a Snapshot vote and an on-chain vote to implement the upgrade. The Short Executor implements the vast majority of AIP proposals, with the Long Executor reserved for major upgrades.
- Direct-to-AIP Process: A refined on-chain voting process designed to enable simple parameter adjustments, not otherwise performed by Stewards, to be implemented quickly.
- Steward Process: This process facilitates high-cadence operational updates implemented by Service Providers within a tightly controlled, limited-access, and bounded environment, allowing the protocol to operate efficiently throughout the market cycle.
The gradual introduction of Steward roles allows for a growing portion of routine upgrades to shift from the Direct-to-AIP process to the Steward Process, streamlining the protocol’s operational readiness by enabling swift action and reducing administrative overhead. Token holders remain critical to shaping the future of business by retaining key decision-making power and electing to delegate daily operations to trusted actors who operate the Steward roles.
Standard Process
The standard governance process for the Aave DAO follows the guidelines outlined below:
Reference: Aave Governance. Adjust Level 2 requirements (long-executor)
-
Governance Forum - Aave Request for Comment (ARFC)
This is where initial discussions take place, and feedback is gathered. Service providers and community members provide detailed feedback over a 4-day period on how the proposal would affect the protocol, helping prepare it for the AIP stage.
-
Snapshot
ARFC voting takes place in the Aave Snapshot Space.
- Voting: If the proposal meets the required Snapshot threshold, it proceeds to the AIP stage; otherwise, it fails. Authors, proposition power, timing, and thresholds are detailed in the Voting section below.
-
Aave Improvement Proposal (AIP)
The AIP stage is where the proposal becomes a formal, on-chain 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 on-chain, the AIP is voted on through Aave’s governance contracts. The on-chain stages, quorum, and vote differential are described in the Voting section below.
- 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 1 day or 7 days) is imposed before the changes are implemented. Cross-chain proposals are executed using Aave’s Delivery Infrastructure (a.DI).
Long Executor
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. For the current thresholds and contract addresses, see the Aave governance documentation.
Direct-to-AIP Process
To support timely implementation of protocol upgrades via Token holder vote, the Direct-to-AIP governance process supports a streamlined 2-step process: a forum post followed by an AIP. By removing the Snapshot vote, the Direct-to-AIP process reduces the governance duration by 4 days and the governance burden. This process is intended to expedite minor changes and can only be proposed by active Service Providers. An illustration of the process is shown below:
To be eligible for this non-standard Tokenholder voter process, an Active Aave DAO Service Provider must submit a Direct-to-AIP proposal that addresses one of the areas mentioned below:
- Existing Asset Listing
- Existing Asset Parameter Update (excl. controlled by Stewards)
- Existing Rolling Maturity Asset Listing Eg: Pendle PTs
- Emission Manager updates
- Funding Updates
- Whitelist Flashloan Borrowers (remove fee)
- Technical Maintenance
- Whitelist addresses to claim rewards
- Extending SVR Integrations to new instances or assets
- Creation of new hubs and spokes on Aave V4 with existing assets
- Risk Parameters not amendable by Steward Role
Stewards Process
Stewards assist the DAO in mitigating potential risks by introducing controlled, incremental exposure adjustments and responding quickly to changing market conditions without the delay of the full governance process. The introduction of a steward role strictly enforces programmatic controls, allowing trusted actors to maintain precise parameters within the protocol, thereby fine-tuning it to prevailing market conditions and limiting exposure to adverse events. The principal rationale for introducing Stewards is to both mitigate risk through tightly controlled exposure limits on Assets and maintain operational readiness.
Each steward is a DAO-owned contract that features 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 Horizon instance is configured through a related delegated model, described at the end of this section.
GHO Stewards
The GHO Stewards manage the GHO stablecoin within bounded limits. The current design is GHO Steward v2, a set of four modular contracts, each gated by a one-day timelock and a maximum change per update, and each callable only by the GHO Risk Council. The GHO Risk Council multisig is 0x8513e6F37dBc52De87b166980Fa3F50639694B60, whose signers are TokenLogic, LlamaRisk, and Aave Labs.
GHO Aave Steward
Manages the GHO reserve in the Aave V3 core pool. It can adjust the GHO borrow and supply caps (up to +100% per update) and the four interest-rate parameters (optimal usage, base rate, slope 1, slope 2), each bounded to ±500 bps per update, with an overall borrow-rate ceiling of 25% APR. It cannot change collateral parameters, the oracle, or any non-GHO reserve. Cooldown: one day per parameter. Address: 0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34.
GHO Bucket Steward
Adjusts facilitator bucket capacities, the mint ceiling of each controlled facilitator, by up to +100% per update, and only for facilitators on its controlled list. Cooldown: one day per facilitator. Address: 0x46Aa1063e5265b43663E81329333B47c517A5409.
GHO GSM Steward
Manages the GHO Stability Module: the exposure cap (up to ±100% per update) and the buy and sell fees (up to ±0.50% per update). Freeze, unfreeze, and price-strategy changes are out of scope and require governance. Cooldown: one day per GSM per parameter. Address: 0xD1E856a947CdF56b4f000ee29d34F5808E0A6848.
GHO CCIP Steward
Manages the cross-chain (Chainlink CCIP) parameters for GHO: the bridge limit and the inbound and outbound rate limits, each bounded to ±100% per update. Cooldown: one day per parameter. Address: 0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39.
Risk Stewards
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. Following the departure of Chaos Labs, 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.
Risk Steward
The main risk steward. It can adjust supply and borrow caps, collateral parameters (LTV, liquidation threshold, liquidation bonus), interest-rate parameters (base rate, slope 1, slope 2, optimal usage), 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). Per-update bounds and cooldowns:
| Parameter | Max change per update | Minimum delay | Pending change (ARFC) |
|---|---|---|---|
| LTV, LT, LB | 0.5% absolute change | 72 hours | - |
| Emode - LTV, LB | 0.5% absolute change | 72 hours | - |
| Emode - LT | 0.1% absolute change | 72 hours | - |
| Base rate, Slope 1 | 1% absolute change | 72 hours | 36h |
| Slope 2 | 20% absolute change | 72 hours | 36h |
| Optimal Usage Ratio | 3% absolute change | 72 hours | 36h |
| Supply and borrow caps | 100% relative change | 72 hours | 36h |
| CAPO Dynamic Cap | 5% relative change | 72 hours | - |
| CAPO Stable Cap | 0.5% relative change | 72 hours | - |
| PT Discount Rate | 2.5% absolute change | 48 hours | - |
Reference: [ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment
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. A tighten-only safeguard.
Finance Stewards
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 on-chain vote. They are operated by the Aave Finance Committee (AFC), the multisig 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa, a 2-of-3 organisation-controlled multisig. The DAO retains ownership and can revoke the role.
Mainnet Swap Steward
Live. Executes treasury token swaps via the CoW Protocol with a Chainlink oracle price check and slippage bounds, supporting market, limit, and TWAP orders, as well as order cancellation. It can only swap into DAO-whitelisted tokens, within per-token budgets, and proceeds always return to the Collector. Address: 0xb7D402138Cb01BfE97d95181C849379d6AD14d19.
Pool Exposure Steward
Live. Migrates assets from Aave V2 to V3, and deposits or withdraws Collector funds within Aave V3. It cannot move funds outside approved Aave pools or deplete a reserve below its minimum floor. Address: 0x22aC12a6937BBBC0a301AF9154d08EaD95673122.
Collector Budget Steward
Transfers or streams Collector tokens to pre-approved recipients within DAO-defined budgets. It cannot send to non-whitelisted addresses or exceed a budget.
Rewards Steward
Live. Claims liquidity-mining and Merit rewards accrued to the Collector and forwards them to the Collector. It holds no discretionary transfer power, and must first be granted claim rights by the Emission Manager.
Bridge Stewards
In development, not yet live. A family of per-route stewards (Polygon, Arbitrum, Optimism, plus CCTP and LayerZero routes) that will move Collector funds cross-chain back to the Ethereum Collector without a full a.DI governance vote. This fills a gap the Pool Exposure Steward cannot cover, since that steward only moves funds within a single chain. Operators will be set at deployment.
Maintenance Stewards
Clinic Steward
Live. Batch-liquidates dust and underwater positions and repays accumulated bad debt, funded from the Collector, within a fixed USD budget cap that only an admin can raise. It cannot act outside repayment, liquidation flows, or exceed the budget. Address: 0xf00E2de0E78DFf055A92AD4719a179CE275b6Ef7.
Deficit Offset Clinic Steward
Live. The Umbrella-linked sibling of the Clinic Steward, used to offset reserve deficits through Umbrella’s deficit-elimination flow. Address: 0x6c1DC85f2aE71C3DAcd6E44Bb57DEeF61b540a5A.
SVR Oracle Steward
Live. Migrates an asset to a Chainlink Smart Value Recapture (SVR) price feed only when its deviation from the current feed is minimal, and lets the Protocol Guardian revert to the previous feed if needed. Address: 0x8b493f416F5F7933cC146b1899c069F2361cad60.
Horizon
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 it still configures the GHO facilitator and credit line by governance vote. Reference: [ARFC] Horizon’s RWA Instance.
Voting
Once a proposal meets the required conditions, it can proceed to the voting stages, which include both off-chain and on-chain voting methods. Voting in the Aave DAO allows AAVE, stkAAVE, and aAAVE holders to participate directly or delegate their voting power to representatives.
Off-Chain
Off-chain votes take place in the Aave Snapshot Space and are the community’s directionally binding signal on a proposal before it moves on-chain. They allow token holders to participate without incurring transaction fees. The off-chain voting stage enables the Aave DAO to make a public commitment to deliver something when there is a difference in timing and/or payment between when the business says it will do something and when that commitment is fulfilled.
Authors and proposition power. To open a Snapshot vote, the author must be on the approved list of Authors for the Aave space, or hold at least 80,000 AAVE of proposition power. This filters spam while allowing recognised service providers and delegates to propose without holding a large balance.
Controller. The administration of the Aave DAO Snapshot space is carried out by the Aave Finance Committee SAFE 0x22740deBa78d5a0c24C58C740e3715ec29de1bFawhilst the Controller is configured to 0x9F8F33e0e22F747617654A50305e61AA9811070C, held by Aave Labs as contingency.
Voting power. Voting weight is the combined balance of AAVE, stkAAVE, and aAAVE that an address holds or has been delegated, measured at the snapshot block taken when the vote opens. Holders can vote directly or delegate their power to a representative.
Timing and threshold. Once submitted, a Snapshot enters a one-day voting delay, followed by a three-day voting period. A 320,000 AAVE threshold applies: if it is met, the proposal proceeds to the AIP stage; if not, the proposal fails.
For further detail, see the Aave governance documentation.
On-Chain
On-chain voting is required on any Aave Improvement Proposal. Aave on-chain voting will take place on the Aave Governance Portal. With the launch of V3 governance, it is now possible to vote across multiple chains and cast gasless votes.
The on-chain voting process is composed of four stages:
- First, the proposal and payload are reviewed by Security Service Providers to ensure they are not malicious and don’t contain errors that could put the protocol at risk.
- The second stage is entered if no errors or a malicious payload are identified, and the proposal is moved on-chain. Once the proposal is on-chain, a 1-day voting delay must pass before it becomes active.
- In the third stage, once the voting delay has elapsed, the proposal becomes active and available for voting. This stage lasts for 3 days.
- In the fourth stage, once the voting period has ended, the proposal will be either SUCCEEDED or FAILED, depending on whether it has reached quorum and received a majority of YAE votes. In this stage, if the proposal has passed, the payload is queued with a 1-day timelock; once this has elapsed, the payload may be executed. If the proposal is not executed before the end of the 7-day grace period, it expires and must be deployed and voted on again at the start of the on-chain voting process.
A visual representation of this flow is shown in the figure below.
Quorum
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.
- Quorum-failure rule: a proposal that fails the Snapshot vote due to a lack of quorum, rather than due to a rejecting majority, may reopen the Snapshot once without restarting from the ARFC stage.
- Anti-spam brake: the proposition power and whitelist gate at Snapshot submission.
- Final token-holder break: the on-chain AIP vote and the one-day timelock.
- Malicious-proposal backstop: the Governance Emergency Guardian retains its power to cancel.
Governance Frameworks
The Aave DAO has predefined frameworks for common types of proposals, simplifying the governance process:
Asset Onboarding Framework
Standardised lifecycle for onboarding new assets to the protocol, providing a structured process for risk assessments and community discussions.
Onboarding the right assets is one of the most direct levers the DAO has for growth. Each new asset can deepen liquidity, expand borrowing demand and protocol revenue, extend GHO’s reach, and unlock integrations and user acquisition. The framework makes that growth deliberate: assets are prioritised by verifiable demand, credible commitments, and strategic fit with the wider Aave business, and are onboarded only once they meet the DAO’s risk and technical standards. The below outlines the asset onboarding and expansion process:
New Asset Listing
The New Asset listing framework uses the Standard Process to list assets on the Aave Protocol for the first time if they have not been listed previously. Introducing a new asset to the Aave Protocol increases the risk surface area and requires rigorous assessment to ensure there is a strong business case for onboarding it.
Onboarding a new asset is expected to take 13 days following the Standard Process.
The Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.
Asset Listing ARFC Process
During the ARFC stage, a clear business case for onboarding the asset must be provided; the asset then undergoes Risk Analysis and a Technical Assessment to verify its suitability for listing on the Aave Protocol.
-
Business Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the listing proposal on the governance forum. It presents a clear, validated case for onboarding the asset, including the proposed initial market structure and parameters, and explains how the asset fits the DAO’s broader strategy. Where relevant, it sets out the commitments supporting the listing, such as expected user deposits and debt, incentive budget, liquidity, and planned integrations.
-
Risk Analysis: The Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.
- Risk Assessment: A thorough review of the risks associated with the asset, covering market risk (volatility, liquidity, and secondary-market depth across market conditions), the asset’s historical performance and susceptibility to market fluctuations, and asset-specific legal and compliance considerations. For coinciding asset listings with product launches,
- Reference: [ARFC] Aave Risk Framework
Any material finding, such as insufficient DEX liquidity, pauses the listing until it is resolved.
-
Technical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the asset’s technical and security profile.
- Technical Assessment: A rigorous review of the asset’s contracts, oracle configuration, access controls, and dependencies, against the requirements of the Technical Asset Listing Framework.
- Reference: [ARFC] Technical Asset Listing Framework
Any finding that falls short of Aave’s security standards pauses the listing process until the issue is resolved.
Existing Asset Listing
The Existing Asset listing framework applies only to assets already listed on the Aave Protocol; identical assets (syrupAssets) shall follow the Direct-to-AIP process when extending assets to other instances of the Aave Protocol.
Adding an Existing Asset to an instance of the Aave Protocol is expected to take as little as 5 days following the Direct-to-AIP process.
The Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.
Existing Asset Direct-to-AIP Process
Similar to the New Asset Listing framework, each of the three requirements must be met before an AIP is published: Business Case, Risk Analysis and Technical Analysis. Upon completing sufficient due diligence and assessing the expected returns, an AIP shall be published.
Similar to the Asset Listing ARFC process, the Direct-to-AIP shall present the business case for adding the asset to another instance of the Aave Protocol, ensuring a rationale for the listing. In the comments section, Risk and Technical Service Providers are to provide commentary on the proposed parameter configuration and highlight any concerns, including additional dependencies (e.g., bridges) and liquidity considerations.
New Network Deployment Framework
Deploying on a new network extends Aave’s liquidity footprint and revenue base, carries GHO into new ecosystems, and positions the protocol where users, partners, and capital are moving. Because a deployment is a larger commitment than a single listing, the framework weighs the network’s liquidity potential, GHO utility, revenue and integration commitments, and partner distribution before the DAO commits.
The New Network Deployment Framework follows the Standard Process for determining whether to deploy a new Aave Protocol instance. This framework provides a transparent approach for evaluating and deploying new instances of the Aave Protocol. The initial ARFC publication focuses on the business case and overall strategy supporting the deployment.
A single ARFC Snapshot authorises the deployment and can trigger up to three separate on-chain AIP votes. For a deployment with GHO these are: (1) a.DI Path Activation, which registers the Aave Delivery Infrastructure for the new network; (2) CCIP GHO Lanes Activation, which activates the GHO lane on Chainlink’s CCIP; and (3) the Aave Protocol Activation, which brings the market live. 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, so only the a.DI Path Activation precedes the Protocol Activation.
The Aave DAO requires that at least $150 worth of each listed asset be deposited into the Aave Short Executor before the market goes live.
New Network Deployment ARFC Process
Following the Standard Process, at the ARFC stage, a clear business case for deploying the Aave Protocol on the network is to be presented to the community. The ARFC publication shall also detail the initial assets to be listed and present a tentative market configuration for discussion.
Given the early stage of most networks at the time the Aave Protocol is deployed, some risk considerations, such as DEX liquidity assessments, are based on commitments to provide flexibility in the lead-up to launch.
-
Business Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the deployment proposal on the governance forum. It presents a clear, validated case for deploying the Aave Protocol on the network, together with the proposed initial market structure: the assets to be listed, their tentative parameters, and how the deployment fits the DAO’s broader strategy. Where relevant, it also sets out the commercial terms supporting the deployment, including the incentive budget, liquidity and integration commitments, GHO utility, and the availability of Chainlink Oracle and CCIP infrastructure.
-
Risk Analysis: Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.
- Risk Assessment: A thorough review of the risks associated with the network and its initial assets, covering chain-level risk (network maturity, decentralisation, and reliability), market risk (asset volatility, liquidity, and secondary-market depth), and asset-specific legal and compliance considerations. Given the early stage of most networks at deployment, some assessments, such as DEX liquidity, may rely on commitments made ahead of launch.
- Reference: [ARFC] Aave Risk Framework
Any material finding pauses the deployment until it is resolved.
-
Technical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the network’s technical and security profile and that of each listed asset.
- Technical Assessment: A rigorous review of the network’s technical and security details, the a.DI (Aave Delivery Infrastructure) integration, oracle and CCIP availability, and each asset’s contract and oracle configuration.
- Reference: [ARFC] Technical Asset Listing Framework
Any finding that falls short of Aave’s security standards pauses the deployment until it is resolved.
Direct-to-AIP Framework
The purpose of the Direct-to-AIP framework is to enable non-controversial, precise parameter updates to the protocol to be implemented quickly. Within the Aave Protocol, there are a number of parameters or access that can be granted that are not currently supported by Steward roles. The Direct-to-AIP provides a means of quickly updating those parameters and of processing routine, non-controversial operational matters.
Governance Roles
Delegates & Delegators
Delegates
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
Delegators are community members who hold Aave, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another person. The person to whom they delegate their voting power is considered a delegate. This system allows delegators to have their interests represented in governance decisions without having to participate directly in every vote.
Contributors and Service Providers
Contributors
Contributors are community members who participate in and dedicate their time to the Aave DAO. They contribute by joining working groups, fulfilling bounties, building on top of the Aave Protocol, or working for the DAO via grants. Contributors work towards completing shared goals that benefit the Aave ecosystem.
Service Providers
Service providers are specialised entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:
- LlamaRisk, risk service provider
- Certora, security service provider
- TokenLogic, finance and growth service provider
- Aave Labs, development and growth service provider
Guardians
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 (see the June 2026 signer and SAFE configuration update).
For more information on the Guardians’ permissions, refer to this detailed view of permissions in Aave systems. For a general overview of their role, see the Medium post about Aave V2 Governance here.
Protocol Emergency Guardian
This Guardian holds the EMERGENCY_ADMIN role in Aave V3 and equivalent roles in V2 and related systems. Its purpose is to act quickly in an emergency to protect the protocol, for example by pausing a market. Following the May 2026 signer rotation, it operates as a 4-of-7 multisig, and to reduce its attack surface, the signer identities are not publicly disclosed. The current signer addresses are listed below.
| Protocol Emergency Guardian (4-of-7) | Signer address |
|---|---|
| Signer 1 | 0x4Ab2Bed1d667260dB34244Ba412817651C2dD52b |
| Signer 2 | 0xc2674C1A1aF0557E1d217fF4F13DF44A637c7C13 |
| Signer 3 | 0xe6838d834674eC35EDd53D485770Baa10bdd6AAe |
| Signer 4 | 0xb291232F480F41c75802C4a60F1D2AC03404Afef |
| Signer 5 | 0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E |
| Signer 6 | 0xa2DCdD6e0b5e0d118E2Fa8922552AC0Fe26EFe58 |
| Signer 7 | 0x3fa960f8355D00874D9C7E3350147f5E94859bc2 |
Governance Emergency Guardian
This Guardian is responsible for cancelling governance proposals if they are detected as malicious or contain errors, typically identified during the on-chain verification stage by Certora. Unlike the Protocol Emergency Guardian, speed is less critical for this role since governance proposals unfold over a period of five days, allowing adequate time for issues to be identified and addressed. The multi-sig configuration for this Guardian is also a 5-of-9 setup. The current Governance Guardians are shown in the table below and were updated in this ARFC Addendum.
| Governance Emergency Guardian | Address |
|---|---|
| Seb (Zapper) | 0xa1c9ceed5ff78f700dc4930514621843b5fac272 |
| Mounir (Paraswap) | 0xfd639f49Da6cadc98f01B60900C8BE30C38c4B27 |
| Gavi Galloway (Standard Crypto) | 0xbd4DCfA978c6D0d342cE36809AfFFa49d4B7f1F7 |
| Nenad (Defi Saver) | 0xDA5Ae43e179987a66B9831F92223567e1F38BE7D |
| Fernando (Balancer) | 0x4C30E33758216aD0d676419c21CB8D014C68099f |
| Roger (Chainlink community) | 0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396 |
| Mariano Conti (DeFi OG) | 0x936CD9654271083cCF93A975919Da0aB3Bc99EF3 |
| Marin (Lido) | 0x0D2394C027602Dc4c3832Ffd849b5df45DBac0E9 |
| Certora | 0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9 |
Templates
The standard ARFC templates are collected here for reference. When drafting a proposal, copy the relevant template and adapt it to the specific asset, network, or change.
Asset Listing ARFC Template
Title: [ARFC] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD
Summary
This ARFC proposes onboarding to the Aave instance on the .
Motivation
Explain the motivation for listing the Token.
-
Business Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.
- A general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.
At the pre-screening stage, the asset’s AAcA category is expected to be confirmed, and assets in an unapproved or unsanctioned category should not proceed.
Reference: [ARFC] Endorse the Asset Classification Framework (AAcA)
The initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.
Specification
Ticker:
Contract address:
Chainlink oracle:
| Parameter | v3 | v4 | Value |
|---|---|---|---|
| Network | Yes | Yes | |
| Instance of Aave Protocol | Yes | Yes | |
| Hub (Core / Prime / Plus) | n/a | Yes | |
| Spoke / Spoke type | n/a | Yes | |
| Isolation Mode | Yes | n/a | |
| Debt Ceiling | Yes | n/a | |
| Siloed Borrowing | Yes | n/a | |
| Borrowable in Isolation | Yes | n/a | |
| Borrowable | Yes | Yes | |
| Collateral enabled / Collateral-only | Yes | Yes | |
| Supply Cap (v3) / Add Cap (v4) | Yes | Yes | |
| Borrow Cap (v3) / Draw Cap (v4) | Yes | Yes | |
| Credit Line Size / Draw Cap | n/a | Yes | |
| LTV | Yes | n/a | |
| Liquidation Threshold (LT) | Yes | n/a | |
| Collateral Factor (CF) | n/a | Yes | |
| Liquidation Bonus | Yes | n/a | |
| Max Liquidation Bonus | n/a | Yes | |
| Liquidation Bonus Factor | n/a | Yes | |
| Health Factor for Max Bonus | n/a | Yes | |
| Liquidation Protocol Fee | Yes | Yes | |
| Collateral Risk (bps) | n/a | Yes | |
| Variable Base | Yes | Yes | |
| Slope 1 | Yes | Yes | |
| Slope 2 | Yes | Yes | |
| Uoptimal | Yes | Yes | |
| Reserve Factor (v3) / Liquidity Fee (v4) | Yes | Yes | |
| Oracle Type (Chainlink SVR / CAPO / Pendle) | Yes | Yes | |
| CAPO: Max Yearly Ratio Growth % | Yes | Yes | |
| CAPO: Minimum Snapshot Delay | Yes | Yes | |
| Price Cap (stablecoin / CAPO) | Yes | Yes | |
| Pendle: Discount Rate / Max per year | Yes | Yes | |
| Flashloanable | Yes | Yes | |
| E-Mode Category (v3) / E-Mode Spoke (v4) | Yes | Yes |
Disclaimer
Statement of the author’s potential conflict of interest and relationship with the asset protocol, and if they received compensation for publishing this proposal
Next Steps
- If consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage.
- If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal
Copyright
Copyright and related rights waived via CC0.
Asset Listing ARFC Template
Title: [Direct-to-AIP] Template
Author:
Date: 2026-06-06
Summary
A brief sentence or two introducing the proposal’s topic. Specifically, the parameters to be updated, which instance of the Aave Protocol and which chains are affected.
Motivation
This section outlines the reasoning, often supported by a business case and supporting analysis, allowing voters to make an informed decision at the time of the vote.
Where applicable, include:
- The problem or opportunity being addressed.
- The rationale for the proposed changes.
- Supporting analysis, research, or market data.
- Expected impact on protocol performance, capital efficiency, risk, or user experience.
- Any relevant business, technical, or governance considerations.
This section should focus on why the proposal should be implemented, while the Specification section describes how it will be implemented.
For assets extended to other instances of the Aave Protocol, as with the original ARFC to list the asset, this section shall include the Business Case supporting the listing. Please see the earlier section for further details.
Specification
A summary of the technical changes to be implemented at the AIP stage.
This section should include all information necessary to construct the governance payload, including, where applicable:
- Markets and networks affected.
- Assets affected.
- Current values.
- Proposed values.
- Smart contracts or protocol components impacted.
- Any implementation or execution considerations.
Disclaimer
The author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this Direct-to-AIP proposal.
Next Steps
- Publish an AIP vote for final confirmation and on-chain enforcement of the proposal.
Copyright
Copyright and related rights waived via CC0.
Existing Asset Listing Direct-to-AIP Template
Title: [Direct-to-AIP] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD
Summary
This Direct-to-AIP proposes onboarding to the Aave instance on the .
Motivation
Explain the motivation for onboarding this asset to another instance of the Aave Protocol.
-
Business Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.
- A general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.
The initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.
Reference: [ARFC] Endorse the Asset Classification Framework (AAcA)
Specification
Ticker:
Contract address:
Chainlink oracle:
| Parameter | v3 | v4 | Value |
|---|---|---|---|
| Network | Yes | Yes | |
| Instance of Aave Protocol | Yes | Yes | |
| Hub (Core / Prime / Plus) | n/a | Yes | |
| Spoke / Spoke type | n/a | Yes | |
| Isolation Mode | Yes | n/a | |
| Debt Ceiling | Yes | n/a | |
| Siloed Borrowing | Yes | n/a | |
| Borrowable in Isolation | Yes | n/a | |
| Borrowable | Yes | Yes | |
| Collateral enabled / Collateral-only | Yes | Yes | |
| Supply Cap (v3) / Add Cap (v4) | Yes | Yes | |
| Borrow Cap (v3) / Draw Cap (v4) | Yes | Yes | |
| Credit Line Size / Draw Cap | n/a | Yes | |
| LTV | Yes | n/a | |
| Liquidation Threshold (LT) | Yes | n/a | |
| Collateral Factor (CF) | n/a | Yes | |
| Liquidation Bonus | Yes | n/a | |
| Max Liquidation Bonus | n/a | Yes | |
| Liquidation Bonus Factor | n/a | Yes | |
| Health Factor for Max Bonus | n/a | Yes | |
| Liquidation Protocol Fee | Yes | Yes | |
| Collateral Risk (bps) | n/a | Yes | |
| Variable Base | Yes | Yes | |
| Slope 1 | Yes | Yes | |
| Slope 2 | Yes | Yes | |
| Uoptimal | Yes | Yes | |
| Reserve Factor (v3) / Liquidity Fee (v4) | Yes | Yes | |
| Oracle Type (Chainlink SVR / CAPO / Pendle) | Yes | Yes | |
| CAPO: Max Yearly Ratio Growth % | Yes | Yes | |
| CAPO: Minimum Snapshot Delay | Yes | Yes | |
| Price Cap (stablecoin / CAPO) | Yes | Yes | |
| Pendle: Discount Rate / Max per year | Yes | Yes | |
| Flashloanable | Yes | Yes | |
| E-Mode Category (v3) / E-Mode Spoke (v4) | Yes | Yes |
Disclaimer
The author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this ARFC.
Next Steps
- Publish an AIP vote for final confirmation and on-chain enforcement of the proposal.
Copyright
Copyright and related rights waived via CC0.
New Network Deployment ARFC Template
Title: [ARFC] Deploy Aave on
Author:
Date: YYYY-MM-DD
Summary
This ARFC proposes deploying the Aave Protocol to the .
Motivation
Provide a comprehensive overview of the new deployment, including its technical features, security measures, and any unique benefits it brings to the Aave ecosystem. This section will focus on the following key areas:
-
Network Capabilities: Transactions per second, latency, finality, scalability, security and interoperability.
-
Market Positioning: Details what makes this network unique from technical, user distribution, focus areas, and/or strategic alignment perspectives, with the goal of distinguishing this network from others.
-
Business Case: This details the core value proposition for deploying the Aave Protocol on the respective network. The business case will take into consideration the effects of future liquidity, user adoption, market growth, strategic positioning and revenue potential, with a clear vision for the market over time.
The following presents a non-exhaustive list of key areas for consideration when compiling the business case:
- Incentive Budget.
- Liquidity commitments.
- GHO utility beyond the Aave Protocol.
- Revenue commitment.
- Integration commitments.
- Partner’s distribution potential.
- Availability of Chainlink’s Oracle and CCIP capabilities.
To support Tokenholders making a fully informed decision, the commercial terms supporting the deployment are to be clearly communicated while respecting any non-public information limitations.
-
Useful Links: Any additional information that can help Aave DAO to decide. This may include recent announcements, links to documentation, a roadmap for network and ecosystem development, and plans.
Specification
This section contains the initial market structure, assets to be included and how the protocol is to be configured. The initial proposed parameters for the deployment should take into account any Unique Selling Points and desired go-to-market strategies, and be configured/positioned to attract users under prevailing market conditions.
| Parameter | Asset 1 | Asset 2 | Asset 3 |
|---|---|---|---|
| Asset | wstETH | WETH | USDT0 |
| Borrowable | |||
| Collateral Enabled | |||
| Supply Cap | |||
| Borrow Cap | |||
| Debt Ceiling | |||
| LTV | |||
| LT | |||
| Liquidation Bonus | |||
| Liquidation Protocol Fee | |||
| Variable Base | |||
| Variable Slope1 | |||
| Variable Slope2 | |||
| Uoptimal | |||
| Reserve Factor | |||
| Stable Borrowing | |||
| Flashloanable | |||
| Siloed Borrowing | |||
| Borrowable in Isolation | |||
| E-Mode | 1 | 1 |
E-Mode Configurations
wstETH Correlated #1
| Parameter | Value | Value |
|---|---|---|
| Asset | wstETH | WETH |
| Collateral | Yes | No |
| Borrowable | No | Yes |
| Max LTV | 94.00% | - |
| Liquidation Threshold | 96.00% | - |
| Liquidation Bonus | 1.00% | - |
CAPO
| Asset | maxYearlyRatioGrowthPercent | ratioReferenceTime | MINIMUM_SNAPSHOT_DELAY |
|---|---|---|---|
| wstETH | 9.68% | Monthly | 7 |
Disclaimer
A statement of the author’s potential conflicts of interest, their relationship with the network or asset issuers, and whether they received compensation for publishing this proposal.
Next Steps
- Community Engagement: Engage with the Aave community to gather feedback on the proposed framework for the new Aave Protocol deployment.
- ARFC Snapshot: If community sentiment is favourable, initiate an ARFC snapshot to gauge official support for the framework.
- Implementation: If the Snapshot vote passes, the proposal as outlined shall be implemented by the respective Service Providers.
Copyright
Copyright and related rights waived under CC0.
References
Aave Governance Process Document v1
[ARFC] Aave Governance. Adjust Level 2 requirements (long-executor)
[ARFC] Update the Asset Onboarding Framework
[ARFC Addendum] Update Asset Onboarding Framework
[ARFC] Technical Asset Listing Framework
[ARFC] Direct-to-AIP Framework
[ARFC] New Chain Deployment Framework
[ARFC ADDENDUM] Mandatory Disclosures and Conflict-of-Interest Voting Norms
[ARFC] Aave Risk Framework
[ARFC] Emission Manager Framework Update
[ARFC] Aave V3 Caps update Framework
Disclosure
TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.
TokenLogic supports and maintains an independent delegate voting platform within the Aave community.
TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.
Next Steps
- Gather feedback from the community.
- If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.
- If the Snapshot outcome is YAE, this proposal will be implemented.
Copyright
Copyright and related rights waived via CC0.