Aave Finance Governance Process v0
Authors: @Kene_StableLab, Bobbay_StableNode
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.
This document aims to provide an overview of the different roles, flow and pathways for various stakeholders to participate in Aave DAO.
Contents
- Governance Roles
- Aave Guardians
- Delegates
- Delegators
- Contributors
- Rules and Values
- Code of Conduct
- Values
- Enforcement
- Governance Processes
- Discussions
- Proposals
- Working Groups
- Funding
- Voting
- Proposal discussion
- Quorum
- Proposal history
- Changes to Governance
Governance Roles.
There are four key roles in Aave Governance.
- Aave Guardians: The Aave Guardians are a group of community-elected individuals and/or entities that form part of a 6/10 multi-sig with the sole responsibility of:
- Protecting the Aave Protocol against potential governance takeovers by having the ability to “veto” an AIP if it is deemed malicious.
- Allowing V3 markets to be upgraded following governance votes on Snapshot while an on-chain cross-chain governance module is implemented.
- Functioning as a failsafe emergency actor to pause Aave markets.
For more information about the Aave Guardians, check out this Medium post about the Aave V2 Governance Process.
- Delegates: Delegates are community members who have received voting power from other community members or through self-delegation. Delegates are currently not compensated in Aave.
- Delegators: Delegators are community members who hold Aave or stkAAVE but have entrusted their voting power to another person. The person they delegated their voting power to is considered a delegate.
- Contributors: Contributors are community members who participate in and dedicate their time to the Aave DAO. They participate by joining working groups, fulfilling bounties, and/or building on top of the Aave Protocol or for the DAO via grants while working towards completing shared goals.
Rules and Values
Aave does not generally have a Code of Conduct. However, the DAO has a set of policies that function as a set of governance-defined rules that control specific aspects of the protocol or the individual markets.
These policies are broadly classified into
- Protocol Policies: This regulates the overall behavior of the protocol and the various entities that participate within the Aave Ecosystem; these policies regulate specific aspects of the protocol related to safety, economics and expansion.
- Market Policies: These policies are market specific and seek to impose safety measures that would overall protect the Aave Protocol from any cross-market contagion, which could spread to the entire protocol.
To learn more about Aave’s Policies, check out this site.
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/stkdAAVE holder or contributor.
Discussions
Most governance discussions take place on the official Aave Governance Forum and the official Aave Discord Channels. It is recommended that all discussions in contemplation of a proposal start out on the Aave Governance Forum.
Proposals
There are generally two types of proposals in Aave Governance; these two general proposal classifications strictly refer to the maturity of a proposal in the Aave Governance Process.
- TEMP CHECK: TEMP CHECKs 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.
- 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.
In order to propose specific changes to the Aave Protocol that fall under the scopes listed below, the proposal format should abide by the specific guidelines stated.
Aave Improvement Proposal (AIP).
- Aave Improvement Proposal: This is a formal proposal to improve the Aave Protocol; it is recommended that before submitting an AIP, an ARC 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; for a step-by-step guide on uploading an AIP on-chain, check here.
Caps Update Framework
This refers to a direct to AIP vote for cap changes or FreezeReserve() implementation if the following conditions are met:
- The proposal is provided by a risk service provider or has received feedback from at least one risk service provider team.
- The proposed cap change is not greater than a 100% increase of the current cap or the implementation of a cap.
- The cap is being decreased.
- The AIP is implementing a FreezeReserve().
For other situations, the normal governance process is applicable. To learn more about the Caps Update Framework, check out this forum post.
This framework is intended for All V3 liquidity pools. Relative to freezing reserves, this framework is intended for all Aave pools.
Asset Onboarding Proposal.
- Asset Onboarding Proposal: This is a formal proposal that is used to onboard new assets onto the Aave Protocol. Asset onboarding proposals still follow the ARC and AIP route; however, there are specific requirements that contribute to a successful asset on-boarding proposal.
To summarise, here is an overview of the standard proposal process:
- Post a governance thread for 5 days
- Snapshot vote for 3 days (24 hours after gov thread)
- Post an AIP vote for 5 days (Minimum 80k required)
This takes process takes around 13-14 days.
Fast Track Proposal.
-
Fast Track Proposal: This express proposal path is designed to cater to emergencies where time is of the essence.
-
Through the expedited fast track process, the fast track process would follow this pattern:
- Governance thread for 24h
- Snapshot with immediate vote open for 48h
- Community multisig enforcement
- Fast-track requires an 80k AAVE quorum
However, the scope of Fast-track proposals is limited to act on only Supply & Borrow caps with a 50% change.
Aave Service Providers.
A number of other service providers also contribute to the development and maintenance of the Aave Protocol; these external entities function as independent contractors who act in the best interest of the Aave Protocol; they are as follows:
- BDG Labs
- Gauntlet
- Chaos Labs etc.
Although there is no clear template to become a service provider, Aave enables service providers to contribute to Aave DAO. A template should be created to simplify this process.
Funding.
Aave DAO has two pathways for funding:
- Direct funding through governance
- The Aave Grants DAO
Direct Funding Through Governance
A number of contributions to the Aave protocol have been funded through Governance Proposals; clear examples of this are.
- The governance for funding the development of Aave V3.
- The governance vote for the renewal of the Aave’s Service Provider Agreement with Gauntlet.
Aave Grants DAO
The Aave Grants DAO was created to fund ideas and builders in the Aave ecosystem. The two-quarter pilot program had a grant budget of $1 million and an operating budget of $250,000 per quarter. Here is a link to the original grant proposal.
The Aave Grants DAO offers grants to innovation in the following areas:
- Protocol Development: This refers to direct technological innovation that translates directly into benefits for the Aave Protocol.
- Applications and Integrations: This refers to technological innovation that involves building on top of the Aave Protocol or leveraging Aave’s infrastructure to develop a product or service that translates into benefits for the Aave Ecosystem.
- Developer Tooling: This refers to building tools that assist developers in building within the Aave Ecosystem.
- Code Audits: Technical assistance that results in the improvement of the security, operations and/or maintenance of the Protocol’s code base is eligible for a grant from the Aave Grants DAO.
- Events & Hackathons: These refers to events aimed at creating more brand visibility for Aave, along with allowing developers to build on top of or in partnership with Aave and get rewarded for their innovation.
- Community Efforts such as (Marketing and Education): Ensuring that the right information is actively promoted within the Aave community is an important aspect of the Aave DAOs growth, therefore efforts within this category are also eligible for a grant for the DAO.
Voting.
The Aave DAO reaches a consensus on proposals via token voting. AAVE or stkAAVE holders are empowered to participate in governance votes. Token holders can also delegate their governance power to delegates who can participate in Aave Governance on their behalf.
Proposal Discussion.
As part of the governance process, a discussion must be started on the Aave Governance Forum.
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, for example: Template ARC Asset Onboarding
Moving to Vote
Once a proposal has completed the requirements stated above, the proposal can move forward to the voting stages.
There are two kinds of votes, off-chain and on-chain:
- Off-chain (Snapshot): This vote is used to gauge the sentiment for ARC’s. This vote is necessary for a proposal to move forward to an on-chain vote (if necessary). The off-chain voting period lasts 5 days.
- 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 5 days.
In both off-chain and on-chain votes, voting power is directly proportional to the amount of AAVE or stkAAVE a user holds or has delegated to them.
Please refer to the official documentation to learn more about voting processes.
Quorum
In order for a proposal to succeed, a minimum of 320k AAVE or stkAAVE must participate in the vote. 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.
Proposal History
To learn about Aave Proposal history, you can find off-chain votes on SnapShot and on-chain votes on the Aave governance platform.
Changes to Governance
Any changes to the Aave Governance Process must be ratified by the community through an AIP.
Resources: