[ARFC] Update Aave DAO Bug Bounty Program Structure

Summary

Aave Labs proposes restructuring the Aave DAO bug bounty framework into multiple subsystem-specific programs, each with its own scope, severity criteria, payout framework, and operating platform.

Motivation

Aave no longer operates as one homogeneous smart contract system. Core Aave V3, Core Aave V2, GHO, governance and other non-liquidity infrastructure, Aave V4, Aave V3 on Aptos, and Aave App Stack each have materially different architecture, threat models, and user impact.

A single unified bug bounty program forces one shared set of eligibility rules, severity assumptions, and payout tiers across systems that do not share the same risk profile. That creates avoidable ambiguity for both researchers and reviewers.

Specification

This ARFC proposes the following protocol-wide bug bounty structure.

Program Structure

Program	Platform
Core Aave V3	Immunefi
Core Aave V2	Immunefi
GHO	Immunefi
Non-liquidity protocol infrastructure	Immunefi
Aave V4	Sherlock
Aave V3 on Aptos	Cantina
Aave App Stack	Sherlock

Each program will have its own published scope, severity framework, payout table, and platform-specific operating setup where applicable.

Submissions would be reviewed by the main technical team responsible for the relevant scope together with the respective audit firm or platform review team. For each program, those teams would align on scope interpretation, severity classification, reward amounts, and other relevant factors before finalizing conclusions on eligible reports.

Payout Framework

The following tables summarize the current and proposed payout structure for each program.

Sherlock and Cantina already operate under aligned severity levels. Under this proposal, the intention is to update the Immunefi programs so that their severity levels are aligned with the Sherlock and Cantina framework as well, while preserving any program-specific scope restrictions, such as those applicable to Core Aave V2.

Core Aave V3

Severity	Current Min	Current Max	Proposed Min	Proposed Max
Critical	$50,000	$1,000,000	$100,000	$5,000,000
High	$10,000	$75,000	$25,000	$75,000
Medium	$10,000	$10,000	$10,000	$10,000
Low	$1,000	$1,000	$5,000	$5,000

Core Aave V2

For assets labeled as Aave V2 and deployed on Ethereum, only Critical and High impacts are in scope.

For assets labeled as Aave V2 and deployed on Ethereum’s L2s, only Critical impacts are in scope.

Severity	Current Min	Current Max	Proposed Min	Proposed Max
Critical	$50,000	$1,000,000	$100,000	$1,000,000
High	$10,000	$75,000	$10,000	$50,000
Medium	—	—	—	—
Low	—	—	—	—

GHO

Scope would be reviewed and expanded where needed as part of implementation.

Severity	Current Min	Current Max	Proposed Min	Proposed Max
Critical	$50,000	$1,000,000	$50,000	$1,000,000
High	$10,000	$75,000	$25,000	$75,000
Medium	$10,000	$10,000	$10,000	$10,000
Low	$1,000	$1,000	$5,000	$5,000

Non-liquidity Protocol Infrastructure

This bucket would include:

• Governance V3
• Aave Safety Module StkAAVE V3 and stkABPT
• Umbrella V3, and Umbrella V4 when ready
• Aave Delivery Infrastructure, or aDI

Severity	Current Min	Current Max	Proposed Min	Proposed Max
Critical	$50,000	$1,000,000	$50,000	$1,000,000
High	$10,000	$75,000	$25,000	$25,000
Medium	$10,000	$10,000	$10,000	$10,000
Low	$1,000	$1,000	$5,000	$5,000

Aave V4

Severity	Current Min	Current Max	Proposed Min	Proposed Max
Critical	$25,000	$500,000	$100,000	$2,500,000
High	$5,000	$25,000	$10,000	$25,000
Medium	$5,000	$5,000	$5,000	$10,000
Low	$1,000	$1,000	$1,000	$5,000

Aave V3 on Aptos

Severity	Current Min	Current Max	Proposed Min	Proposed Max
Critical	$25,000	$500,000	$100,000	$1,000,000
High	$5,000	$25,000	$10,000	$50,000
Medium	$5,000	$5,000	$5,000	$10,000
Low	$1,000	$1,000	$1,000	$5,000

