AAVE-logo

AAVE

Aave is a decentralized non-custodial liquidity protocol where users can participate as suppliers or borrowers in a common pool. Suppliers provide liquidity to earn a passive income, while borrowers are able to borrow in an overcollateralized (perpetually) or undercollateralized (one-block liquidity) fashion.

ETH
Defi
Asset Management
DAO
Lending
Stablecoin
Staking
Solidity
Maximum Bounty
$1,000,000
Live Since
18 October 2023
Last Updated
09 September 2024
  • PoC required

  • KYC required

Rewards

AAVE provides rewards in AAVE, BGD on Ethereum, denominated in USD.

Rewards by Threat Level

Smart Contract
Critical
USD $50,000 to USD $1,000,000
High
USD $10,000 to USD $75,000
Medium
USD $10,000
Low
USD $1,000

Rewards are distributed according to the impact the vulnerability could otherwise cause based on the Impacts in Scope table further below.

Reward Calculation for Critical Level Reports

For critical Smart Contract bugs, the reward amount is 10% of the funds directly affected up to a maximum of USD 1 000 000. The calculation of the amount of funds at risk is based on the time and date the bug report is submitted. However, a minimum reward of USD 50 000 is to be rewarded in order to incentivize security researchers against withholding a bug report. There needs to be an absolute minimum of USD 10 000 at risk in order to be considered Critical.

Reward Calculation for Direct theft of any funds in the Aave Treasury

For the impact “Direct theft of any funds in the Aave Treasury”, which is considered as High, the reward amount is 10% of the funds directly affected up to a maximum of USD 75 000. The calculation of the amount of funds at risk is based on the time and date the bug report is submitted. However, a minimum reward of USD 10 000 is to be rewarded. There needs to be a minimum of USD 5 000 at risk in order to be considered as High affecting the Aave Treasury.

Repeatable Attack Limitations

In cases of repeatable attacks for smart contract bugs, the amount of funds at risk will be calculated within the first 45 minutes from the first attack, inclusive, no matter how many times the attack can be executed within that time frame, as demonstrated by the PoC provided by the security researcher.

Example 1: vulnerability is discovered that can steal USD 1 million 30 times within 45 minutes from the first execution of the attack, then the funds at risk is considered as USD 30 million.

Example 2: if a vulnerability is discovered that can steal USD 1 million once every 45 minutes from the first execution of the attack, then the funds at risk is considered as USD 1 million.

However, for smart contracts directly holding funds that can’t be protected, if a discovered vulnerability includes the temporary locking of funds that could otherwise be withdrawn and thus prevented from being stolen but still accessible to the exploiter to take the funds, the time is extended to the exact same time as temporary locking. Extensions of the temporary locking that introduce a gap where withdrawals can happen will not be considered.

Reward Calculation for High Level Reports

High smart contract vulnerabilities will be capped at up to 100% of the funds affected. In the event of temporary locking, the reward doubles for every additional 3600 blocks that the funds or NFTs could be temporarily locked, rounded down to the nearest multiple of 3600 blocks, up to the hard cap of USD 75 000. However, there is a further hard cap of 1000% of the funds affected after the multiplier effect of the duration of temporary locking.

If the duration of temporary locking is 3600 blocks or less, then the severity level will be reduced to Medium if the amount is equal to or greater than USD 1 000 000. If not, the severity level will be downgraded to Low.

There needs to be a minimum of USD 5 000 at risk in order for a report to be considered High.

Unless downgraded, all bug reports with a severity level of High at the end of the evaluation of the bug report will have a minimum reward of USD 10 000.

Restrictions on Security Researcher Eligibility

Security researchers who fall under any of the following are ineligible for a reward

  • Official Contributors, defined as:
    • Developers who have worked on Aave Labs, BGD or any forks of the protocol at any point in time. Contributor with a meaningful amount of commits on Aave-related repositories.
    • Security auditors that directly or indirectly participated in the review of exactly the code impacted.
    • Entities that were compensated anyhow with funds of the DAO (excluding bounties recipients).
    • Whitehats who already reported the same type of bug, with the same type defined as easy to infer by an Aave-expert party, like the Immunefi reviewers.
  • Former Official Contributors are eligible if their last contribution has been more than 24 months before the bug report. For avoidance of doubt, the following are explicitly not ineligible for the bug bounty program:
  • Independent security researchers who didn’t officially review the part of the code impacted.
  • Independent contributors to Aave via small commits.

Previous Audits

GHO

V3.1

V3.0.1 and V3.0.2

V3.0.0

Aave has provided these completed audit review reports for reference. Any unfixed vulnerability mentioned in these reports are not eligible for a reward. However, you are encouraged to review these audits in order to get a better understanding of the codebase

V2

Aave Governance V3

Feasibility Limitations

Bug reports that require an attack that involve one or more other protocols (e.g. utilizing flash loans from a margin protocol or manipulating the spot prices on a DEX), either to make an attack more severe than it would be in isolation, or to achieve an attack that would otherwise be impossible or infeasible, will be downgraded or rejected entirely, at the full discretion of the DAO representatives. However, they will be considered as in-scope and categorized according to the program rules as long as ALL of the following are true:

  • Losses or other negative effects of the attack are inflicted upon Aave ecosystem participants
  • The additional protocols used must have enough liquidity in various assets to allow the attack to succeed at the time of bug report submission. For example: if an attack requires an ETH flash loan, but the amount is larger than all the ETH available for loan across the ecosystem, then this would not be satisfied
  • The attack doesn’t include a dependency on a Chainlink price update.

