AAVE

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

• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/audits/2023-03-01_ABDK.pdf
• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/audits/2022-08-12_Openzeppelin-v1.pdf
• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/audits/2022-11-10_Openzeppelin-v2.pdf
• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/audits/2023-07-06_SigmaPrime.pdf
• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/audits/2023-09-20_GSM_Stermi.pdf
• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/audits/2023-10-23_GSM_SigmaPrime.pdf
• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/certora/reports/Aave_Gho_Formal_Verification_Report.pdf
• https://github.com/aave/gho-core/blob/c351f895b4eadde317157c4e456690689c2a4a79/certora/reports/Formal_Verification_Report_of_GHO_Stability_Module.pdf

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

• https://github.com/aave/aave-v3-core/blob/master/audits/23-12-2022_SigmaPrime_AaveV3-0-1.pdf
• https://github.com/aave/aave-v3-core/blob/master/certora/Aave_V3.0.1_Formal_Verification_Report_Dec2022.pdf
• https://github.com/aave/aave-v3-core/blob/master/audits/09-12-2022_PeckShield_AaveV3-0-1.pdf
• https://github.com/bgd-labs/proposal-3.0.2-upgrade/blob/main/audits/19-04-2023_SigmaPrime_AaveV3-0-2.pdf

V3.0.0

• https://github.com/aave/aave-v3-core/blob/master/audits/27-01-2022_ABDK_AaveV3.pdf
• https://github.com/aave/aave-v3-core/blob/master/audits/27-01-2022_SigmaPrime_AaveV3.pdf
• https://github.com/aave/aave-v3-core/blob/master/certora/Aave_V3_Formal_Verification_Report_Jan2022.pdf
• https://github.com/aave/aave-v3-core/blob/master/audits/14-01-2022_PeckShield_AaveV3.pdf
• https://github.com/aave/aave-v3-core/blob/master/audits/07-01-2022_TrailOfBits_AaveV3.pdf
• https://github.com/aave/aave-v3-core/blob/master/audits/01-11-2021_OpenZeppelin_AaveV3.pdf

V2

• https://github.com/aave/protocol-v2/tree/master/audits

Aave Governance V3

• https://github.com/bgd-labs/aave-governance-v3/tree/main/security/sp
• https://github.com/bgd-labs/aave-governance-v3/tree/main/security/certora/reports

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

• “Sub-systems of Aave” are the following: Aave liquidity pools (including v2 and v3 in the same), Aave Governance, Aave Safety Module and GHO stablecoin.

• “Active liquidity pool instances” are Aave v2 in Ethereum, Polygon and Avalanche; Aave v3 in Ethereum, Polygon, Avalanche, Optimism, Arbitrum, Metis, Base, GnosisChain, BNBChain and Scroll.

• “Aave Treasury” is defined as each one of the Aave Collector smart contracts in the different networks, connected to “Active liquidity pool instances”. Only components of these instances are considered active and eligible for bounties, no matter if included or not in aave-address-book.

• “Active safety module instances” are: stkAAVE, stkABPT and stkGHO.

• “GHO stablecoin” contracts are: GHO Token and facilitators listed as assets in scope (including GHO reserve of Aave Pool, GHO FlashMinter and GSM).

• Only components of these instances are considered active and eligible for bounties, no matter if included or not in aave-address-book.

• Whenever the same bug is fixed or anyhow mitigated in any instance of the same sub-system, it is considered as known by the project and not eligible for bounty.

• 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 from what is disclosed in said compiler bug.

• 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, or any other internal operational procedure. 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.

• All addresses of eligible assets can be found on the following links:

  • Aave v2 Ethereum https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV2Ethereum.sol
  • Aave v2 Polygon https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV2Polygon.sol
  • Aave v2 Avalanche https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV2Avalanche.sol
  • Aave v3 and Governance Ethereum https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Ethereum.sol, https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Ethereum.sol
  • Aave v3 Polygon https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Polygon.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Polygon.sol
  • Aave v3 Optimism https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Optimism.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Optimism.sol
  • Aave v3 Arbitrum https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Arbitrum.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Arbitrum.sol
  • Aave v3 Avalanche https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Avalanche.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Avalanche.sol
  • Aave v3 Metis https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Metis.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Metis.sol
  • Aave v3 Base https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Base.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Base.sol
  • Aave v3 Gnosis https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Gnosis.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Gnosis.sol
  • Aave v3 BNBChain https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3BNB.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3BNB.sol
  • Aave v3 Scroll https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV3Scroll.sol https://github.com/bgd-labs/aave-address-book/blob/main/src/GovernanceV3Scroll.sol
  • Aave Safety Module https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveSafetyModule.sol
  • GHO https://github.com/bgd-labs/aave-address-book/blob/main/src/MiscEthereum.sol

• 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
  • Governance
  • VotingStrategy
  • GovernancePowerStrategy
  • VotingMachine
  • PayloadsController

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.