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.
The objective is to better align bounty incentives with the actual risk profile of each part of the Aave ecosystem, simplify operational review paths, harmonize severity levels across platforms where appropriate, and preserve flexibility while the DAO evaluates platform performance across Immunefi, Sherlock, and Cantina.
Under this proposal, bug bounty coverage would be organized individually as follows:
-
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
The Aave V3 on Aptos bug bounty program is currently funded by Aave Labs. As part of the Aave Will Win effort, this cost would be transferred to the Aave DAO.
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.
A more granular structure improves on that in several ways:
-
each subsystem can have a bounty framework proportionate to its own risk surface
-
each program can have a clearer, shorter scope definition
-
operational handling becomes simpler when each program has a defined lead review path
This proposal also reflects the current state of the protocol. Aave V4 is now live and should move to a payout ceiling that better reflects its strategic importance and production deployment. Aave V3 on Aptos already operates under a separate bounty setup and can remain unchanged in structure, with funding responsibility migrating from Aave Labs to the DAO under the Aave Will Win effort. The same logic applies to GHO, non-liquidity infrastructure and Aave App Stack, where the impact model differs from the core liquidity protocol. Core Aave V2 is retained as a separate program because the applicable impacts and coverage restrictions differ from Core Aave V3 and should remain explicit.
Rationale for maintaining multiple platforms
This proposal does not seek immediate consolidation onto a single bug bounty platform. Different platforms have shown different strengths across researcher reach, submission quality, triage model, spam filtering, and ecosystem fit. Under this proposal, the platform allocation is:
-
Immunefi for Core Aave V3, Core Aave V2, GHO, and non-liquidity protocol infrastructure
-
Sherlock for Aave V4 and Aave App Stack
-
Cantina for Aave V3 on Aptos
Maintaining this structure for the next 6 to 12 months allows the DAO to compare operational outcomes using live data before deciding whether consolidation is beneficial.
The review can consider:
-
report quality and validity rate
-
spam load and triage burden
-
time to first response and time to resolution
-
researcher participation and coverage quality
-
overall operational overhead
At the end of that period, the DAO can evaluate whether consolidation improves efficiency without reducing security coverage or report quality.
To preserve researcher visibility despite the multi-platform setup, the different bug bounty programs would remain discoverable through aave.com/security, which would serve as a single entry point to the different programs.
Specification
This ARFC proposes the following protocol-wide bug bounty structure.
Program structure
-
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
-
Added: Umbrella V3, and Umbrella V4 when ready
-
Added: Aave Delivery Infrastructure (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.
Disclaimer
This ARFC is posted by Aave Labs in its capacity as a contributor proposing an updated approach to Aave DAO bug bounty operations. Decisions and approvals belong to the DAO via the standard governance process.
Immunefi, Sherlock, and Cantina are third-party service providers. Final implementation details, operational setup, and any required commercial updates would follow the applicable governance or operational processes.
Copyright
Copyright and related rights waived via CC0.