Aave Governance Process Document v1
Authors: ACI
Date: 2024-08-08
Introduction
The “Aave Governance Process’’ is an all-in-one document for contributing to Aave DAO. This document will be continuously updated by Aave DAO contributors. The previous version is available here: Aave Finance Governance Process v0
This document provides an overview of the different roles, flow and pathways for various stakeholders to participate in Aave DAO.
Governance Processes
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.
At a high level the Aave governance process is composed of five stages, from temp check forum dicussion to on-chain votes. The stages are as follows: temp check forum post, temp check snapshot, ARFC forum post, ARFC snapshot, AIP on-chain vote. A standard proposal will take a minimum of 19 days to pass through all of these stages, although it is uncommon that it progresses this quickly as time is needed for writing and reviewing payloads, and there are timelocks and other waiting periods relating to the various voting stages.
Proposal types
There are generally three main types of proposals in Aave Governance; these three general proposal classifications strictly refer to the maturity of a proposal in the Aave Governance Process. In specific situations, in order to minimise governance burden and increase speed, there are streamlined versions of this process. These situations are described in a later section.
- TEMP CHECK: These serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high level of precision or technicality.
- TEMP CHECK Snapshot: This is an off-chain vote using the Snapshot platform, with voting starting after the TEMP CHECK discussion period has ended.
- ARFC: Aave Request for Comment (ARFCs) are precursors to Aave Improvement Proposals (AIPs). Relevant service providers are formally invited to provide feedback on them, and the specification section of ARFCs should detail how the potential upcoming AIP will impact Aave protocol smart contracts.
- ARFC Snapshot: This is an off-chain vote using the Snapshot platform, with voting starting after the ARFC discussion period has ended.
- AIP: Aave Improvement Proposal (AIPs) are a formal proposal to improve the Aave Protocol; before submitting an AIP, an ARFC should be submitted to the community to gather feedback. Once the AIP has been written and reviewed, the AIP will be submitted via GitHub to begin the process of putting the AIP on-chain.
General proposal process
As pictured below, the standard proposal process is as follows:
- Post a Temp Check for 5 days to allow discussion and gauge sentiment.
- Temp Check Snapshot vote for 3 days.
- Post an ARFC for 5 days to allow for closer scrutiny and discussion.
- Post an ARFC Snapshot vote for 3 days.
- Post an AIP vote for 3 days.
This process takes around 19 days at a minimum, but often takes longer due to backlogs and time taken for writing and reviewing payloads, there are also various timelocks and waiting periods relating to the voting stages which extend this minimum timeframe. It should also be noted that ACI Skyward can help tokenholders to ensure the governance process proceeds smoothly and efficiently.
Standard governance process
Proposal Discussion
As part of the governance process, a discussion must be started on the Aave Governance Forum, as shown in the diagram above there are two rounds of discussion, firstly as a Temp Check, and then as an ARFC if the Temp Check Snapshot passes.
Once the proposal has been posted on the forum, it must:
- Be available for review and comment for a minimum of five days.
- Contain all relevant information that would be contained in the AIP
- Comply with any relevant templates that apply to the proposal.
The proposal author may decide to modify the proposal based on feedback during the discussion phases.
Moving to Vote
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 voting (Snapshot): Off-chain votes are used to gauge the sentiment for Temp Checks and ARFCs. The off-chain voting period lasts 3 days for both Temp Check and ARFC votes.
On-chain (Native): On-chain voting is required on any Aave Improvement Proposal. Aave on-chain votes will occur on the Aave Governance Portal. The voting period must last for a minimum period of 3 days. With the launch of V3 governance, it is now possible to vote across multiple chains and carry out gasless voting, read more here.
The on-chain voting process is composed of four stages:
- First of all, the proposal and payload are reviewed by Security Service Providers to ensure that it is not malicious and that it doesn’t contain errors which put the protocol at risk.
- The second stage is entered if no errors or malicious payload are identified, and the proposal is moved on-chain. Once the proposal is on-chain, a voting delay of 1 day must pass before the proposal becomes active.
- In the third stage, once the voting delay has elapsed the proposal becomes active and is available to be voted on. This stage lasts for 3 days.
- In the fourth stage, once the voting period has ended, the proposal will either have SUCCEEDED or FAILED, depending on whether it has passed quorum and has a majority of YAE votes or not. In this stage, if the proposal has passed, the payload is queued with a timelock of 1 day, after this is elapsed the payload may be executed. If the proposal is not executed before the end of a grace period it expires and must be deployed and voted on again from the beginning of the on-chain voting process.
A visual representation of this flow is shown in the figure below.
On-chain voting process
In both off-chain and on-chain votes, the voting power is directly proportional to the amount of AAVE, stkAAVE or aAAVE a user holds or has delegated to them. For more details, please refer to the official documentation.
Quorum
In order for a proposal to succeed, a minimum of 320,000 AAVE, stkAAVE, or aAAVE must participate in the vote. In addition to this, the winning vote must also have 320,000 votes. For example if a proposal had 320,000 total votes, with less than 320,000 votes for the winning option, this would not meet quorum requirements. Any changes to the quorum requirements must be amended by the community through an AIP.
Each vote has to reach the minimum quorum, even if it has a majority, for it to be considered an official proposal. It is the responsibility of the proposal author to enlist voting participation from the community in order to reach a quorum.
ACI Skyward
Skyward is a free service launched by ACI to assist Aave DAO members with the proposal process, making it more accessible and streamlined. The service covers various AIP types, including asset onboarding, risk parameter changes, interest rate strategy changes, supply & borrow caps changes, E-mode activation, and asset offboarding. Skyward is open to everyone and free of charge in order to lower the barriers to participation in Aave’s governance.
How Skyward works:
- Initial contact: Proposer will often contact ACI before engaging in the governance process to ensure efficient progression through the various stages.
- Temp Check: Proposer writes a Temp Check and has ACI review the draft before publishing to forums.
- Temp Check Snapshot: ACI publishes Temp Check Snapshot.
- ARFC Request: ACI creates and publishes the ARFC in collaboration with the proposer.
- ARFC Snapshot : ACI publishes the ARFC Snapshot.
- AIP Creation: If the Snapshot vote is successful, ACI writes the payload and publishes the AIP for a vote.
To help understand at what point ACI Skyward takes responsibility for the governance process, see the figure below.
Governance process when making use of ACI Skyward
Non-standard Governance Frameworks
For some common actions that governance needs to take in order to manage the Aave protocol, there are frameworks for expedited governance. This helps reduce the governance burden on the DAO, tailors governance processes to the level of scrutiny required for various tasks, and helps the DAO run more efficiently.
ARFC Addendum
In order to make minor changes to an existing ARFC, rather than restarting the process from Temp Check stage, an Addendum can be proposed by forum post which progresses to Snapshot then AIP. This expedites minor changes, reducing governance burden. An illustration of the process is shown below:
ARFC Addendum Governance Process
Asset Onboarding Framework
The Asset Onboarding Framework is available to read on the forums here: [ARFC] Update the Asset Onboarding Framework along with minor modifications here: [ARFC Addendum] Update Asset Onboarding Framework.
There are two pathways for onboarding new assets to Aave. If there is no existing Aave market for the asset, the standard governance process is followed, starting at temp check and progressing through all standard governance stages. For assets already listed in other Aave markets, a direct-to-AIP process is used, skipping the Temp Check stages and taking about 10 days. To use this process the following must be applicable for the asset being onboarded:
- Existing Aave market presence.
- Submission or feedback from a risk service provider.
- Supply cap not exceeding 50% on the respective chain.
- At least 90 days old Chainlink price feed.
New listing candidates must deposit $100 worth of the intended asset into the Aave Short Executor. This deposit is non-refundable and required before proceeding to the AIP phase.
Asset onboarding proposals are most commonly used for deploying markets for already listed assets on new chains, for example see these proposals to deploy weETH markets on Base and Scroll.
Asset onboarding process for assets already listed on Aave
New Chain Deployment Framework
The New Chain Deployment Framework is a standardized process for deploying the Aave Protocol on new blockchains. This framework aims to create a transparent approach for evaluating and deploying new Aave v3 instances. The full forum post detailing the framework along with templates for both temp check and ARFC proposals can be found here: [ARFC] New Chain Deployment Framework.
The process follows these key steps:
- Post a TEMP CHECK governance thread for 5 days
- Snapshot vote for 3 days (24 hours after gov thread)
- Documentation submission:
- 7 days after the Snapshot vote
- If deadline is not met, there will be a frozen period of 30 days. After that period documentation could be analyzed again
- Technical review duration
- 21 days since documentation submitted
- If technical review fails due to security concerns, process will be frozen until it’s been resolved.
- Documentation submission:
- Post an ARFC governance thread for 5 Days, after technical review has been successfully completed
- Snapshot vote for 3 days (24 hours after gov thread)
- Post an AIP vote for 5 days (Minimum 320k vote required)
These steps are shown visually in the figure below:
New Chain Onboarding Framework flowchart
The framework introduces stricter timelines and requirements than the standard proposal process. If documentation submission deadlines are not met, there’s a 30-day freeze period. Technical review failures due to security concerns freeze the process until resolution.
This framework balances security and speed, providing a more efficient governance process while maximizing the benefits of Aave’s brand for new chain ecosystems. It aims to streamline the deployment process, reduce governance overhead, and prioritize chains offering standing deposits or other benefits to the Aave protocol and its users.
Emission Manager Framework
To allow quick addition of new emissions admins to Aave pool reserves, the process of adding new emissions admins follows a direct to AIP framework. This framework also allows
pre-authorized inclusion of an emission admin as part of either an ad-hoc steward or current risk steward role to facilitate a more efficient and streamlined onboarding process. Further information can be found here: [ARFC] Emission Manager Framework Update.
The governance process under this framework is as shown in the below figure.
Emissions manager framework governance process.
Technical Maintenance Proposals
With Aave instances in multiple versions (v1, v2, v3) and networks, periodically it is necessary to do maintenance tasks related to infrastructure consistency. In order to balance efficiency and transparency of updates, Technical Maintenance Proposals are posted by BGD Labs, the current Development Service Provider on this thread (Technical maintenance proposals) for 3 days and then move directly to AIP if there is no feedback or concerns from the community. The governance process for Technical Maintenance Proposals is shown in the below figure.
Funding
As a mature DAO, there are both planned and ad hoc funding needs. In order to address these, several governance processes relating to funding have been developed. These are: one off funding requests, grants, bug bounties, and operational budgets.
Direct Funding Through Governance
A number of contributions to the Aave protocol have been funded through Governance Proposals for example funding the development of Aave V3.
Bug Bounties
The Aave bug bounty program operates in collaboration with Immunefi to enhance the security of the Aave protocol. BGD Labs and Aave Companies act as appointed representatives of the DAO for this program, with BGD responsible for most systems and Aave Companies managing GHO-related submissions. Full details and discussion around the Bug Bounty Program are available here: [TEMP CHECK] Aave Bug Bounty Program on Immunefi and here: BGD. Aave <> Immunefi bug bounty program.
Eligibility criteria and systems covered under this bug bounty program are as follows:
| Criteria | Details |
|---|---|
| Systems Covered | Aave v2, Aave v3, Aave Governance v2, Aave Safety Module, GHO stablecoin |
| Eligible Participants | All, except Official and Former Official Contributors |
| KYC Requirements | May be required at discretion of DAO representatives, not for Medium or Low severity reports |
| Special Conditions | Measures may be implemented to prevent submissions from Official Contributors for high and critical reports |
Payouts under the bug bounty program are as follows:
| Severity | Payout Range | Applicable Systems |
|---|---|---|
| Critical | 10% of funds at risk, $50,000 to $1,000,000 | Aave v2 Ethereum, Aave v3, Governance v2, Safety Module, GHO |
| Critical | 10% of funds at risk, up to $250,000 | Aave v2 on other networks |
| High | 10% of funds at risk, $10,000 to $75,000 | Aave v2 Ethereum only |
| Medium | $10,000 | All systems |
| Low | $1,000 | All systems |
Additional payout terms and procedures:
- For repeatable attacks, funds at risk calculated within first 45 minutes from first attack
- Payments made via governance proposals in a mix of AAVE and stablecoins
- Payouts batched monthly to avoid governance overload
- Immunefi’s fee of 10% applied on top of each bounty payout
- Proof of Concept (PoC) required for all Smart Contract bug reports
- Only Critical and High impacts in scope for Aave v2 on Ethereum
- Only Critical impacts in scope for Aave v2 on other networks
- Attacks involving other protocols may be considered if they meet specific criteria
- BGD can modify technical aspects, but fundamental changes require governance approval
This program allows Aave to maintain a robust security posture while engaging with the wider security research community in a structured manner.
Operational Budgets
In order to minimise governance overhead, trusted providers may receive funds for scoped and budgeted activities ahead of time. These are for well defined activities that provide either essential or beneficial services to the DAO. Most significantly these include Security Budget for BGD labs as per this proposal: [ARFC]. BGD. Security budget request - December 2023, and Events and Sponsorship Budget to Aave Labs as per this proposal: [TEMP CHECK] Aave Events & Sponsorship Budget.
Governance Roles
Delegates & Delegators
Delegates
Delegates are community members who have received voting power from other members of the community 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. Some delegates are compensated under the Orbit program.
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 specialized entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:
- 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
Guardians
The Aave Guardians are crucial for maintaining the protocol’s security and integrity. They are divided into two groups: Protocol Guardians, who handle emergency responses and can pause markets, and Governance Guardians, who can veto malicious governance proposals. The Guardians operate under a 5/9 multi-sig arrangement.
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, as well as similar roles in V2 and other related systems. The primary function of the Protocol Emergency Guardian is to act swiftly in emergency situations to protect the protocol. It is composed of highly active entities within the Aave DAO, such as service providers and delegates. The multi-sig configuration for this Guardian is a 5-of-9 setup. The current Protocol Guardians are shown in the table below and were updated in this ARFC Addendum.
| Protocol Emergency Guardian | Address |
|---|---|
| Chaos Labs | 0x5d49dBcdd300aECc2C311cFB56593E71c445d60d |
| LlamaRisk | 0xbA037E4746ff58c55dc8F27a328C428F258DDACb |
| Karpatkey | 0x818C277dBE886b934e60aa047250A73529E26A99 |
| Certora | 0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9 |
| TokenLogic | 0xb647055A9915bF9c8021a684E175A353525b9890 |
| BGD Labs | 0xf71fc92e2949ccF6A5Fd369a0b402ba80Bc61E02 |
| ACI | 0x57ab7ee15cE5ECacB1aB84EE42D5A9d0d8112922 |
| Ezr3al | 0xC5bE5c0134857B4b96F45AA6f6B77DB96Ac1487e |
| Stable Lab | 0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E |
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 |
Stewards
Stewards were introduced to allow the DAO to respond quickly to market changes in order to remain competitive and address risks. They are delegated responsibility over specific parameters within certain boundaries of magnitude and frequency of change. The benefit of this is that minor changes do not need to go through a full governance cycle, increasing speed and reducing governance burden on delegates and tokenholders. At time of writing there are stewards for managing: GHO, lending parameters, and treasury operations.
GHO Stewards
The GHO Stewards are a group of Contributors and Service Providers who manage critical parameters for the GHO stablecoin, ensuring its stability. This group has the authority to adjust the:
- GHO Borrow Cap
- Borrow Rate
- various GSM parameters like Exposure Cap, Bucket Capacity, Price Strategy, Fee Strategy, and Price Range (Freeze, Unfreeze)
The ranges for parameters which the GHO Stewards may adjust are shown in the below table and were proposed in the following ARFCs [ARFC] GHO Stewards, [ARFC] GHO Stewards + Borrow Rate Update.
| Description | Value |
|---|---|
| GHO Aave Bucket Capacity | 100% Increase |
| GSM Exposure Cap | 100% Increase |
| GSM Bucket Capacity | 100% Increase |
| GSM Fee Strategy | + 0.5% |
| GSM Price Range | (Freeze, Unfreeze) |
| GHO Borrow Cap | 100M |
| Max GHO Borrow Rate Adjustment | 5% |
| Max GHO Borrow Rate | 25% |
| Frequency of Change | 2 days |
The creation of GHO Stewards aims to streamline governance, allowing quick adjustments to maintain the GHO peg, especially during market fluctuations. The GHO Stewards operate under a 3-of-4 multi-sig configuration and GHO Stewards at time of writing are:
- Karpatkey
- Tokenlogic
- ACI
- Chaos Labs
Risk Stewards
Risk Stewards are responsible for managing critical risk parameters within the Aave protocol. They are able to make adjustments to supply and borrow caps, reducing the need for frequent community votes. This setup ensures rapid responses to emerging risks while minimising governance overhead.
The parameters that Risk Stewards can change are:
- Supply and Borrow Caps: Increasing caps with constraints on frequency and maximum percentage increase to maintain protocol stability.
- Collateral Risk Configurations: Adjusting parameters such as Loan-to-Value (LTV), liquidation thresholds, and liquidation bonuses.
- Interest Rate Strategies: Fine-tuning base rates, slopes, and optimal points to align with market conditions.
The parameters that the Risk Stewards can control are shown in the table below and were discussed in the following proposal: BGD. Risk Steward Phase 1: CapsPlusRiskSteward.
| Description | Value |
|---|---|
| Frequency of change | 5 days |
| Maximum supply cap increase | 50% |
| Maximum borrow cap increase | 50% |
Risk Stewards operate under strict on-chain validations and are managed by a 1-of-1 multisig. Risk Stewards at the time of writing are:
- Chaos Labs
Finance Stewards
Please note the Finance Stewards system in not yet live and is for information purposes only at this point, it is planned that this will go live in the near future.
Finance Stewards are responsible for executing pre-approved and budgeted financial operations on behalf of the Aave DAO. They manage the Aave DAO’s funds through a smart contract that acts as an admin of the collector, streamlining the management of treasury assets and reducing the need for frequent on-chain votes.
The Finance Stewards have the authority to:
- Migrate assets from v2 and deposit into v3
- Use the Aave Swapper to exchange treasury assets
- Withdraw and deposit into V3
- Transfer and stream tokens to pre-approved addresses within set budgets such as ACI Frontier Program and ACI Merit Program
Proposed Finance Stewards at the time of writing are:
- Karpatkey
- Tokenlogic
