[ARFC ADDENDUM] Updated Framework for ARFC and TEMP CHECK Proposals

Governance General
1

[ARFC ADDENDUM] Updated Framework for ARFC and TEMP CHECK Proposals

Author: ACI

Date: 2024-08-14

Summary

This framework provides comprehensive guidelines for the Aave DAO community when creating and voting on TEMP CHECK, ARFC (Aave Request for Comment) and ARFC ADDENDUM proposals. It includes a template for crafting proposals and outlines the quorum and voting requirements.

Motivation

Distinction Between TEMP CHECK, ARFC, and ARFC ADDENDUM

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.

If minor updates are required for an ARFC, an ARFC ADDENDUM can be used instead of repeating the entire ARFC process. If this is not controversial and feedback from tokenholders and delegates is limited, the discussion period on forums can be reduced or bypassed for addendums.

Proposal Cycle

For ARFC addendums, the following process can be followed:

Proposal Structure

Each proposal must include the following sections:

A header:

  1. Title: A concise and descriptive title for the proposal, including the proposal type (ARFC, TEMP CHECK, or ARFC ADDENDUM) in a [TAG] format.
  2. Author: The name of the author and/or entity creating the proposal.
  3. Date: The date the proposal is being made, in the YYYY-MM-DD format.

A proposal body:

  1. Summary: A succinct summary of the proposal.
  2. Motivation: A detailed presentation of the proposal and potential benefits for the Aave protocol. This section can have sub-sections for improved readability.
  3. 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.
  4. Disclaimer: Any necessary disclaimers, such as conflicts of interest or third-party involvement.
  5. Next Steps: The proposed next steps if the proposal is approved.
  6. Copyright: A statement defining proposal copyright. While Open-Source is mandatory, the choice of a specific license is left to the author.

Voting Guidelines

  1. Vote Start Time: The vote should commence 24 hours after the proposal is published on Snapshot.
  2. Proposal Age: The governance thread related to the snapshot vote should be at least 5 days old before voting begins.
  3. Vote Duration: The vote should last for a minimum of 3 days.
  4. Vote Options: The vote should have at least three options: YAE (Yes), NAY (No), and ABSTAIN. Sometimes a vote will require other voting options such as choosing between multiple options, however there should still be a NAY and ABSTAIN option as a minimum.
  5. Quorum: The vote should reach a quorum of 320,000 YAE votes.
  6. Differential: The YAE votes should exceed the second-largest vote option (either NAY or ABSTAIN) by at least 80,000.

Special Considerations

This framework should be considered as a general template for proposals. Specific proposals and/or frameworks, such as asset onboarding or caps updates, should follow specific guidelines as determined by the Aave DAO community. Guidelines for many of the different frameworks are available in the Aave Governance Process Document: Aave Governance Process Document v1.

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

  1. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.
  2. If the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted.

Copyright

Copyright and related rights waived via CC0.

3 Likes
2

LlamaRisk thanks @ACI for putting together a straightforward, simple skeleton for the lifecycle of a proposal. This update to the existing framework, once implemented, will streamline processes and enhance collaboration among all involved parties.

In general, this presents a clear outline for governors to follow. The quorum requirements are suitably large, and the addendum process should enhance efficiency. It’s helpful to see the latest iteration of these processes codified in one area.

We want to make two risk-specific suggestions nonetheless:

  1. ARFC Risk Provider required replies
    While this process is generally followed, we’d like to see the requirement for at least one risk provider recommendation formally included in the framework. This ensures that proposed changes are analyzed for potential impacts on existing protocol operations before an ARFC moves to a vote.

  2. ARFC length to at least 5 days
    Comprehensive risk assessment requires extensive research on both quantitative and qualitative aspects. This research must be conducted, refined, and presented clearly to inform Aave DAO. Sometimes, more than 5 days are required to complete this process, especially when the ARFC period overlaps with weekends. Risk analysis often requires third-party input, which can lengthen the process, potentially compromising quality if rushed. We will strive to inform the DAO when more time is needed to complete our examination.

We thank you again for this initiative and the opportunity to voice our input.

6 Likes
3

This proposal provides a clear set of directions for prospective Aave Governance Participants.

We are pleased to see the addition of the ARFC Addendum process where there is additional feedback to implement after the ARFC stage.

As Delegates, we are committed to seeing the strict implementation of this governance framework.

3 Likes
4

Hello @LlamaRisk,

A service provider will not slow down the Aave DAO.

Feedback at the ARFC stage is mandatory and expected in governance delays as part of the service engagement scope.

3 Likes
5

The current ARFC Addendum has been escalated to ARFC Addendum Snapshot.

Vote will start tomorrow, we encourage everyone to participate.

6

Thanks for the structure / outline of the process, looks good

7

The current ARFC Addendum Snapshot has just ended, reaching both Quorum and YAE as winning option with 516K votes.

Therefore the ARFC Addendum has passed, and the new framework is considered as canon, with the current guidelines being adopted from now on.