Aave App Stack

Severity	Current Min	Current Max	Proposed Min	Proposed Max
Critical	—	—	$50,000	$100,000
High	—	—	$10,000	$25,000
Medium	—	—	$5,000	$10,000
Low	—	—	$1,000	$5,000

In cases where a single vulnerability clearly affects multiple subsystems, the payout framework should escalate to the most critical affected subsystem.

For example, if a vulnerability in a GHO component could be used to create a loss-of-funds scenario for Core Aave V3, the Core Aave V3 payout framework should apply.

Payment Process

While the programs are split operationally, payout execution can remain unified at DAO level.

Valid payouts across programs can continue to be batched through periodic treasury proposals or another DAO-approved payout flow, reducing governance overhead while preserving subsystem-specific evaluation.

Funding Responsibility

Core Aave V3, Core Aave V2, GHO, non-liquidity protocol infrastructure, and Aave V4 programs are funded by the Aave DAO. Similarly, Aave App Stack would fall under the Aave DAO funding responsibilities.

The Aave V3 on Aptos program is presently funded directly by Aave Labs. Under the Aave Will Win effort, funding responsibility for the Aave V3 on Aptos bug bounty would be transferred from Aave Labs to the Aave DAO.

After transfer, all programs described in this proposal would be funded by the DAO under the unified payout flow described above.

Transition mechanics, including any required treasury action or reimbursement for the transition period, would be handled through the applicable governance path.

Principles

The proposed structure follows these principles:

• separate programs by subsystem
• keep scope and severity guidance specific to each subsystem
• maintain explicit reviewer ownership for each program
• preserve the ability to compare platform performance before deciding on consolidation
• transfer Aptos bug bounty funding responsibility from Aave Labs to the DAO

Scope

Core Aave V3

This program should cover the production Core Aave V3 liquidity protocol and its explicitly listed production contracts and integrations.

The rewards module would be excluded, including the RewardsController, RewardsDistributor, EmissionManager, and any associated library or contract, given their limited and infrequent use.

Core Aave V2

This program should continue to cover the explicitly listed Core Aave V2 deployments subject to the impact restrictions described in the payout framework.

GHO

This program should cover GHO-specific contracts and infrastructure, including the token system, savings-related contracts, facilitators, bridging components, and other GHO-specific production infrastructure explicitly listed.

In cases where components rely on external integrations or third-party systems, the program may cover only the integration layer or any additional code built on top, while the underlying systems remain out of scope and are covered by their respective programs.

Non-liquidity Protocol Infrastructure

This program should cover governance, Safety Module components, Umbrella, aDI, and other explicitly listed non-liquidity protocol infrastructure.

Aave V4

This program should cover the final list of Aave V4 in-scope repositories, deployed contracts, environments, and official or canonical spokes included in the launch configuration and subsequent production scope updates.

Any non-canonical or third-party spokes would only be in scope if they are separately and explicitly added.

Aave V3 on Aptos

This program should continue to cover the current Aptos deployment under the existing Cantina structure.

Operational scope and severity framework remain unchanged.

The rewards module would be excluded, including the RewardsController and RewardsDistributor, given their limited and infrequent use.

Funding responsibility would transition from Aave Labs to the Aave DAO as part of the Aave Will Win effort.

Aave App Stack

This program should cover Aave V3 App, Aave Pro, Aave Kit, and a number of critical domains and web applications that users and integrators interact with.

The main focus of this program would be vulnerabilities that could directly lead to loss of funds.

Review Period

This structure should remain in place for an initial observation period of 6 to 12 months.

At the end of that period, the DAO can review:

• whether the split structure improved clarity and operational handling
• whether platform diversity improved researcher coverage and report quality
• whether consolidation across one or more platforms would improve efficiency

A subsequent review can be initiated once enough operating data has been collected.

Next Steps

Seek community feedback on the proposed split, payout framework, platform allocation, and Aptos funding transfer to the DAO.

If consensus is reached on this ARFC, move the proposal to Snapshot.

If Snapshot passes, implement the revised multi-program structure and the related funding and operational updates through the appropriate governance paths.