Governance

Overview

Aave governance operates as a decentralized system where the community of AAVE token holders participates in decision-making processes that affect the protocol. This decentralized governance structure ensures that the protocol remains community-driven, transparent, and adaptable to the needs and preferences of its users.

Core Components

1. Governance Token (AAVE)

The AAVE token is the native governance token of the Aave protocol. AAVE holders can participate in governance by:

• Voting directly on proposals
• Delegating their voting power to trusted delegates
• Each AAVE token represents one vote
• Tokens can be staked in the Safety Module for additional benefits

2. Delegation

Aave's delegation system allows AAVE token holders to assign their voting power to trusted delegates without transferring ownership of their tokens. This mechanism increases governance participation by enabling token holders who may lack the time or expertise to actively participate in governance to still have their interests represented.

Here's a list of current proxy voters you can delegate to.

Key aspects of delegation include:

• Process: Token holders can delegate through the Aave governance interface, selecting from a list of established delegates or delegating to any Ethereum address.
• Delegates: Active delegates include various entities such as:
  • Professional governance firms (e.g., TokenLogic, StableLab)
  • University blockchain organizations (e.g., Blockchain at Berkeley, Cambridge Blockchain Society)
  • Individual governance participants (e.g., Aave Chan Initiative)
  • DeFi-native organizations (e.g., Karpatkey)
• Responsibilities: Delegates are expected to:
  • Actively participate in governance discussions
  • Vote on proposals and AIPs
  • Represent their delegators' interests
  • Maintain transparency in decision-making processes
• Flexibility: Token holders can:
  • Change their delegate at any time
  • Split their delegation among multiple delegates
  • Revoke delegation and resume direct voting

3. Service Providers

Aave DAO has established partnerships with several specialized service providers:

• Risk Management:

  • LlamaRisk & Chaos Labs: Risk assessment and parameter recommendations

• Finance:

  • Karpatkey & TokenLogic: Treasury management and financial operations

• Technical:

  • Certora: Security and formal verification
  • BGD Labs: Protocol development and technical implementation

• Growth:

  • Aave Chan Initiative (ACI): Growth and business development

Governance Process

Aave governance enables the community to shape the protocol's future through a structured proposal and voting system. This guide explains how governance works and how you can participate effectively.

1. Temperature Check

The process begins with a temperature check on the Aave governance forum. This 5-day period lets the community discuss new ideas and provide initial feedback. New proposers can use the Skyward program through Aave Chan Initiative for guidance on their first proposals.

2. First Snapshot Vote

If the temperature check shows promise, the proposal moves to a Snapshot vote. The community votes "YAE" or "NAE," with a minimum requirement of 320,000 AAVE voting in favor to proceed. This ensures significant community support before moving forward.

3. ARFC (Aave Request for Comments)

During this 5-day technical review phase, service providers and community members examine the proposal's details and implications. Proposers can publish addendums to address feedback and improve their proposals.

4. Second Snapshot Vote

A second community vote confirms support for the technical specifications. The same 320,000 AAVE minimum applies. Failed proposals return to the ARFC stage for refinement.

5. AIP (Aave Improvement Proposal)

The final stage is an on-chain vote lasting 3 days. Successful AIPs are automatically implemented through smart contracts.

Special Processes

Asset Listing

Aave has streamlined the process for adding new assets while maintaining security standards. Risk providers must submit thorough analysis, but the timeline is accelerated compared to standard proposals.

Chain Deployment

When deploying Aave to new blockchains:

1. ACI submits technical documentation within 7 days of the ARFC Snapshot
2. Certora conducts a 21-day security review
3. Failed reviews pause the process for 30 days
4. Successful reviews continue through standard governance

Technical Updates

BGD Labs manages routine technical maintenance through a simplified process:

• Posts forum thread for discussion
• 3-day review period
• Proceeds directly to AIP if no significant concerns arise

Security and Management

Guardian System

Aave maintains two types of guardians for emergency protection:

• Protocol Guardian: Can pause markets during security threats
• Governance Guardian: Can veto malicious governance actions

Steward System

Specialized stewards manage key protocol aspects:

• GHO Stewards: Monitor and adjust stablecoin parameters
• Risk Stewards: Oversee critical risk settings
• Finance Stewards: Handle treasury operations

Bug Bounty Program

BGD Labs and Avara manage a bug bounty program through Immunefi to reward security researchers who identify potential vulnerabilities. Immunefi receives 10% of bounty payments.

Service Provider Ecosystem

Aave works with specialized teams to maintain protocol health:

Risk Management

• Chaos Labs and LlamaRisk: Analyze and monitor protocol risks
• Provide regular parameter recommendations

Treasury Management

• Karpatkey and TokenLogic: Manage protocol finances
• Optimize treasury operations

Technical Services

• Certora: Security verification
• BGD Labs: Protocol development
• Aave Chan Initiative: Growth and business development

Participation Guidelines

For Proposers

• Review existing proposals and discussions
• Use clear, specific language
• Respond to community feedback
• Keep documentation current

For Voters

• Read proposals thoroughly
• Consider expert feedback
• Participate in discussions
• Vote in all relevant stages

Resources

• Governance Forum: For discussions and proposals
• Snapshot: For off-chain voting
• GitHub: For technical implementations
• Documentation: For process guidelines