On Wednesday, Aave DAO approved a proposal seeking to streamline the Aave Governance process by defining which proposals should fall under Temperature Checks and ARFCs.
Authored by Stable Lab and Marc Zeller, the proposal argues that there is currently no “clear distinction” on the different categories of proposals that govern various sections of the protocol. In particular, there are Aave Request for Comments (ARCs), Aave Request for Final Comments (ARFCs), and Aave Improvement Proposals (AIPs) that govern all aspects of the Aave ecosystem, with overlapping functions.
This proposal is intended to shorten the lifecycle for mature proposals involving Risk Service Providers’ direct involvement while clearly distinguishing which proposals have to pass through the entire Aave Governance Process to enable ample community feedback and participation.
To make Aave’s governance process more agile and robust, the proposal recommended renaming ARCs to “Temperature Checks (TEMP CHECKs).” It also proposed “clearly defining” what type of proposals should be considered as TEMP CHECKs and those regarded as ARFCs.
That said, a Temperature Check will be the first step in the DAO’s governance process. When a proposal qualifies as a TEMP CHECK, it would have to go through the ARFC phase before becoming an AIP. However, in the event that a proposal falls outside the purview of a TEMP CHECK, it will be regarded as an ARFC and subsequently upgraded to an AIP.
As a general guideline, proposals that fall under one of the following scopes listed below will begin as a TEMP CHECK:
- Discussions that require general community feedback
- Proposals that involve the deployment of Aave on a new network
- New asset listings
- Discussions and proposals involving the assessment of GHO Facilitator candidates, Portals Operator candidates, or New Service Provider Candidates
For clarity, ARFCs are considered to be more mature and significantly technical proposals that require the input of Aave DAO Risk Service Providers. Things like risk parameter changes, onboarding already listed assets, and the renewal of previously engaged Aave Service Providers are all viewed as ARFCs.
Comment from Aave DAO contributor KΞntPhilly.eth
I voted for the proposal to help clarify the governance process. Following Uniswap with their temperature check vote and then official vote, this appears the be the leading best practice.
Comment from Aave DAO contributor KeneChukwu:
By creating distinctions in the Aave Governance Process, we worked together with @lemiscate to define a clearer process for different kinds of proposals, through this change service provider resources could be applied to mature proposals, while less mature proposals are allowed to develop