[ARFC] Aave Risk Framework

Summary

This framework sets the risk standard that governs every asset on Aave V3, V4, and Aave Horizon. It is binding at onboarding, at every quarterly due diligence refresh, at every material-change re-evaluation, and at every parameter or deprecation decision taken on a listed asset. The requirements, evaluation points, and procedures below are to become the standard against which every listing and every parameter decision is measured once the framework is endorsed.

Asset safety on Aave is the union of every chain it lives on, every bridge it crosses, and every operational decision its issuer makes between reviews. The framework reflects that surface in full and reinforces continuity in the monitoring of the asset risk vectors as well as automation of the defensive actions.

The framework is organised into four layers, each addressing a distinct class of risk and a distinct timescale of control.

Layer 1: Asset Risk carries the lifecycle, the qualitative onboarding requirements, the continuous due diligence cadence, the material-change taxonomy, and the conditions under which a reserve or an entire market deployment is wound down.

Layer 2: Bridging Risk defines the mandatory bridge configuration baseline that any asset crossing chains must satisfy, the lifecycle for managing those configurations, and the evaluation pillars applied to every bridging stack in use.

Layer 3: Monitoring and Automated Risk Oracle Systems defines the enforced automated monitoring of Aave-external layers, the continuous risk oracles and automated freeze guardians that act between adverse events and human response, the Risk Stewards' role as the human-paced complement, and Umbrella's role as the safety net. These are risk management mechanisms rather than discretionary tooling, and the framework codifies them as standing infrastructure because the risks they address are not fully manageable through onboarding requirements and continuous reviews alone.

Layer 4: Chain Risk codifies the chain-level evaluation that gates whether Aave should deploy on a chain at all and the standing chain properties that constrain the exposure tier of every asset listed on the deployment, it functions as a precondition to Layers 1 through 3, because every asset and bridging decision on a chain inherits that chain's properties.

1. Asset Risk

An asset's life on Aave passes through four stages: onboarding, continuous due diligence, material-change re-evaluation, and an unlikely deprecation. Listing breadth in itself does not signal elevated risk, because exposure is gated at the parameter level long before it becomes systemic. The question this layer answers at every stage is not whether the protocol holds a long list of reserves, but whether each reserve continues to fit the risk and operational profile that justifies its presence. The subsections below define the requirements applied at each stage and the triggers that advance an asset between stages.

This framework is designed to operate alongside the Technical Asset Listing Framework proposed by Aave Labs, and the two complement each other during the asset evaluation phase. Read together they are what makes a veto authority exercisable, since the technical framework establishes whether an asset technically can be listed and surfaces material technical concerns, while this framework determines whether it may be listed from the risk surface perspective and at what exposure tier, and holds the explicit veto. Where a subsection below covers ground that the Technical Asset Listing Framework also addresses, the relevant section of that framework and the specific additional requirements it carries are noted in the subsection itself, so the technical requirement and its risk treatment are read together.

1.1 Asset Classification Adherence

Equivalently as indicated in the Technical Framework, every asset must map to a governance-ratified Aave Asset class Allowlist (AAcA) before listing, because the class determines the parameter stack, the relevant E-Mode configurations, and the comparable assets the parametrisation is benchmarked against. Onboarding outside an existing class is structurally ambiguous and not accepted under the framework until the asset is included in a newly created class.

Requirements:

• The asset is mapped to an existing governance-ratified asset class (stablecoin group, ETH-correlated group, BTC-correlated group, RWA, or other class formally defined by Aave governance) before listing.
• Assets that do not fit an existing class require explicit class definition through Aave governance before listing, not ad-hoc onboarding under an analogous but non-binding category.
• The closest comparable asset already listed under the same class is identified and could be used as a comparable reference for oracle design, LTV, LT, CF, caps, and Credit Lines subject to the new asset's own technical profile.

Onboarding under an unconfirmed or out-of-class designation is treated as a hard block at the pre-screening stage, therefore listings for such assets would first need to be approved via the asset class allowlist.

1.2 Multi-Chain Evaluation Scope

An asset's risk profile is the union of every chain it lives on and every configuration its issuer has shipped. A fixed snapshot or chain-local evaluation is structurally insufficient because an exploit, misprint, or governance action on one chain inevitably affects stability on every chain where the asset is deployed and translates directly to stress on the lending protocol.

Requirements:

• Every chain the asset is or will be deployed on through Aave is examined as part of the same evaluation.
• Per-chain bridge topology is documented for every cross-chain route carrying Aave exposure.
• Per-chain smart contract divergence, including proxy implementation and smart contract structure, is documented and reconciled to the latest audited version.
• Per-chain access-control and parameter divergence is documented.
• Per-chain oracle path and adapter configuration is documented.

Material divergence across chains that cannot be reconciled to a single documented configuration profile materially constrains the asset's cross-chain exposure tier.

1.3 Smart Contract Audit Coverage

Audits are the standing technical attestation that the asset's contracts implement the design the framework's other operational controls assume. Recency matters as much as existence because the threat landscape and the asset's contracts both evolve between audits.

Requirements:

• The deployed version of the asset is covered by audits from reputable firm(s) completed with a published audit report.
• Re-attestation is required on every subsequent material upgrade rather than reliance on the original audit.
• Bridge-side contracts on every deployed chain are reviewed under the same standard as the asset contract itself, because the bridge contract is part of the asset on the destination chain.
• Audit reports are provided to the risk provider; any unresolved findings are disclosed.
• Past incidents on any deployed version are disclosed with post-mortem and documented remediation.

Audits without re-attestation on subsequent material upgrades, unresolved Critical or High findings, or past exploits without documented remediation are hard-block conditions. This matches the requirements of the technical listing framework.

1.4 Bug Bounty Coverage

A live bug bounty program is the only standing financial incentive aligning external security researchers with the asset's safety. Detailed expectations are set out in the LlamaRisk Bug Bounty Landscape report and form the baseline applied here.

Requirements:

• A live bug bounty program covering the asset and its critical dependencies is in place at listing and maintained continuously.
• Minimum payout floor of $50,000 for a critical finding as an absolute minimum regardless of TVL.
• Maximum payout that scales with the protocol’s TVL, sized using bounty value per million dollars of TVL as the reference metric, with comparisons of this metric for current Aave assets presented in the Bug Bounty Landscape document.
• Scope covers loss of user funds, private-key or password exposure, user-information disclosure, unauthorised state-modifying actions, infrastructure compromise, domain takeover, and malicious redirection. Smart-contract-only scope is not sufficient anymore.
• The program is preferably platform-managed (Immunefi, HackerOne, or equivalent) given platform-managed programs' professional triage, credibility, and stronger researcher network effects.

Missing or materially weak bug bounty coverage is a hard-block condition.

---

Due to the Snapshot character limit, the remainder of this proposal can be viewed on the Aave Governance forum.