Aave V4 Bounty Program

Aave V4 introduces a Hub-and-Spoke architecture, where the Hub manages shared liquidity and Spokes implement asset-specific supply and borrow logic. Spokes are modular components that can connect to one or more Hubs, routing user actions (supply, withdraw, borrow, repay) based on reserve configuration and capacity constraints.

The protocol retains core functionality from previous versions while extending the design to support additional mechanisms such as collateral-level risk premiums, reinvestment strategies, and more flexible risk configuration, enabling support for more heterogeneous assets and scalable system behavior.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Likelihood. The combination of these factors determines the severity and guides the reward amount.

Severity Levels

Vulnerabilities will be classified according to the following severity levels:

• Critical
  • Direct theft of user funds (at least 100,000 USD at risk)
  • Permanent freezing of user funds (>100,000 USD)
  • Protocol insolvency due to accounting errors
  • Unauthorized minting of tokens (>100 USD worth of tokens can be minted).
  • Permanent modification of protocol parameters leading to a significant loss
• High
  • Direct theft of user funds (<100,000 USD and >100 USD at risk)
  • Temporary freezing of user funds (>2 days)
  • Theft of unclaimed yield (>100 USD at risk)
  • Permanent freezing of unclaimed yield
  • Significant manipulation of oracle prices affecting protocol operations
• Medium
  • Smart contracts are inoperable due to a lock of funds
  • Griefing attacks causing temporary service disruption (either >12 hours of functionality DOS without lock of funds, or short-term time-sensitive functionality DOS)
  • Unbounded gas consumption (>10% more gas consumed)
  • Temporary freezing of funds (>12 hours and <2 days)
  • Incorrect interest rate calculations affecting protocol economics
• Low/Informational
  • Issues not directly impacting user funds or protocol operations
  • Best practice violations
  • Minor deviations from specifications
  • Code quality issues
  • Lack of input validation without security implications

Impact Assessment

The severity level of a vulnerability will be determined based on both its impact and likelihood:

• Impact Factors
  • Amount of funds at risk
  • Number of users affected
  • Duration of the vulnerability's effect
  • Complexity of exploitation
  • Requirement for privileged access
• Conditional Factors
  • Technical complexity of the exploit
  • Required preconditions for exploitation
  • Opportunity window for exploitation

Reward Structure

Reward Amounts

Rewards will be paid in USD-pegged stablecoins according to the following structure:

Severity Level	Reward Range
Critical	25,000 USD - 500,000 USD
High	5,000 USD - 25,000 USD
Medium	Flat 5,000 USD
Low	Flat 1,000 USD

• Reward Calculation for Critical Vulnerabilities
  • For critical vulnerabilities, the reward amount will be calculated as 10% of the funds directly affected, up to a maximum of 500,000 USD. The calculation of the amount of funds at risk will be based on the time and date the bug report is submitted.
  • A minimum reward of 25,000 USD will be awarded for critical vulnerabilities to incentivize security researchers against withholding bug reports. There needs to be an absolute minimum of 10,000 USD at risk for a vulnerability to be considered Critical.
• Reward Calculation for High Severity Vulnerabilities
  • For high-severity vulnerabilities, rewards will be capped at up to 100% of the funds affected, with a maximum of 25,000 USD. In the case of temporary locking of funds, the reward will increase based on the duration of the lock, up to the maximum amount.
• Bonus Considerations
  • Additional bonuses may be awarded for:
    • Exceptional quality of the vulnerability report
    • Provided fix or mitigation strategy
    • Novel attack vectors or vulnerability types
    • Vulnerabilities affecting multiple components

General Notes

• Sherlock's Criteria for Issue Validity guide can be a helpful resource for more context on out-of-scope issues, etc. but nothing in the guide should overrule the definitions above
• A coded Proof of Concept (POC) with instructions to run the POC is required
• If the protocol team has the ability to take measures (upgrade the contract, pause the contract, etc.) against an exploit, the potential damage is limited to a 1-hour exploit period before it is assumed that the protocol team takes measures to prevent further damage

Platform Rules

Please review the Sherlock Bug Bounty Platform Rules before submitting any vulnerability.

Scope

Out of scope

• Chainlink feeds are assumed to operate correctly, remain available, and not deviate from expected behaviour. Incorrect data or pricing information supplied by third-party oracles is out of scope.
• Vulnerabilities that have already been reported or are known to the Aave team
• Issues that have been identified in previous audits and are pending fixes
• Vulnerabilities in the blockchain itself
• Issues in third-party libraries or dependencies not developed by Aave
• Theoretical vulnerabilities without a working proof of concept
• Issues requiring privileged access (e.g., governance or admin keys)
• Economic or tokenomic vulnerabilities that do not result in direct loss of funds
• Gas optimization issues without security implications
• Centralization risks inherent to the protocol design
• UI/UX issues that do not impact security
• Documentation errors or inconsistencies
• Spelling or grammar mistakes
• A one-block DOS — where the attacker causes a transaction to revert in a single block, but it can be successfully re-executed in the next block — is evaluated based on that single occurrence only, even if the attack is theoretically repeatable. Such an issue is presumed not to repeat. It qualifies as valid only if the affected functionality is clearly time-sensitive.

