Comment on page
With the addition of new features in Aave V3, the scope for potential governance proposals is substantially widened:
- Supply caps, borrow caps, and isolation mode can reduce the risk for onboarding new assets
- With the
ROLE_ADMINdesignation, Aave Governance can approve a variety of permissions
- Roles could potentially be used for automated asset listing or parameter adjustment
- Every aToken and debtToken now supports multiple rewards per asset
All proposals follow the same general process from idea to execution, which is detailed in this guide. There are also pages with templates for completing these steps with standard proposal types:
The first step in the proposal process is introducing the proposal to the community through the governance forum. The Aave Request for Comments (”ARC”) is a post on the forum to allow the community to discuss the details of a proposal. Here is a guide for Creating an ARC; you can also find templates for specific proposal types in the links above.
The Aave Snapshot Space is a place for voters to gauge community sentiment for on-chain votes, or decide off-chain proposals. The Snapshot poll should contain the same information as the ARC, and should always link back to the original ARC post.
Any proposal which passes the Snapshot phase and requires an on-chain payload moves to the "AIP" phase. An AIP - Aave Improvement Proposal - is the proposal payload which will be submitted on chain and voted on by the community. The AIP consists of two main components: the AIP text and implementation.
The AIP text is a structured text description of the proposal which is uploaded to IPFS, and the IPFS hash is submitted with the on-chain proposal. To generate an AIP text for your proposal, create a fork of the AIP repo, and follow the steps in the README.
The AIP implementation is the array of transactions which will be executed if the proposal succeeds. All AIPs should be tested (and potentially audited) to ensure safety and correctness. See the proposal type pages for steps on generating the execution parameters.
The proposal life cycle is detailed in the diagram or in text form below:
Or set to
The validation and execution of the proposal is performed by the time lock executor. The proposal is set to QUEUED until it is EXECUTED , or if a queued proposal is not executed before expiration, it is set to EXPIRED.