18 October 2023
Live since
Yes
KYC required
$1,000,000
Maximum bounty
11 March 2024
Last updated

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 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 .

Rewards by Threat Level

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

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

V3.0.1 and V3.0.2

V3.0.0

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.

Smart Contract

Critical
Level
USD $50,000 to USD $1,000,000
Payout
PoC Required
High
Level
USD $10,000 to USD $75,000
Payout
PoC Required
Medium
Level
USD $10,000
Payout
PoC Required
Low
Level
USD $1,000
Payout
PoC Required

Assets in scope

All code of Aave can be found at https://github.com/aave/ and https://github.com/bgd-labs . Token addresses can be found at https://github.com/bgd-labs/aave-address-book/tree/main.

Impacts in scope

Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in scope table.

Smart Contract

  • Major manipulation of governance voting results deviating from voted outcome, whenever protection mechanisms (e.g. cancellation of proposal) can’t mitigate the damage.
    Critical
    Impact
  • Direct theft of any user funds classified as the principal, whether at-rest or in-motion
    Critical
    Impact
  • Permanent locking of user funds classified as the principal or funds of the Aave treasury
    Critical
    Impact
  • Protocol insolvency
    Critical
    Impact
  • Direct theft of any funds in the Aave Treasury
    High
    Impact
  • Theft of yield, defined as funds not classified as the principal (not including yield yet to be earned)
    High
    Impact
  • Permanent locking of unclaimed yield of users, defined as funds not classified as the principal (not including yield yet to be earned)
    High
    Impact
  • Temporary locking of funds classified as the principal or funds of the Aave treasury
    High
    Impact
  • Smart contract unable to operate due to lack of token funds
    Medium
    Impact
  • Loss of rewards-to-be-accrued
    Medium
    Impact
  • Manipulation of interest rates (supply or borrow) with mechanisms not intended or limited by design
    Medium
    Impact
  • Unexpected infrastructural behavior
    Medium
    Impact
  • Contract fails to deliver promised returns, but doesn't lose value
    Low
    Impact
  • Griefing
    Low
    Impact
  • Imprecision on accounting (balances, rates)
    Low
    Impact
  • Theft of gas Low
    Low
    Impact
  • Griefing
    Low
    Impact

Keep in mind the restrictions on impacts based on the respective asset:

  • For all assets labeled as “Aave v2” and deployed on the Ethereum network, only Critical and High impacts are in-scope.
  • For all assets labeled as “Aave v2” and deployed on networks other than Ethereum, including L2s on Ethereum, onlyCritical impacts are in-scope.

Out of Scope & Rules

These impacts are out of scope for this bug bounty program.

  • Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
  • Impacts caused by attacks requiring access to leaked keys/credentials or the compromise of access-controlled functions
  • Impacts caused by attacks requiring access to privileged addresses (governance, strategist) except in such cases where the contracts are intended to have no privileged access to functions that make the attack possible
  • Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
  • Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
  • Best practice recommendations
  • Feature requests
  • Impacts on test files and configuration files unless stated otherwise in the bug bounty program
  • Incorrect data supplied by third party oracles
    • Not to exclude oracle manipulation/flash loan attacks
  • Impacts requiring basic economic and governance attacks (e.g. 51% attack)
  • Lack of liquidity impacts, including those based on an asset with low trading volume. That will be considered as belonging to risk control of the protocol, and not eligible in this bug bounty program.
  • Impacts from Sybil attacks
  • Impacts involving centralization risks
  • Impacts requiring the use of non-active features including those not available due to configurations (e.g. risk parameters, flags).

The following activities are prohibited by this bug bounty program:

  • 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