Proof of Concept (PoC) Requirements

A PoC is required for all Smart Contract bug reports.

All PoCs submitted must comply with the Immunefi-wide PoC Guidelines and Rules. Bug report submissions without a PoC when a PoC is required will not be provided with a reward.

Other Terms and Information

Reward Payment Terms

Payouts are handled by the Aave DAO directly, but in coordination with BGD and Aave Labs, and are denominated in USD. However, payments are done in a mix of AAVE and a stablecoin with a tight correlation to USD 1 with equal to or less than 0.5% average deviation over a period of 1 month preceding the submission of the bug report, at the discretion of BGD Labs.

The calculation of the net amount rewarded is based on the average price of the past 30 days immediately preceding the bug report time. For avoidance of doubt, this will be calculated as exactly 720 hours preceding the bug report time. However, the stablecoin used will always have an effective value of USD 1.

Due to the limitations with DAO payments, each valid bug report will require its own proposal within the DAO for payment. Though this will be coordinated with the DAO representatives and the security researcher submitting the report will not be required to be involved, this delays payments to the end of each month.

As details about the bug report need to be included in the governance proposal, a proposal cannot be made until a fix has been implemented, due to the security risks of publicly disclosing a live vulnerability.

Program Overview

Aave is a decentralized non-custodial liquidity protocol where users can participate as suppliers or borrowers in a common pool. Suppliers provide liquidity to earn a passive income, while borrowers are able to borrow in an overcollateralized (perpetually) or undercollateralized (one-block liquidity) fashion.

For more information about Aave, please visit https://aave.com/.

Aave provides rewards in a mix of AAVE and stablecoins. For more details about the payment process, please view the Rewards by Threat Level section further below.

Aave is represented by its service providers BGD Labs (Aave v2/v3/SM/Governance) and Aave Labs (GHO). BGD and Aave Labs as appointed representatives of the DAO exclusively in this context, based on a successful Aave governance proposal.

KYC Requirement

The provision of KYC may be required for a reward for this bug bounty program at the discretion of the DAO representative or representatives. If KYC is requested, the following information will be required to be done:

  • Live video call where the following may be asked:
    • Government-issued ID

KYC will not be required for bug reports classified with a severity level as Medium or Low.

Responsible Publication

Aave adheres to category 3. This Policy determines what information whitehats are allowed to make public from their submitted bug reports. For more information about the category selected, please refer to our Responsible Publication page.

Primacy of Impact vs Primacy of Rules

Aave adheres to the Primacy of Impact for the following impacts:

  • Smart Contract - Critical - Major manipulation of governance voting result deviating from voted outcome, whenever protection mechanisms (e.g. cancellation of proposal) can’t mitigate the damage.
  • Smart Contract - Critical - Direct theft of any user funds classified as the principal, whether at-rest or in-motion, if more than 100 USD value and representing minimum 1% of the user’s position.
  • Smart Contract - Critical - Permanent locking of user funds classified as the principal, whenever no rescue of any type can be performed.

If an impact is covered within the Primacy of Impact, it means that even if the impacted asset is not in-scope but is owned by the project, then it would be considered as in-scope of the bug bounty program. Only sub-systems of Aave and sub-systems of GHO explicitly mentioned in the section “Other Terms and Information” are considered as owned by the project, anything outside that is not eligible for any bounty. When submitting a report, just select the Primacy of Impact asset placeholder. If the impact affects something in any of the related GitHub repositories, select the placeholder containing the link to the specific repository instead.

If the team behind this project has multiple projects, those other projects are not covered under the Primacy of Impact of this program. Instead, check if those other projects have a bug bounty program on Immunefi.

Testnet and mock files, as well as non-active features, defined as features that 1) are not introduced in production and 2) are not able to be used due to configurations of the protocol, are not covered under the Primacy of Impact.

All other impacts are considered under the Primacy of Rules, which means that they are bound by the terms of the bug bounty program.

Known Issue Assurance

Aave commits to providing Known Issue Assurance to bug submissions through their program. This means that Aave will either disclose known issues publicly, privately via a self-reported bug submission or to the Immunefi team, in order to allow for a more objective and streamlined mediation process to prove that an issue is known. Otherwise, assuming the bug report itself is valid, it would result in the bug report being considered in-scope and due 100% of the reward with respect to the bug bounty program terms.

For privacy and security reasons, self-reported bug submissions will only have a hash as its contents. In the event that proof is needed to demonstrate that the issue is known, the respective file will be sent for evaluation to check if the hashes match with the earlier self-reported entry.

Immunefi Standard Badge

Aave has satisfied the requirements for the Immunefi Standard Badge, which is given to projects that adhere to our best practices.

Governance-Run Program

This bug bounty program is governed by a governance proposal. To view the governance proposal poll, visit https://app.aave.com/governance/proposal/?proposalId=325 .

KYC required

The submission of KYC information is a requirement for payout processing.

Participants must adhere to the Eligibility Criteria.

Proof of Concept

Proof of concept is always required for all severities.

Responsible Publication

Category 3: Approval Required

Prohibited Activities

Default prohibited activities
  • Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
  • Any testing with pricing oracles or third-party smart contracts
  • Attempting phishing or other social engineering attacks against our employees and/or customers
  • Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
  • Any denial of service attacks that are executed against project assets
  • Automated testing of services that generates significant amounts of traffic
  • Public disclosure of an unpatched vulnerability in an embargoed bounty
  • Any other actions prohibited by the Immunefi Rules

Feasibility Limitations

The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity. Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.