AIPs
Aave Improvement Proposal (AIP) may be created and submitted by any community member who has sufficient proposition power. Its recommended to start with an ARC to gather feedback on the governance forums, then move to a snapshot poll to reach rough consensus before finally moving to the AIP phase which is resource heavy.
The AIP number will be assigned by an AIP reviewer, and the AIP status should start at
WIP (Work In Progress). The AIP should include all the relevant information as well as links to the forum discussion and snapshot vote.Once the AIP is written and polished, it needs to be submitted via Github by forking the AIP repository and following the instructions there.
When submitting the AIP pull request, ensure that it includes the relevant
front matter properties at the top of the file. For example, the first 10 lines as shown on the template must be modified and included in your AIP.Once the AIP pull request has been polished and reviewed, it becomes ready for on-chain governance. This requires the following technical steps:
- The reviewed AIP is merged into the AIP repository and passes the CI pipeline (currently performed by the Aave Genesis Team).
- The reviewed AIP is parsed and uploaded to IPFS. We recommend using the AIP uploader tool. The returned IPFS hash is needed for the next step.
- The payload is reviewed and sufficiently tested.
A community member with enough proposition power is now able to submit the AIP for on-chain governance.
Currently this is a technical process, so requires a developer to submit the payload and IPFS hash using the
create() function on Governance v2 with the appropriate parameters.Also see the Voting & Governance section of the developer docs, or the New Asset Listing guide for examples.
There are two types of proposals with different parameters which affect the length and execution of a proposal, i.e. critical proposals that affect governance consensus require more voting time and a higher vote differential, whereas proposals affecting only protocol parameters require less voting time and can be quickly implemented.
The table below summarises the characterises of the two types of proposals. For more details, please check the detailed Aave Governance V2 github.
Text | Short Executor | Long time lock |
|---|---|---|
Description | Minor changes to the protocol: parameter change, asset listing | Change to the core code base of the protocol such as governance |
Proposition Threshold | .5% AAVE 80k | 2%
AAVE 320k |
Delay | 1 day | 7 days |
Voting Duration | 3 days | 10 days |
Vote quorum | 2%
AAVE 320k | 20%
AAVE 3.2m |
Vote Differential | .5% AAVE 80k | 15%
AAVE 2.4m |
Grace Period | 5 days | 5 days |
Last modified 1yr ago