Title: [ARFC] Framework for ARFC and TEMP CHECK Proposals
Author: @MarcZeller - Aave Chan Initiative
Date: 2023-06-27
Summary
This framework provides comprehensive guidelines for the Aave DAO community when creating and voting on ARFC (Aave Request for Comment) and TEMP CHECK proposals. It includes a template for crafting proposals and outlines the quorum and voting requirements.
Motivation
Distinction Between TEMP CHECK and ARFC
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.
Conversely, 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.
Proposal Template
Each proposal must include the following sections:
A header:
Title: A concise and descriptive title for the proposal, including the proposal type (ARFC or TEMP CHECK) in a [TAG] format.
Author: The name of the author and/or entity creating the proposal.
Date: The date the proposal is being made, in the YYYY-MM-DD format.
A proposal body:
Summary: A succinct summary of the proposal.
Motivation: A detailed presentation of the proposal and potential benefits for the Aave protocol. This section can have sub-sections for improved readability.
Specification: A comprehensive description of the proposed change, including any relevant parameters or risk considerations. For ARFCs, this section should be technical, detailing the specific changes to be made. This section can have sub-sections for improved readability.
Disclaimer: Any necessary disclaimers, such as conflicts of interest or third-party involvement.
Next Steps: The proposed next steps if the proposal is approved.
Copyright: A statement defining proposal copyright. While Open-Source is mandatory, the choice of a specific license is left to the author.
Voting Guidelines
Vote Start Time: The vote should commence 24 hours after the proposal is published on Snapshot.
Proposal Age: The governance thread related to the snapshot vote should be at least 5 days old before voting begins.
Vote Duration: The vote should last for a minimum of 3 days.
Vote Options: The vote should have at least three options: YAE (Yes), NAY (No), and ABSTAIN.
Quorum: The vote should reach a quorum of 320,000 YAE votes.
Differential: The YAE votes should exceed the second-largest vote option (either NAY or ABSTAIN) by at least 80,000.
Proposal Cycle:
Special Considerations
This framework should be considered as a general template for general proposals. Specific proposals and/or frameworks, such as asset onboarding or caps updates, should follow specific guidelines as determined by the Aave DAO community.
This framework is designed to ensure that all proposals are thoroughly considered and that all votes are fair and representative of the Aave DAO community’s views.
Specification
As this proposal pertains to governance guidelines, it does not require any on-chain action or protocol change.
Disclaimer
The ACI is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC.
Next Steps
If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.
If the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted.
We are glad you see the same concerns and issues facing new, less familiar participants.
Something that may be worth including in this is the timing of each cycle; i.e. how long should a TEMP CHECK discussion be live before heading to a vote? As an ARFC?
The voting duration is clearly defined but it would be helpful to help guide discussions on the forum and how long they last (and when to progress) so the community may provide ample input.
This set of guidelines may prevent rushed, nefarious proposals – and create a clearer set of expectations around the total length of the Governance cycle.
We disagree with this line in the Snapshot stage:
Quorum should not be related to the direction of a vote – nor in the AIP stage.
What happens if a vote reaches 320,000 NAY votes? Is it not valid?
Additionally, it eliminates real possibilites of mixed votes and ABSTAINs.
Both general-purpose ARFCs and TEMP CHECKs share several similarities, including the timeline for proposals. In this case, a minimum of 5 days is required between the topic publication and escalation to a snapshot vote.
We believe that setting a maximum or other “subjective” requirements is not necessary in this context. Proposals that fail to reach consensus have a low chance of passing the snapshot stages. When designing guidelines, it’s crucial to strike a balance between mandatory parts and parts left to “usage” to allow some degree of flexibility in well-designed frameworks.
A vote that reaches 320,000 NAY votes is indeed valid and effectively rejects the proposal. All three stages of the proposal life process are designed to act as filters. The TEMP CHECK snapshot determines whether a proposal is worth the time and resources for service provider feedback and engineering to detail the proposal. The ARFC snapshot decides whether to dedicate actual resources to convert the human language of a proposal into AIP payload code. Finally, AIPs decide whether the payload is executed and actively modifies the Aave protocol.
NAY and ABSTAIN votes are not subject to differential requirements, as no specific action is required with an ABSTAIN or NAY outcome. Payloads are simply not executed, or proposals are not escalated.
By design, a YAE outcome is supposed to be harder to achieve than a NAY or ABSTAIN outcome. Aave is a decentralized protocol, and AIPs modify the protocol itself, which manages billions of dollars. Therefore, checks and filters are necessary to ensure the protocol’s security and integrity.
EDIT adding some examples for clarity:
Proposal 1
Votes
YAE
310k
NAY
20k
ABSTAIN
80k
Outcome
Failed (quorum failure)
Proposal 2
Votes
YAE
325k
NAY
150k
ABSTAIN
80k
Outcome
YAE
Proposal 3
Votes
YAE
400k
NAY
350k
ABSTAIN
0
Outcome
Failed (differential)
Proposal 4
Votes
YAE
120k
NAY
240k
ABSTAIN
0
Outcome
Failed (No quorum needed to fail a proposal if NAY/Abstain wins)
If the goal is to be comprehensive, we suggest the following types of votes be included:
Level 2 Governance votes from the perspective of quorum requirements
Risk Stewards specific to Supply/Borrow and GHO Mint Caps
Asset listings when the asset is already active on another Aave deployment
A loose idea is to have a rule of thumb whereby the vote cycle starts early in the week for all the non urgent votes. ie: minimise weekend voting where possible.
In the past, some teams have gone direct to AIP with minimal input from the community. This is normally the result of an abundance of caution from a risk perspective, which in recent votes has at times been voted down or quickly overturned by a later AIP submission.
If the objective is to be comprehensive, then all governance flows should be detailed in a single place. Or as a minimum cross referenced. Supply/Borrow caps amendments need to go through this process when both Chaos Labs and Gauntlet don’t support the proposed risk parameter changes. Having visibility of that governance flow here adds visibility to anyone using this post as the source of truth.
Regarding the content of specifications, there seems to be a distinct difference between [TEMP CHECKS] and [ARFC]. [TEMP CHECK] appears to be more narrative and [ARFC] more technical. Directionally, we agree. However, more granularity on the distinctions is warranted as the text in the proposal is open for a wide array of interpretation.
This publication is a great start and in our honest opinion, it can be expanded to become more of a holistic source of truth for Aave governance. We are happy to help wherever possible to make this a more holistic framework.
Thanks for putting this together and we support the proposed framework, template, and voting requirements.
I think it would help the community if the new framework + template is easily accessible via a pinned post in the forum. Would it also be possible to have: Aave Protocol Overview updated to reflect these changes?
I assume that if this proposal is approved, every off-chain vote will follow this template and voting guideline including Temp Checks + AFRC for level 2 governance (long executor). It won’t be until the AIP stage that voting guidelines are changed for level 2 governance votes. However, providing examples of what’s valid under these frameworks could certainly dispel some confusion.
this documentation is controlled by the @AaveLabs so up to them to stay up to date.
we worked with stable labs to do this : Aave Finance Governance Process v0 it’s not perfect, but it’s a start, it will be updated to reflect governance decisions.
To confirm, adding assets already listed on one Aave deployment to another shall require a [TEMP CHECK] and [ARFC] Snapshot vote as per this proposal ?
For risk parameter changes deemed necessary, these can go direct to AIP without any Snapshot vote and fall outside of this framework ?
Can we add this process flow into this framework.
Regarding Supply/Borrow Caps, if we need to route via Snapshot. Does it make sense to vote twice given the both proposals [TEMP CHECK] and [ARFC] given the same known risk parameters are stated in the both Snapshot votes. There is an opportunity to remove some duplication by having a single Snapshot vote on Supply / Borrow Caps.
i don’t get what the problem here is?
If anybody involved in the DAO is against this, this person can come here and say so.
Its just about a framwork for the different steps, which helps to organize stuff in here.
The snapshots and votings in the end will be voted decentralized.
Thanks for this framework @MarcZeller. It was definitely needed and creates much clearer guidelines for everyone while enabling easier access for anyone to place proposals and with the help of Skyward potentially escalate further in governance once there is community feedback.
In a scenario where this is a successful ARFC, we would strongly recommend as well that this gets pinned by @AaveLabs.
Thank you for this much needed framework! This adds clarity for delegates and third parties who are new to making proposals. Michigan supports this proposal.
In the future, could we also have some guidelines on, at the ARFC stage, which service providers’ input are needed for each type of proposals? For example, for proposals regarding onboarding new oracles, who are the relevant service providers in addition to BGD?
Thank you for this framework @MarcZeller and ACI, definitely needed! We agree with @Michigan_Blockchain around the need to provide guidelines on service provider input - it’ll make it easier for proposers to contact the relevant teams.
With regard to @TokenLogic’s comments on the Supply/Borrow Caps, if changes are to be made to those we agree that we should only have a single Snapshot vote. However, new listings on a new Aave deployment, regardless of whether it is present on another deployment, should require a TEMP CHECK as well since conditions across chains (e.g., liquidity) can materially differ.
Further additions to this framework could include more details around AIPs and specifically where proposals could directly go to the AIP stage and where it may not be appropriate to do so. However, we recognise that this proposal is to more keenly define the TEMP CHECK and ARFC stages of governance, and more details on the AIP stage can be added later.
This is good feedback, will publish a framework on this shortly
We agree, these cases should be covered, voted and integrated in existing guidelines
This framework is the “general purpose” one, designed to act as the basic template for proposals, exceptions to these frameworks for specific cases will be voted on separately such as current “cap update framework” that is currently discussed to be updated as a “direct-to-Aip” framework allowing governance to bypass current framework for specific actions.
As you may have seen recently, there’s been some upgrades to update the Asset Onboarding Framework. Please find attached latest ARFC with a more detailed explanation on the changes to establish a streamlined governance process for adding new markets and streamline the listing of assets with existing Aave markets on new chains.
The listing framework aims to balance security and speed by providing a more efficient governance process for asset onboarding. We have established the precedent with past proposals that have improved timeliness and governance overhead. This will define a clearer and accessible standard in the same spirit as the DAO’s historic process.
