Governance Process
Proposal Lifecycle
Governance Forum
The first step in the proposal process is to introduce an idea to the community. The governance forum and official Discord server are the primary platforms to receive feedback and technical support from community members.
Snapshot
The Aave Snapshot Space is a place for the community to signal support for early-stage proposals. There are two general types of proposals in the Aave Snapshot: TEMP CHECK and ARFC.
TEMP CHECK
TEMP CHECK votes serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate involvement from DAO service providers or a high level of precision or technicality.
ARFC
The Aave Request for Final Comments ("ARFC") is a precursor to Aave Improvement Proposal ("AIP"). 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.
See the governance forum for updates on the latest procedures and templates for Snapshot proposals.
Create On-Chain Payload
AIP
Any proposal which passes the Snapshot phase and requires an on-chain payload moves to the Aave Improvement Proposal ("AIP") phase. An AIP is the proposal payload which will be submitted on chain and voted on by the community. The AIP consists of the proposal metadata (IPFS hash) and contract payload which are both submitted on-chain.
See developer docs for more information on AIP creation.
Voting & Execution Timeline
Voting
When a proposal is submitted, a voting network is specified, all voting occurs through the governance contracts on this network.
Voting tokens and delegations are still only on Ethereum Mainnet, validated by proofs on the voting network.
Once a proposal is created, it’s status is set to PENDING and will move to ACTIVE once the voting delay period has elapsed. The snapshot for voting balances occurs at the block before the proposal moves to ACTIVE.
Once the delay period is passed and voting duration has elapsed, the proposal is status is set to SUCCEEDED if:
The voting power (in % of total voting power) of for-votes reaches the quorum set by the minimum quorum parameter for the proposal executor, AND
The difference between for-votes and against-votes (in % of total voting power) exceeds the vote differential threshold set by the vote differential parameter for the proposal executor.
Or set to FAILED otherwise.
Execution
A SUCCEEDED proposal can be executed on Ethereum mainnet by relaying the vote information through governance cross-chain infrastructure.
Once executed on Ethereum, if the proposal contains a cross-chain payload, it can be queued on the timelock executor contract on the corresponding network. After the timelock delay and before grace period expiration, the payload is able to be executed.
The timelock delay depends on the executor of the proposal. A short executor proposal includes most protocol updates, and has a 1 day timelock delay. A long executor proposal involves updating core permissions for Aave Governance, and has a 7 day timelock delay.
Cross-chain proposal payloads are executed using a.DI ("Aave Delivery Infrastructure"), which uses a quorum to verify messages from designated bridges.
Proposal Frameworks
The Aave DAO has frameworks for common proposal types which are adopted and amended through community Snapshot votes.
Last updated