Disclosure Policy

All vulnerabilities must be reported exclusively through the Sherlock platform and must not be disclosed publicly until:

1. The vulnerability has been verified by the Aave team
2. A fix has been implemented and deployed
3. The Aave team has granted explicit permission for public disclosure
   Premature public disclosure can result in disqualification from the reward.

Testing

When testing for vulnerabilities:

• Do not test on public mainnet deployments
• Use local test environments or testnets for all testing
• Do not attempt to access or modify other users' data
• Do not perform any actions that could disrupt the normal operation of the protocol
• Do not use automated scanning tools without manual verification

Prohibited actions

The following actions are strictly prohibited:

• Attempting to access private user data
• Social engineering or phishing attacks
• Denial of service attacks
• Physical or electronic attempts to access Aave infrastructure
• Any testing that violates applicable laws or regulations
• Threatening or harassing behavior

Additional Context

Chains in scope

Ethereum for initial deployment.

Trusted protocol roles

Privileged roles are trusted actors (Aave DAO and governance-approved executors). Their parameter changes are considered honest, and misconfiguration is out of scope.

That said, the codebase does enforce specific hard limits on certain configuration values:

• Asset decimals: Assets must fall within a predefined minimum (MIN_ALLOWED_UNDERLYING_DECIMALS) and maximum (MAX_ALLOWED_UNDERLYING_DECIMALS) decimal range; assets outside these bounds cannot be listed.
• Collateral risk score (collateralFactor): Each asset’s collateral risk value is capped by a maximum allowed risk, preventing governance from setting risk scores beyond the upper bound enforced by the protocol.
• Liquidation logic: the maximum liquidation bonus (maxLiquidationBonus) is constrained to a protocol-defined minimum; the product of the maximum liquidation bonus and the collateral risk score is bounded by a global upper limit; and the liquidation fee (liquidationFee) itself is capped by a protocol‑defined maximum.

Beyond these explicit constraints, most configuration values rely on governance processes rather than on-chain caps, consistent with the “trusted admin” assumption.

Tokens

Only explicitly whitelisted ERC20 tokens are accepted. Whitelisting is enforced via governance-controlled configuration and assumes:

• ERC20 compliance without non-standard hooks (no ERC777, no callbacks).
• No fee-on-transfer, rebasing, reflection, or balance-mutation side effects.

Asset onboarding follows the Aave DAO’s technical and risk due diligence process, executed by service providers before governance approval. If the tokens are incompatible with the codebase, then they won't be used.

Design choices

Aave V4 adopts a Liquidity Hub as the canonical accounting layer for all assets: available liquidity, drawn and premium liabilities. User flows are implemented in external Spokes, which initiate Hub mutations and perform asset transfers. The Hub enforces global invariants and liquidity provisioning; Spokes handle borrow logic and risk configuration logic.

All Spokes are governance-permissioned modules. Governance explicitly authorizes which Spokes may call Hub mutators for each asset and maintains the allowlist.

Hub ↔ Spoke Trust Boundary

The system defines an asymmetric trust model:

• The Hub is the authoritative ledger.
• Permissioned Spokes orchestrate user actions and decide operational details such as:
  • the source and destination addresses for ERC20 transfers between the user and the Hub,
  • when user premium bookkeeping occurs,
  • manage donations within the Spoke.

Spokes operate under Hub-enforced global invariants and per-Spoke caps/flags that throttle or isolate flows without halting the protocol.

Implications:

• A malicious or compromised Spoke could misuse its privileges. E.g., drawing all the liquidity up to the draw cap and never return it. This risk is out of scope and mitigated by governance gatekeeping, since only approved Spokes can invoke Hub mutators. Hence, Spokes are considered trusted entities, working in a legit way.

Collateral Risk Framework

Each reserve receives a dynamic risk score (0–1000 %) controlled by governance. This score feeds into the final interest rate computation resulting in a risk-adjusted rate: low-risk assets map to lower borrowing costs, and higher-risk assets incur higher effective rates.

Protocol Resources

• Aave V4 Documentation
• Aave V4 Technical Overview
• The Potential of Aave V4
• All onchain deployments for the in-scope assets will be maintained on: Address-book
  • Ethereum