18 October 2023
Live since
Yes
KYC required
$1,000,000
Maximum bounty
12 February 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 - Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results
  • Smart Contract - Critical - Direct theft of any user funds classified as the principal, whether at-rest or in-motion
  • Smart Contract - Critical - Permanent locking of user funds classified as the principal

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. 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 or at the very least privately via a self-reported bug submission 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.

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.

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. For avoidance of doubt, if a 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.

However, for smart contracts directly holding funds that cannot be paused, 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.

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 or BGD at some point in time. Contributor with a meaningful amount of commits on Aave-related repositories.
    • Developers associated with forks of the protocol are also considered official contributors.
    • Security auditors that directly or indirectly participated in the review of the system impacted.
    • Entities that were compensated anyhow with funds of the DAO (excluding bounties recipients).
  • Former Official Contributors who have contributed within 12 months before the bug report

For avoidance of doubt, the following are explicitly not ineligible for the bug bounty program:

  • Independent security researchers.
  • 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

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

  • Exploits consequence of newly publicly available information will be considered only if they are non-evident. Examples:
    • Evident - A stablecoin (listed on Aave) gets exploited and that has immediate consequences on Aave via borrowing attacks or others.
    • Non-evident - A Solidity compiler bug is found, and some logic used on Aave is affected. In addition, the nature of the way the bug affects Aave is totally different for the review team to not link the compiler bug with Aave’s impact.
  • On attacks involving market manipulation, a solid and realistic scenario needs to be presented in order for the bug report to be considered eligible for consideration.
    • Realistic Scenario Example - Manipulation of an asset listed as collateral is possible via flash loans, allowing for borrowing of all available liquidity.
    • Non-Realistic Scenario Example - Manipulation of an asset listed as collateral, but not via flash loans, depending on CL oracle update with the manipulated price, and putting at risk considerable capital.
  • Attacks whose losses materialize via market dynamics, like shorting of AAVE in parallel with the exploit, will not take into account that component when determining the severity level. Thus, other impacts according to the Impacts in Scope Table will be considered when determining the severity level of the bug report.
  • Precision mechanisms on aToken and other tokenization (due to balance growing) are out of scope unless they enable a provable new attack vector involving loss of funds.
  • Loss of rewards-to-be-accrued is initially not considered a loss of funds. Only rewards already accrued would be considered under the loss of funds assessment. Otherwise, this will be downgraded to Medium.
  • 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, only Critical impacts are in-scope.
  • In the event that a vulnerability exists on the GitHub file but not on the most recently deployed contract, this may be due to actions taken to fix a vulnerability quietly and that public announcement is still being planned. Thus, in order to be eligible for a reward, the vulnerability must exist both in the deployed smart contract and the respective GitHub file in the Assets in Scope table, otherwise the bug report will be considered as invalid.
  • The following assets have their inheritance chain of contracts also included as in-scope for the bug bounty program within the limitations of the respective asset being in v2 or v3. The OpenZeppelin base contract, however, is not considered as in-scope. If you find a bug in the inheritance chain of contracts, select the related asset in the Assets in Scope table.
    • Aave v2 LendingPool
    • Aave v2 AToken
    • Aave v2 VariableDebtToken
    • Aave v2 StableDebtToken
    • Aave v3 Pool
    • Aave v3 AToken
    • Aave v3 VariableDebtToken
    • Aave v3 StableDebtToken
    • Aave v3 RewardsController
    • Aave v3 StakedAaveV3
    • Aave v3 GhoAToken
    • Aave v3 GhoVariableDebtToken
    • Aave v3 GhoStableDebtToken

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

  • Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results
    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
  • Theft of gas
    Medium
    Impact
  • Unbounded gas consumption
    Medium
    Impact
  • Loss of rewards-to-be-accrued
    Medium
    Impact
  • Manipulation of interest rates (supply or borrow) with mechanisms not intended by design
    Medium
    Impact
  • Imprecision on accounting (balances, rates)
    Medium
    Impact
  • Unexpected infrastructural behaviour
    Medium
    Impact
  • Contract fails to deliver promised returns, but doesn't lose value
    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