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.

1. Writing an AIP

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.

2. Preparing the AIP for on-chain governance

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.

3. Submitting the AIP for on-chain governance

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.

Submitting a proposal

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.
Short Executor
Long time lock
Minor changes to the protocol: parameter change, asset listing
Change to the core code base of the protocol such as governance
Proposition Threshold
AAVE 80k
2% AAVE 320k
1 day
7 days
Voting Duration
3 days
10 days
Vote quorum
2% AAVE 320k
20% AAVE 3.2m
Vote Differential
AAVE 80k
15% AAVE 2.4m
Grace Period
5 days
5 days