[ARFC] Aave Risk Framework

LlamaRisk · June 9, 2026, 10:56am

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.

1.5 Liquidity and Market Structure

Healthy liquidation depends on the asset having a real secondary market, and oracle stability is itself a function of that secondary market. Liquidity is therefore evaluated as a structural property of the asset rather than as a point-in-time metric.

Requirements:

Secondary market depth is sufficient to clear the largest expected borrower within the asset’s liquidation bonus at acceptable slippage under different benchmarked VaR thresholds, applied individually.
Liquidity-provider diversity within each venue is the primary structural concern, because a single dominant LP concentrates dependency on that LP’s behaviour (withdrawal, mispricing, opportunistic exploitation) regardless of the venue’s headline depth. Multiple venues with diverse LPs per venue is the preferred state. A single deep venue with verified LP diversity is acceptable. A fragmented multi-venue footprint with thin LP diversity offers limited improvement over a single concentrated venue, and therefore should be applied with reasonable allocation constraints. Due to the presence of effective atomic CEX-DEX arbitrage on Ethereum mainnet, centralized exchange liquidity can also be considered. However, CEX or remote chain liquidity will not receive the same treatment as direct onchain liquidity.
Volume profile is assessed qualitatively for the share attributable to organic demand versus incentive-driven flow, since no single metric isolates organic flow cleanly. The assessment draws on incentive and rebate programmes active on the asset’s distribution venues and the share of measured volume eligible for them, the volume profile across incentive cliffs or reductions, trade-size distribution patterns, and holder concentration metrics.
For pegged assets, no sustained deviation from collateral value of 1% or more over a window of two days or longer is acceptable as an E-Mode precondition; sustained deviation also constrains LTV and forces higher LB values or alternatively moves them to a non-collateral state.
In general, but especially for assets with a gated mint and redeem function, the availability of liquidity and liquidator activity in the Chainlink network will be assessed on an ongoing basis.

Insufficient depth relative to the borrower distribution, thin LP diversity within the asset’s deepest venues, or volume substantially supported by active incentive programmes materially constrains caps, LTV, and any E-Mode treatment.

1.6 Timelock Requirements

Timelocks gate the time between an authority deciding to change the asset and that change taking effect onchain. They are the standing control that allows Aave to take mitigating action before a malicious or accidental change executes, and apply on every chain the asset is deployed on rather than only on the primary chain.

Requirements:

Timelocks gate parameter changes that materially affect the asset’s behaviour on Aave.
Timelocks gate mint and burn authority assignments and revocations.
Timelocks gate oracle authority and oracle adapter changes.
Timelocks gate bridge authority and bridge configuration changes (verifier-set, library, rate-limit).
Timelocks gate upgrade paths on every chain the asset is deployed on.
Timelock delay is sufficient for Aave to take mitigating action before the change executes; instantaneous or sub-hour delays are not acceptable.

Absence of a timelock on any of the above authorities is a hard-block condition.

Technical Asset Listing Framework formalises the timelock dimension through a standard Level 0 to 5 security configuration model, where:

Level 5 is onchain DAO governance with a timelock.
Level 4 is a multisig with a timelock of at least 48 hours.
Level 3 is a multisig with a short timelock below 48 hours.
Level 2 is a multisig with credible majority configuration but without a timelock.
Any entity at Level 0 (a single key or EOA with no delay) or Level 1 (a multisig below honest majority) is defined as a weak security configuration.

1.7 Signing Authority Decentralisation and Custody

Signing authority decentralisation determines whether the asset’s authority surface can be compromised through a single point of failure (a single key, a small concentrated signer set, a single custodian). Disclosure of the signer surface is required even where confidentiality is reasonable, in which case disclosure is made under NDA to the risk provider.

The framework’s standing preference is for transparent on-chain multisig arrangements over MPC-based custody on the authorities that materially affect Aave’s exposure. Standard multisig contracts publish the signer set, the quorum threshold, and every authority action on chain, which is exactly the verifiability the protocol depends on for assessing whether a malicious or accidental change can occur and for responding to one in flight. MPC produces an on-chain footprint identical to a single externally-owned account; the underlying signer set, key-share distribution, and quorum threshold are opaque to anyone other than the operator, which removes the on-chain visibility multisig provides. In an environment where unauthorised authority changes and key-share compromises are a recurring exploit category, the transparency property of standard multisig is the preferred baseline. MPC remains acceptable only where additional private disclosures and operational controls recover the visibility the on-chain layer does not provide, the trade-off and the mitigations relied on here are set out in the LlamaRisk MPC Explainer.

Requirements on every authority that can affect the asset on Aave (admin, mint, burn, oracle, bridge, slashing, upgrade):

Signer-set composition, quorum threshold, and per-signer identity disclosed to the risk provider.
Signer diversification across organisations and across hardware, sufficient to prevent collusion or single-supply-chain compromise.
Institutional-grade private-key custody for every authority.
Pause and blacklist authority, where present, identified and held under controls no weaker than the corresponding mint or burn authority.
Where confidentiality is reasonable, disclosure is made under NDA to the risk provider rather than published; undisclosed signer composition, quorum, or thresholds (even under NDA) is a hard block.

Additional requirements where MPC is used in place of standard multisig:

Private disclosure of the MPC signing composition under NDA, including the number of key shards, the quorum threshold, and the identity of each shard holder. The on-chain identity of a single MPC address does not satisfy the disclosure requirement.
Disclosure of shard-level custody (where each shard is held, by whom, under what custodial framework). Operational concentration across shards (multiple shards held by a single entity or under shared infrastructure) is disclosed and treated as a constraint on exposure equivalent to a sub-honest-majority multisig.
Third-party audit or certification of the MPC implementation and the provider’s operational set-up, with re-attestation on subsequent material changes.
Disclosure of whether the MPC cryptographic library is open-source and independently auditable.
Where the MPC provider supports auditable mechanisms (commitments and proofs posted to a public bulletin board, on-chain audit logs of authority actions, or equivalent), those are in use. MPC configurations without any auditability mechanism are problematic and put a full trust assumption on both the stack and the integrator.

Single externally owned account authorities, multisigs below honest-majority thresholds, undisclosed signer surfaces, or MPC configurations lacking the additional disclosures above are hard-block conditions.

1.8 Legal Disclosures

For asset classes where value depends on legal arrangements rather than on-chain mechanics (custodied stablecoins, RWAs, redemption-bearing instruments), legal disclosures are part of the asset’s risk surface and not optional supporting information. Disclosures are scoped to what the risk provider needs to assess legal recourse and counterparty exposure.

Requirements:

Issuer jurisdiction and entity structure disclosed.
Redemption rights disclosed, including any conditionality, queue mechanics, or jurisdiction-specific limitations.
Asset-backing terms disclosed, including the legal treatment of property interests in the underlying.
Custodian disclosures provided where the asset depends on a custodian, including the custodian’s jurisdiction and the legal nature of the arrangement.
Regulatory status disclosed, including any active or pending classifications under securities, money-transmission, or equivalent regimes that could affect the asset’s behaviour.

Opaque legal structure, undisclosed redemption mechanics, or undisclosed custodian arrangements where applicable materially constrain onboarding and exposure until clarified.

1.9 Holder Claims Seniority and Loss-Bearing Hierarchy

A listed asset typically exists in multiple representations across chains (canonical issuance, bridged or wrapped representations on L2s, vault or staking wrappers, custodied institutional claims), and a loss event on one representation does not automatically distribute pro rata across all holders. Ambiguity over which class of holders bears the loss blocks orderly recovery: the asset cannot reprice cleanly until the loss-bearing hierarchy is known, redemption queues cannot honour exits at par when the share of impairment per holder class is undefined, and Aave’s own safety-net layer cannot size slashing against a target that is not yet allocated. The framework therefore treats the claims seniority structure as a standing disclosure requirement, agreed in advance rather than negotiated under live incident pressure.

Requirements:

Each class of holder with rights against the underlying is identified (canonical-chain holders, per-L2 bridged holders, wrapper or vault holders, custodied institutional claims, and any other class with a distinct legal posture).
The seniority ordering across those classes is disclosed: who is paid first against the underlying, who absorbs first loss, and under what conditions seniority shifts.
Cross-chain symmetry is stated explicitly: whether bridged representations carry equal claim to canonical issuance, or whether a bridge incident is borne by holders on the affected chain rather than socialised across all holders.
Coordination authority is identified: who decides loss allocation under an incident, on what timescale, and with what governance preconditions.
Where the seniority structure depends on legal arrangements outside Aave’s observation (custody agreements, jurisdictional bankruptcy treatment, issuer DAO votes), those dependencies are disclosed under NDA where appropriate.

Undisclosed or ambiguous claims seniority on assets with multiple holder classes is a hard-block condition, because it cannot be priced and it materially impairs the speed and credibility of any incident response.

1.10 Asset Backing Structure and Visibility

For asset classes whose value is determined by backing (stablecoins, LSTs, LRTs, restaked assets, RWAs), the framework requires not only that backing exists but that it remains continuously observable. Periodic attestation alone is insufficient where the asset’s risk surface shifts faster than the attestation cadence.

Requirements:

Proof-of-Reserves or equivalent attestation in place for the full backing of the asset by a reputable third party approved by Aave stakeholders.
Reserve composition disclosed at the level of individual collateral components, not aggregate value.
Onchain visibility of backing where structurally possible; off-chain backing covered by attestation with a publication cadence sized to the asset’s risk dynamics rather than episodic disclosure.
Material changes to attestation cadence or attestor identity disclosed in advance.
Backing-asset price and redemption-buffer state observable in real time where the asset depends on either for its peg or its exchange rate.

Opaque backing, attestation cadence misaligned with the asset’s risk dynamics, or unverified reserve composition materially constrains onboarding and exposure.

1.11 Issuer Operational Stack Disclosure

On-chain observability does not describe the issuer’s full operational stack, and the gaps in that observability are where the highest-impact risk vectors typically sit. The framework requires private disclosure of the operational stack to the risk provider, under NDA where appropriate, so that operational security is not weakened by publication.

Requirements:

Infrastructure setup disclosed, including hosting, key custody arrangements, and authority-to-action paths.
Operational security practices disclosed, including incident-response procedures, change-management procedures, and access-revocation procedures.
Third-party dependency list disclosed, including any infrastructure shared with bridge stacks, oracle providers, or other listed assets.
Monitoring practices disclosed, including the issuer’s own coverage of authority queues, infrastructure events, and asset-state anomalies.
New infrastructure (a new bridge route, a new chain deployment, a smart contract upgrade) walked through with the risk provider before it goes live.

Refusal to disclose the operational stack, even under NDA, materially constrains onboarding and exposure.

1.12 Pre-Agreed Incident Communication Baseline

A predictable communication path during an incident is part of risk mitigation rather than optional courtesy. The framework requires the baseline to be agreed in advance rather than negotiated under live incident pressure.

Operational requirements:

Issuer contact point and escalation path identified and tested.
Pre-agreed communication baseline for confirmed exploits affecting the asset on Aave.
24/7 reachability across the issuer’s incident-response team during any window in which the asset carries material Aave exposure.
Commitment to pre-notify Aave teams of material changes before they go live rather than after the fact.

Absence of an agreed communication baseline, or refusal to commit to pre-notification, materially constrains onboarding and exposure.

1.13 Hard-Block Conditions and Veto Authority

An explicit veto authority is held by each service provider on the hard-block conditions below. This is necessary because historically onboardings had proceeded without resolution of all outstanding deficiencies indicated by different SPs in the form of recommendations. The veto applies at listing and at any quarterly refresh that surfaces one of these conditions.

Hard-block conditions:

Missing or materially weak bug bounty programme.
Opaque or unverified governance structure.
No timelock on upgrade paths that materially affect Aave’s exposure.
Undisclosed signer composition or thresholds, even under NDA.
Audits without re-attestation on subsequent material upgrades.
Unresolved audit findings or past exploits without documented remediation.
Bridge configuration falling short on any Layer 2 mandatory requirement on a route carrying Aave exposure.
Refusal to disclose the operational stack, the legal structure, or the backing composition where applicable.

A hard block stops onboarding entirely until the condition is cleared; for an already-listed asset, a hard block triggers an immediate exposure-tier review and may trigger deprecation if not remediated within the framework’s standing timelines. Similarly, whenever an evaluation made in accordance with the technical listing framework outlines any blockers, the veto authority automatically blocks onboarding even if this framework does not indicate any hard blockers.

1.14 Continuous Due Diligence Cadence

Structural due diligence, just like the asset parametrization efforts and market evaluations, is a continuous process, with a quarterly refresh as the minimum cadence. Each refresh publishes a delta report against the prior baseline, so that the picture stays current and the change history remains auditable.

Operational requirements:

A quarterly refresh per asset, scheduled relative to the asset’s onboarding date, covering every chain the asset is deployed on.
A delta report published against the prior baseline, expanding and iterating on the original findings.
Each refresh re-evaluates every requirement in Sections 1.1 through 1.11 against the asset’s current configuration.
Bridge configuration is re-evaluated at every refresh under the bridging cadence.
Monitoring coverage is re-evaluated at every refresh against the monitoring stack.

Failure of the issuer to engage with the quarterly refresh, or refusal to provide updated disclosures, materially constrains the asset’s exposure until the refresh is completed. If the updates materially change the asset’s risk profile, measures would include offboarding of the asset.

1.15 Material-Change Taxonomy

In addition to the quarterly cadence, material changes by the issuer trigger out-of-cycle re-evaluation. Asset issuers are required to disclose material changes to bridge configuration in advance so that the change can be reviewed before deployment and does not trip the automated monitoring layer’s anomaly detection. Bridge infrastructure providers are required to disclose material changes to the bridging protocol as to manage resources needed for re-evaluation across numerous issuers.

Authority and access changes:

New mint or burn authorities introduced on any chain.
MPC, multisig, or custody arrangement changes.
Multisig signer composition or timelock parameter changes.
New pause, blacklist, or upgrade authority assignments.

Reserve and backing changes:

New collateral type, staking destination, restaking layer, or custody arrangement for the underlying.
Material changes to attestation cadence or attestor identity.
Material changes to redemption mechanics or queue parameters.

Contract and deployment changes:

Contract upgrades on any deployed chain.
Expansion to new chains.
New chain-specific access-control or parameter divergence.

Bridge configuration changes:

Bridge stack change or addition of a new bridge route.
Verifier-set or attestor-set changes, including additions and removals.
Rate-limit changes on any route.
Pause authority composition changes.

Oracle changes:

Composition changes: adapter swaps, primary feed swaps, fallback source addition or removal, and any change to the oracle path that is either consumed by Aave or used in the internal systems (e.g. to calculate balances, serve the redemptions etc.).
Quality changes: shifts in the Chainlink risk tier on the asset’s feed, changes to heartbeat or deviation threshold, single-venue concentration emerging on the inputs to the feed, sustained volume decay on the feed’s source venues, and any other change that materially affects the feed’s manipulability or reliability.

Failure to disclose a material change in advance is itself a remediation trigger and may constrain the asset’s exposure tier.

1.16 Remediation Timelines and Residual Risk Treatment

Recommendations raised at onboarding and at every quarterly refresh carry a one-month implementation expectation. The one-month timeline exists to ensure that compliance with the framework’s findings is met within a defined, enforceable window rather than being left open-ended as a longer-term goal, since binding each recommendation to an explicit timeline closes the loop and ensures the framework’s findings translate into operational change rather than into a growing recommendation backlog.

Operational requirements:

Each recommendation is acknowledged by the issuer and assigned a one-month implementation target.
Recommendations not implemented within one month convert into hard constraints on the asset’s exposure tier (lower caps, lower LTV, restricted cross-chain expansion).
Recommendations classified as hard-block conditions are not subject to the one-month grace; they block onboarding outright or, for listed assets, trigger immediate exposure-tier review.
Where remediation is structurally infeasible, the residual is documented in the asset’s profile and reflected in the standing exposure ceiling.

Recommendation backlogs that persist across multiple quarterly refreshes are themselves a deprecation trigger.

1.17 Asset Deprecation Triggers

An asset becomes a deprecation candidate when its continued listing no longer fits the active risk surface. The triggers are grouped by the underlying source of the impairment, because the source determines which deprecation mechanics apply and how aggressive the wind-down needs to be.

Trigger conditions:

Secondary-market liquidity decays to where healthy liquidation depth can no longer be sustained for the asset’s outstanding exposure.
Oracle stability degrades materially, with the feed becoming manipulable or thin (single-venue concentration, wide spreads, low daily volume); Chainlink price feed risk tiering is a binding input, where High or Very High risk evaluation is critical.
Economic footprint falls below the cost of standing oversight.
Backing structure degrades, including issuer-side or custody-side incident, exploit, or insolvency materially affecting the asset.
Hard-block conditions surface on a listed asset and are not remediated within the framework’s standing timelines.

Deprecation under any of these triggers is operationalised under the mechanics and oracle treatment defined below.

1.18 Oracle and Price-Feed Treatment

Oracle stability is itself a function of adoption. As trading depth declines on an asset, market inputs to the feed thin out (fewer venues, wider spreads, lower daily volume), and the market becomes progressively less stable and more manipulable. Chainlink’s continuous risk-tiering process on price feeds flags these failure modes, and the framework treats those flags as binding inputs on every feed Aave consumes.

The framework’s oracle treatment is not limited to the feed Aave consumes on chain. A listed asset typically depends on additional oracle paths for its own mechanics: minting and burning gates, redemption pricing, internal balance and exchange-rate accounting, proof-of-reserves attestation etc. Failures in those internal oracles propagate to Aave through the asset’s behaviour even where Aave’s own feed is functioning correctly. A manipulable mint gate translates into unauthorised minting that Aave then accumulates as collateral; a stale or coerced redemption-pricing oracle into mispriced exits; a manipulable internal exchange-rate oracle into an inflated balance that Aave reads through a correctly-functioning price feed; a delayed proof-of-reserves into backing impairment Aave cannot detect from its own feed alone. The framework therefore treats the asset’s full oracle surface as a standing concern, with treatment differentiated by the role each oracle plays.

Requirements on the Aave-consumed price feed:

In the cases where a market rate price feed is used, a Chainlink price feed is required with the Chainlink risk tier on the feed reviewed continuously.
High or Very High risk-tier flags on a feed in use on Aave trigger deprecation review as a standing rule.
A feed quoting a market price on an asset with no significant secondary market on chain and on centralised venues is treated as an unacceptable risk surface and triggers direct and aggressive deprecation.
For stablecoins not used as collateral, the deprecated feed is pinned at the nominal peg, which removes oracle manipulation risk on assets whose nominal value is the only sensible reference.
For non-stable tokens with decayed secondary markets, the deprecated feed is pinned to a conservative constant (last-good or a defined haircut) and the asset’s collateral position is unwound through a controlled LT step.

Requirements on issuer-internal oracles the asset depends on:

Each internal oracle path that gates supply integrity, redemption pricing, balance accounting, or backing attestation is identified at onboarding and documented in the asset’s profile.
Mint and burn gates cannot be unilaterally manipulated within a single transaction; in-block donations, flash-loan-induced deviations, and accounting-shortcut surfaces on the gating oracle are explicit disqualifiers.
Redemption-pricing oracles maintain a sustained accuracy window consistent with the asset’s redemption queue dynamics, so that exits are not priced against a stale or coerced input.
Internal exchange-rate or balance-accounting oracles for LSTs, LRTs, vault tokens, and similar instruments are monotonically non-decreasing under normal operation (with slashing or negative-rebase pass-through as the only acceptable exception) and resistant to single-transaction manipulation.
Proof-of-reserves and equivalent backing-attestation oracles publish at a cadence aligned to the asset’s risk dynamics rather than at an episodic interval disconnected from how fast the backing surface can change.

Feeds that remain in use against a Chainlink High or Very High flag, and internal oracles that fail any of the above requirements, are treated as standing hard constraints on the asset’s exposure tier before the asset itself is fully deprecated.

1.19 Market (Deployment) Deprecation Criterion

When a group of assets within a market deployment becomes unstable, or when a deployment’s total revenue falls below the operational cost of supporting it (due diligence, audit, monitoring, parameter maintenance, governance overhead, infrastructure subsidy), the deployment itself becomes a candidate for sunset rather than just its individual reserves.

Trigger conditions:

Total quarterly deployment revenue, evaluated using both borrow-side attribution and collateral-attributed revenue, falls below the standing operational support cost for the deployment.
A group of reserves on the deployment becomes structurally unstable (liquidity decay, oracle decay, bridging risk concentration).
Per-deployment TVL and revenue thresholds are scaled to the deployment’s total supplied USD value, calibrated per deployment rather than copied across, because a tail asset on a small deployment may be load-bearing for that deployment’s economics.

A deployment that crosses these triggers is operationalised under the playbook below.

1.20 Market Deprecation Playbook

The mechanics are structurally similar to asset deprecation, applied across the whole deployment in coordinated steps.

Operational sequencing:

Supply and borrow caps (add/draw caps on Aave V4 architecture) are set to 1 across all reserves on the deployment.
The reserves are frozen.
Reserve factor is tuned upward to drive organic unwinding through repayment, withdrawal, and liquidation, with reserves carrying material leveraged exposure (typically WETH on LST-heavy deployments) excluded from the reserve-factor increase to avoid triggering forced liquidations of leveraged positions.
IRM adjustments follow once meaningful exposure has cleared, raising borrow rates to incentivise voluntary repayment for residual positions. On Aave V4 architecture, an additional risk premium lever is used for collateral assets, to drive loan repayments further, either in conjunction with the IRM adjustments or as a standalone measure.
Cross-chain bridge routes serving the deprecated deployment are closed under decayed-lane treatment as the deployment empties, per coordination with the asset issuers.

Subsequent whole-deployment deprecations under the framework follow this sequencing.

2. Bridging Risk

Bridge providers carry the first share of responsibility for the safety of a bridged asset. The bridge configuration travels with the asset and is reflected directly in the asset’s risk classification, irrespective of which bridge stack is in use. The requirements below are vendor-agnostic and apply uniformly across stacks, with no allowance for opt-in advanced settings, single-party verifiers, or vendor-managed defaults that fall below the baseline. An asset whose bridge configuration falls short on any mandatory item receives a tightened exposure tier (lower LTV, lower caps, restricted cross-chain expansion) until remediation lands.

2.1 Bridge Topology Disclosure

Every bridged asset is documented at the route level before listing. Topology disclosure is the precondition for every subsequent requirement in this layer, because requirements such as verifier independence, library pinning, and rate limiting cannot be assessed without a precise specification of the route.

Requirements:

Origin chain and canonical supply identified.
Target-chain representation documented (mint-and-burn, lock-and-mint, native-bridge representation).
Bridge or messaging system identified by name and version.
Verifier, attestor, oracle, or message-verifier configuration documented for every route carrying Aave exposure.
Bridge admin and upgrade controls identified for the route on both chains.
Weak controls on the origin chain are assessed as part of the target-chain listing, because origin-chain weakness can undermine the full cross-chain supply model regardless of bridge implementation.

Incomplete topology disclosure on any route carrying Aave exposure is a hard block.

2.2 Verifier Set Threshold Requirement

The minimum verifier-set threshold is the most consequential security property of a bridge stack and the property most often weakened by opt-in default configurations. The framework sets a binding floor below which no asset can be onboarded.

For threshold purposes a verifier is counted as an independent operator/trust domain: a verifier network operated by a single organisation counts as one unit regardless of internal node count, and verification layers run by genuinely distinct operators count separately.

Requirements:

A minimum of three independent verifiers (validators, attestors, nodes, or message verifiers) is required on every route carrying Aave exposure.
One-of-N and two-of-N configurations are not acceptable as a default baseline regardless of vendor.
Meaningful verifier distribution across organisations, geography, and infrastructure.
Supply-chain isolation, including RPC providers, hardware, and key infrastructure.
Bare-metal or comparably isolated infrastructure.
The verifier threshold is reflected in the asset’s risk classification; deviations require explicit governance justification and reduced exposure.

A route with a verifier set below the threshold is treated as a hard block on cross-chain exposure expansion and triggers non-conformance treatment for existing exposure on the route. In addition, issuers will be encouraged to have more verifiers beyond the minimum threshold.

2.3 Verifier Independence Requirements

Verifier count alone is insufficient. Independence between verifiers determines whether a nominal threshold reflects real defence-in-depth or whether it collapses to a single supply-chain point of failure under stress.

Requirements:

Verifiers are independent across organisations.
Verifiers are independent across geographic jurisdiction, sufficient to avoid concentration risk under a single regulatory action.
Verifiers are independent across underlying infrastructure (RPC providers, hardware, cloud providers).
Bare-metal or comparably isolated infrastructure is preferred, with minimal interdependence across the supply chain.
Identifiable verifier overlap (shared RPCs, shared cloud accounts, shared key infrastructure, economic co-dependence) is documented as a risk-tier input and constrains exposure.

Nominal verifier-set decentralisation that collapses under any of the above independence dimensions is treated as a single point of failure for risk-tier purposes.

2.4 Mutable Send and Receive Libraries

Even where the verifier set is robust at a point in time, the authority that can change the verifier set or the message-handling library remains a critical surface. Pinning closes the path where vendor-side compromise silently rewires the verifier configuration without the asset issuer’s explicit re-attestation.

Requirements:

Receive libraries (or vendor equivalent) are pinned, so that compromise of a vendor-side authority cannot silently change the verifier set or message-handling logic.
Library upgrades require the issuer’s explicit re-attestation rather than executing under a vendor-controlled upgrade path.
Verifier-set changes are gated by bridge-authority timelocks on every chain.
The pinned configuration is documented as part of the route topology disclosure.

Unpinned receive libraries on routes carrying Aave exposure are treated as a hard constraint on the route’s exposure tier until pinning is in place.

2.5 Bridge Authority and Ownership Timelocks

Bridge authority is the standing power to change the verifier set, the rate limits, the libraries, or the mint and burn functions. Timelocks on that authority are required so that any malicious or accidental change can be observed and acted on before it takes effect.

Requirements:

Timelocks gate bridge ownership transfers.
Timelocks gate verifier-set or attestor-set changes.
Timelocks gate library upgrades and message-handling logic changes.
Timelocks gate per-route rate-limit changes.
Timelocks gate mint and burn authority grants on every route.
Timelock delay is sufficient for Aave to take mitigating action before the change executes; instantaneous or sub-hour delays are not acceptable.

Absence of timelocks on any of the above bridge authorities is a hard constraint on cross-chain exposure until remediated.

2.6 Separate Pause Pathways

Pause authority is the standing incident-response control on a bridge. Concentration of pause authority in a single party leaves Aave without an independent path to stop an in-flight exploit, and is not acceptable under the framework.

Requirements:

Issuer-side pause authority exists and is independent of the vendor. This can include methods such as setting native rate limits to 0.
A vendor-side or verification operator-enforced ability to halt verification on the route exists and is exercisable by the vendor or operator’s incident-response team.
An Aave-controllable pause pathway is implemented via the monitoring layer where the bridge architecture supports it.
Each pause path is documented and tested under standing incident-response procedures.

Reliance on a single pause path is not acceptable because it concentrates incident-response authority in one party. Single-path pause configurations would constrain the asset’s cross-chain exposure.

2.7 Custody Requirements at the Bridge Layer

Both the bridge stack and the asset issuer hold rights to functions that affect the collateral on Aave (mint, burn, pause, rate-limit change). Custody on those rights is required at institutional grade on both sides, because the weaker of the two custody arrangements determines the overall surface.

Requirements:

Institutional-grade private-key custody at the bridge stack level for every authority that can affect Aave-listed bridged assets.
Institutional-grade private-key custody at the asset issuer level for the corresponding authorities on the issuer side.
Custody arrangement disclosed to the risk provider as part of operational stack disclosure.
Custody changes disclosed in advance as material changes.

Weak custody on either side, or undisclosed arrangements, materially constrains cross-chain exposure.

2.8 Per-Route Rate Limiting Requirement

Rate limits bound the worst-case single-transaction drain that can result from a bridge exploit or from related exploit types (unauthorised minting, message replay). Under the framework, rate limits are required as a standing property of the bridge configuration rather than as a contingency to be activated under stress.

Requirements:

Rate-limiting is present and enforced at the bridge stack or app level.
Where native rate-limiting is unavailable, the issuer must layer it externally; external layering is accepted as a substitute but must have equivalent enforceability.
Per-route rate limits are configured on every route carrying Aave exposure.
Inbound and outbound limits are sized separately by direction.
Rate-limit configurations are documented under route topology disclosure and reviewed at every cadence point.

Routes without effective per-route rate limits carrying material Aave exposure are treated as a hard constraint on the asset’s exposure tier. It is highly recommended to have native rate limits and to be publicly documented in the bridging infrastructure provider documentations. This serves as an additional cross reference across the issuer and vendor, to prevent solely trusting a single party.

2.9 Rate Limit Sizing Methodology

Rate-limit values, not just their existence, determine whether the limit binds a forged or coerced package. Sizing methodology is standardised under the framework so that limits are evaluated consistently across assets and across bridge stacks.

Requirements:

Per-route limits are sized to the highest observed sustained flow on the route rather than to peak burst.
Headroom over highest sustained flow is explicit and bounded; unbounded headroom is treated as the absence of a meaningful limit.
Inbound and outbound sustained flow are evaluated separately, because cross-chain flow profiles are typically asymmetric.
Decayed-lane treatment applies once the sustained flow on a route falls below the threshold for active maintenance.

The sustained-flow basis keeps legitimate traffic comfortable while ensuring that a forged or coerced package cannot exceed what real cross-chain activity has ever needed.

2.10 24/7 Redphone and Incident Response Requirements

A bridge’s safety properties hold in steady state; incident response determines whether those properties hold in flight. The framework requires standing 24/7 reachability across every party with authority to mitigate an in-flight incident, including but not limited to all required attestors that are responsible to validate the cross chain transfers.

Operational requirements:

24/7 redphone availability across vendors, attestors, and issuer.
Written exploit procedure documented and rehearsed.
Pre-agreed authority for the on-call team to pause contracts and lower rate limits without further escalation.
Emergency reductions in limits and defensive pauses may bypass timelock requirements, while the timelock governs changes that loosen or alter verification.
Pre-agreed escalation path between the vendor, the attestors, the issuer, and Aave’s service providers.
The entity operating the verification and messaging layer takes explicit responsibility for security and integrity monitoring of that layer rather than offloading it to issuers and consuming protocols; this operates as defense in depth alongside the issuer’s application-level monitoring, which covers the correctness of cross-chain activity.

Gaps in 24/7 reachability across any party in the chain materially constrain the asset’s cross-chain exposure tier.

2.11 Dedicated Security and Monitoring Team Requirements

Monitoring is required on both the vendor and issuer side, scoped to what each can observe: infrastructure and verification-layer integrity sits with the entity operating that layer, while application-level monitoring and response authority sit with the asset issuer. Where a stack’s verification layer can itself detect anomalous cross-chain activity, that detection and response capability sits with the operating entity; where it cannot, the determination requires application context held by the issuer. Offloading all monitoring onto consuming protocols is not acceptable, and no layer carrying Aave exposure should be left monitored by no party.

Requirements:

A dedicated security and monitoring team at the infrastructure and verification-layer level, maintained by the entity operating that layer, which shares documentation of its monitoring coverage for that layer with Aave.
Dedicated security and monitoring team at the asset issuer level for the bridge-side surface, with asset issuers to share detailed documentation to Aave.
Detailed system checks across the stack, automated logic for anomaly detection, and written procedures for an in-flight exploit are maintained as standing artefacts.
Neither the operator’s layer monitoring nor the issuer’s application monitoring is offloaded onto the other party or onto consuming protocols.

Absence of dedicated monitoring resources on either side materially constrains the asset’s cross-chain exposure tier.

2.12 Bridge Configuration Lifecycle: Initial Limits

Bridge configuration is not set once at integration; the lifecycle below governs how the configuration is established, reviewed, and adjusted across the asset’s life on Aave. The first stage is the issuer’s proposal at integration.

Requirements:

Per-route initial limits are proposed by the issuer at integration, based on the issuer’s view of expected cross-chain flow per route.
Initial limits are documented per route and per direction.
Initial limits reference comparable issuer routes already in operation where available.

The initial proposal becomes the input to the review stage; routes proposed without an initial-limit specification are not eligible for integration.

2.13 Bridge Configuration Lifecycle: Review

LlamaRisk reviews the proposed configuration as part of the asset’s risk classification and recommends adjustments where the proposed values diverge from observed cross-chain flow or from the requirements.

Operational requirements:

Review is completed before the route goes live on a chain carrying Aave exposure.
Recommended adjustments are documented and the issuer’s response captured before integration.
Material divergence between issuer proposal and reviewer recommendation is flagged in the asset’s risk classification and reflected in the initial exposure tier.

Routes deployed without completed review are treated as non-conforming until reviewed.

2.14 Bridge Configuration Lifecycle: Cadence and Out-of-Cycle Triggers

Bridge configuration is re-evaluated at every quarterly due diligence refresh against the latest flow data, alongside the rest of the asset’s evaluation. In addition, material monitoring flow events trigger out-of-cycle re-evaluation, because cross-chain flow profiles can shift faster than the quarterly cadence.

Out-of-cycle triggers:

A new chain deployment by the issuer introducing a new route.
A new liquidity venue accepting the bridged token on any deployed chain.
A sustained shift in transit volume on an existing route, in either direction.
A material change affecting bridge authority, verifier set, or rate limits.

Decayed-lane treatment:

Lanes that have decayed toward zero usage are candidates for closure rather than continued elevated limits, since every open lane is an incremental attack surface independent of whether it carries traffic.
Decayed lanes are closed under the same authority and timelock pathway that gates rate-limit changes.

2.15 Bridge Stack Evaluation Pillar: Additional Infrastructure Risk

Each cross-chain stack used by an asset onboarded on Aave increases the protocol’s total risk exposure. Additional time and resources are necessary to track and monitor every additional bridge infrastructure.

Evaluation requirements:

Operational security of the vendor and its attestors assessed.
Code quality on the on-chain and off-chain components, and the corresponding audit reports, reviewed.
Novel architectural attack surfaces unique to the design identified and assessed.
Exploit history evaluated, including recurrence and the quality of remediation.
Time and resources required for Aave to maintain monitoring on the stack documented and reflected in the stack’s classification.

For example, the protocol has already vetted and approved CCIP for GHO and sGHO and additionally relies on Data Feeds that are built on the same underlying infrastructure. A more detailed review across all cross-chain infrastructures that Aave is currently exposed to will be conducted.

Stacks whose additional infrastructure cost is disproportionate to the asset exposure they secure are not preferred and materially constrain the asset’s exposure tier.

2.16 Bridge Stack Evaluation Pillar: Uniformity vs. Configuration Flexibility

A uniform default security architecture across all chain expansions allows Aave to more readily quantify and measure risk and reduce the level of unknowns. Bespoke per-chain configurations without an enforced minimum complicate the risk management process, demand higher monitoring effort, and introduce unknown risk vectors.

Evaluation requirements:

Uniform default security architecture across all chain expansions is preferred and reflected positively in the evaluation.
Bespoke per-chain configurations are explicitly justified and disclosed under route topology.
Deviation from the stack’s uniform default which materially increases monitoring burden is reflected negatively in the evaluation.
Configuration uniformity is reviewed at every cadence point.

Configurability does not necessarily undermine security properties, but it does impose monitoring costs; a stack that permits many per-route configurations requires more standing effort for the DAO to track, and uniform-default stacks are credited for reducing that effort.

3. Monitoring and Automated Risk Oracle Systems

Layers 1 and 2 set the standing rules applied to assets and bridges. They do not, on their own, manage the risks that materialise between assessments. Bridge drains, peg breaks, redemption-buffer depletions, and abrupt market-depth collapses unfold on minute-to-hour timescales, while human-in-the-loop response on a manual cadence lags those timescales by hours at times. This layer codifies the standing risk-management infrastructure the framework binds Aave to operate against those failure modes: enforced automated monitoring of Aave-external layers, continuous risk oracles and automated freeze guardians that act without waiting for human review, Risk Stewards as the human-paced complement that handles recovery and judgment-bound calibration, and Umbrella as the residual safety net that absorbs loss the layers above cannot prevent. These are operational risk-management mechanisms rather than discretionary tools, where the framework treats them as binding standing infrastructure on the same footing as the requirements in Layers 1 and 2.

3.1 Enforced Continuous Monitoring of Aave-external Layers

Automated monitoring is to cover the full stack. The focus is Aave-external because that is where the highest-impact events typically begin before they translate into on-chain effects on Aave itself, and the lead time between an external event and its on-chain consequence is what makes a defensive response feasible. A complementary layer watches for events that are likely to precede an incident, so that Aave is first informed when anomalous Aave-external events occur.

Coverage requirements span four signal areas:

Authority-queue activity on the multisigs and timelocks that control the asset’s admin, oracle, bridge, and slashing authorities, where queues are watched and not just executions, so that a response can begin while a malicious or accidental change is still pending.
Governance activity on adjacent venues whose decisions can affect the asset before they reach the chain, including Snapshot proposals, on-chain governance actions, and RFC and ARFC threads.
Infrastructure activity on the oracle adapters and bridge stacks the asset depends on, including validator-set changes, library upgrades, and pause events.
Direct asset-state activity on chain, including bridge balance reconciliation between locked-side reserves and minted-side supply, backing-asset and redemption-buffer state where applicable, and minting and burning volume anomalies relative to historical baselines.

A per-asset monitoring stack is to be published alongside the asset’s due diligence report, enumerating what is under coverage and what is explicitly out of scope, and is re-evaluated at every quarterly refresh. Detected signals route either to the automated risk oracle layer for hard adverse signals, or to Risk Steward escalation for soft signals or signals requiring judgment, under the per-asset playbook agreed at onboarding.

3.2 Continuous Risk Oracles and Automated Freeze Guardians

Two automated mechanisms are to address the speed gap between an adverse event beginning and a human response: the Automated Freeze Guardian and the Supply and Borrow Cap Oracle. These mechanisms are to conform to the following:

Built on Chainlink CRE as the off-chain compute and execution layer.
Owned by the Aave DAO, so that signal sources, thresholds, and on-chain execution authority are auditable and governed through Aave rather than held under any vendor relationship.
Both are tailored per asset type to the specific risk profile of the asset.
Both are defensive by design: each can tighten exposure on its own, while any loosening (cap raise, threshold relaxation, freeze release) requires human review through governance or Risk Steward action.
The oracle layer is one-directional: a transient signal can only lower or freeze exposure, never raise caps or release freezes.
Both are implemented through the Risk Agents architecture, consistent with the rest of the Aave peripheral stack.

Together, the two mechanisms limit the blast radius that would otherwise be possible through exploits involving unauthorised minting, peg breaks, or counterfeit collateral, while keeping the protocol’s recovery path under human judgment.

The Automated Freeze Guardian is the reactive defensive layer. It fires when a hard adverse signal is detected on the asset’s stack, freezing the reserve and stopping further accumulation of exposure. The trigger areas are asset-type-specific and are defined as part of each asset’s continuous due diligence: backing-asset price and reserve-composition signals for fiat-backed stablecoins; redemption-buffer replenishment and exchange-rate manipulation signals for LSTs, LRTs, and restaked assets; locked-versus-minted supply mismatches and unannounced verifier or library changes for bridged assets; and cross-type minting and burning volume anomalies layered on top of the type-specific triggers. The standing design baseline is the Automated Freeze Guardian proposal, with per-asset thresholds calibrated against the asset’s normal operating ranges. Generalising the Freeze Guardian across the assets deployed on Aave is the core defensive primitive of this layer, because it is the mechanism that bounds the protocol’s exposure during the minutes-to-hours window in which an exploit involving unauthorised minting or counterfeit collateral can otherwise propagate uncontested.

The Supply and Borrow Cap Oracle is the proactive continuous monitoring complement. Caps are pulled down automatically when per-asset triggers fire, before any acute event has occurred, so that Aave does not accumulate exposure into an asset whose secondary market is thinning out, whose holders are exiting rapidly, or whose cross-chain supply has concentrated unsustainably. Cap reduction is proportional to the trigger magnitude; cap expansions remain manual through governance and Risk Steward review, in line with the defensive-only invariant. The mechanism extends the conservative cap-sizing approach, ensuring that Aave is not exposed to overly large collateral capacity by default and cannot be used as an exit venue for counterfeit or stolen collateral.

The two mechanisms are to work in conjunction. The Freeze Guardian limits blast radius when an exploit involving unauthorised minting or counterfeit collateral begins; the Cap Oracle keeps Aave from accumulating exposure into an asset whose risk surface is degrading before any acute event has occurred.

3.3 Risk Stewards as Human-in-the-loop Complement

The Risk Stewards is the manually controlled layer that complements the automated defensive layer of the Risk Agents. The automation handles defensive tightening on minute-to-hour timescales; the Risk Stewards handle the recovery side, the parameter tuning that requires judgment, and the cases where an automated defensive action needs to be unwound after the signal clears. The two layers are asymmetric by design: automation is biased toward tightening, Risk Stewards toward calibration and recovery.

When caps are sized closer to current utilisation, legitimate organic growth on a healthy asset more frequently bumps into the Risk Steward cooldown. The Risk Steward RiskConfig enforces per-parameter constraints, where minDelay is the minimum time between consecutive changes to the same parameter on the same reserve and maxPercentChange is the largest accepted single-step change.

Under the framework, minDelay is set to 36 hours on the cap and IRM parameters where the defensive cap posture meaningfully constrains response speed: supplyCap, borrowCap, baseVariableBorrowRate, variableRateSlope1, variableRateSlope2, and optimalUsageRatio. The higher-impact collateral and E-Mode parameters (base LTV, LT, LB and their E-Mode equivalents, both price caps) remain at the 72-hour minimum because changes there have a larger downstream effect on existing positions. The Pendle discount rate stays at its existing 48-hour minimum. maxPercentChange bounds are unchanged across every parameter. The intent is symmetric with the Cap Oracle defensive automation: a faster downward path on caps through the oracle, and a faster upward path on caps and rates through the Risk Stewards, so that the defensive cap posture does not turn into a soft cap on legitimate organic growth.

3.4 Umbrella Coverage Role

Umbrella sits below the automated and human layers as the residual safety net: the layer that absorbs loss when the layers above cannot prevent it. Its design principles and slashing logic are set out in the Umbrella coverage principles and slashing logic post and form the baseline this framework extends.

Umbrella’s slashing logic was deliberately kept primitive at design: slashing fires when bad debt is reflected on the pool’s accounting, and the standing unstaking cooldown ensures coverage is available across the loss-recognition window. This means that no matter what and how a possible bad debt arises (e.g. smart contract losses, exploits, counterfeit collateral), Umbrella coverage would apply. The design assumed that bad debt is recognised soon after the loss event. However, this assumption does not hold cleanly. An asset impaired by exploit, key compromise, or insolvency may not reflect the correct internal exchange rate for weeks or months while losses consolidate, redemption queues clear, and off-chain recovery processes run their course. If loss recognition moves more slowly than the cooldown, coverage can substantially reduce before slashing can fire; whether and when to pause Umbrella under those conditions becomes a live tactical question with material market-signalling cost.

The framework extends Umbrella along three dimensions, each addressing the recognition-lag gap:

Unstaking cooldown sized to loss recognition. The cooldown is sized against realistic loss-recognition timelines for the asset classes under coverage rather than against ordinary unstaking convenience, with a freeze condition added when an asset-level stress signal is active so that unstaking cannot drain the coverage pool during the recognition window.
Slashing trigger extended with upstream signals. Upstream signals (oracle freeze, bridge balance mismatch, issuer governance action materially affecting backing) act as triggers for a coverage hold even before bad debt is reflected on the pool, so that automatic protection engages alongside the Freeze Guardian rather than waiting for the loss to land on Aave’s books.
Coverage bounded per chain. An Umbrella module deployed on one chain does not absorb bad debt generated on another chain. Expansion of the coverage to Aave’s instances across different chains would achieve this goal.
Loss reflection treated per collateral asset. Where the loss is reflected is treated per collateral asset by the asset issuer, as indicated in Section 1.9, where clear loss-handling scenarios are outlined by the issuer itself: that is, whether in the event of a bridge exploit the collateral loss is socialised across all chains or reflected only to the bridged representations of the token. Umbrella only reflects the bad debt that is generated due to the external loss handling decision.

4. Chain Risk

Aave’s deployment on a chain inherits every property of that chain. Chain-level failure modes (sequencer halts, reorgs, governance compromise, withdrawal lockouts, ecosystem adoption decay) affect every asset on the deployment regardless of how clean the asset or bridge configuration is. This layer 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 once it is live. Chain risk is therefore a precondition to Layers 1 through 3: an asset cannot pass Layer 1 onboarding on a chain that has not first passed this layer, and the chain’s evaluation tier sits as an upper bound on the exposure tier of every asset listed on the deployment.

4.1 Chain Evaluation Scope

Chain risk evaluation precedes asset and bridging evaluation for any new deployment. A chain that does not pass this layer is not a candidate for an Aave deployment, regardless of which assets or bridges might be intended for it. For existing deployments, chain risk is re-evaluated at the same quarterly cadence as the asset and bridging layers and out-of-cycle whenever material chain events occur (a halt, a reorg, a governance compromise, a major ecosystem participant exit). Chains that do not meet the requirements below are not candidates for an Aave deployment; chains that pass but with material residual risk carry that risk as a standing constraint on every deployed asset.

4.2 Network Architecture and Security Model

The chain’s architecture determines the inherent failure modes Aave inherits. Consensus mechanism, settlement model (for L2s), and the security assumptions backing them are evaluated as standing structural properties.

Requirements:

Consensus mechanism and finality model documented.
Settlement layer identified for L2s, the bridge from the L2 to its settlement layer evaluated under the standing requirements in Layer 2.
Virtual machine support and any divergence from standard EVM documented, including precompile behaviour, opcode differences, and gas-model variations that affect Aave’s contracts.
Chain contracts (consensus, settlement, governance) covered by audits from reputable firms; audit reports available.
Active bug bounty programme on the chain’s codebase, sized commensurate with the chain’s TVL and the same floors that apply at the asset level.
Source code for the chain’s consensus, execution, and settlement components is open and publicly auditable.

Closed-source consensus or settlement layer code, missing audits on chain contracts, unrated L2 settlement security, or material undocumented divergence from standard EVM behaviour materially constrain the chain’s evaluation tier.

4.3 Decentralisation

Consensus-layer decentralisation determines whether the chain can be censored, halted, or rolled back by a small set of actors. For L2s, sequencer decentralisation and the path to permissionless sequencing are the binding properties. For L1s, validator set composition and concentration carry the same role.

Requirements:

Validator or sequencer count, identity, and geographic distribution documented.
Client diversity assessed; single-client dependency on the chain’s consensus is treated as a single point of failure.
For L2s, sequencer model documented (single sequencer, shared sequencer, or permissionless), with single-sequencer dependence treated as a binding constraint on the chain’s exposure tier until permissionless sequencing is in place.
Validator entry, exit, and slashing mechanics documented for L1s; staking economics evaluated for stake concentration and operator alignment.
Geographic and infrastructure concentration risk assessed across the operator set (jurisdiction, cloud provider, RPC dependence).
Revenue distribution and stakeholder alignment documented, including any disproportionate concentration of fee revenue or block-building rewards.

A single sequencer, validator concentration above honest-majority thresholds in a single entity or jurisdiction, or single-client dependency materially constrains the chain’s exposure tier.

4.4 Finality, Withdrawal, and Escape Mechanics

Finality lag and withdrawal mechanics determine the speed at which exposure can be unwound under stress, and the conditions under which holders retain access to their assets if the chain’s operators disappear or misbehave.

Requirements:

Finality model and finality lag documented; probabilistic, economic, and deterministic finality stated explicitly rather than conflated.
Reorg history documented, including any reorgs deeper than the chain’s standard finality assumption.
For L2s, withdrawal mechanism and standing withdrawal delay are documented (typically multi-day for optimistic rollups, near-instant for zk rollups).
Forced-inclusion or escape-hatch availability documented for L2s; absence of a forced-inclusion path is treated as a single point of failure on the sequencer.
Fraud-proof or zk-proof maturity assessed for L2s; permissioned or stub-proof systems carry standing exposure constraints until proof systems are live and permissionless.
MEV market characteristics that materially affect liquidation execution documented, including private orderflow concentration and any sequencer-level prioritisation. In the case that significant MEV activity is present, a deployment of Chainlink SVR may be needed to mitigate the risk of spam activity or other user affecting behaviours.

Probabilistic finality without bounded reorg depth, withdrawal mechanics that depend entirely on an honest sequencer, or absent escape hatches materially constrain the chain’s exposure tier.

4.5 Chain Governance and Upgrade Control

The chain’s governance is the standing authority that can change every other property in this layer. Disclosure and timelock requirements on chain governance are binding for the same structural reasons they are binding on issuer authorities at the asset level.

Requirements:

Upgrade authority for chain contracts identified, including settlement-layer contracts for L2s.
Multisig composition, quorum, and signer identity disclosed for upgrade and pause authorities.
Timelock delays on critical upgrades are documented; sub-day or instantaneous upgrade paths on production chain contracts are treated as a binding constraint until remediated.
Pause and emergency-action authorities identified, including the conditions under which they can be invoked and the parties holding them.
Governance token distribution and voting concentration documented where on-chain governance is the upgrade path, with the same honest-majority and concentration scrutiny applied to multisigs at the asset level.
Change-management process documented for hard forks and consensus-layer upgrades.

Single-signer or sub-honest-majority control of chain upgrade authorities, sub-day timelocks on production-critical upgrades, or undisclosed governance arrangements materially constrain the chain’s exposure tier.

4.6 Operational History

Operational history is the standing record against which the chain’s stated properties are tested. A chain whose architecture promises strong properties but whose record shows frequent halts or unresolved incidents is evaluated on the record rather than on the design documentation.

Requirements:

Halt incidents documented with duration, root cause, and resolution.
Reorg incidents documented with depth and resolution.
Post-mortems published for material incidents.
Time-to-recovery on prior incidents documented.
Recurrence patterns evaluated; repeated halts or reorgs on the same root cause are treated as standing exposure constraints until structurally addressed.

Chains with frequent unresolved halts, reorgs deeper than stated finality assumptions, absent post-mortems on material incidents, or unaddressed recurrence patterns materially constrain the standing exposure tier.

4.7 Ecosystem Adoption and Market Infrastructure

The chain’s ecosystem determines whether Aave can operate sustainably on it: whether liquidations can clear at acceptable slippage, whether the ecosystem supports the DeFi primitives Aave depends on, and whether the bridging and on-ramp infrastructure supports the asset flow Aave needs. Adoption metrics are evaluated as a structural property of the chain rather than as a growth forecast.

Requirements:

Aggregate adoption metrics documented: TVL, stablecoin TVL and dominance, active addresses, transaction baseline, protocol count and concentration, total value borrowed across the chain.
DeFi vertical coverage assessed: lending, DEXs, stablecoins, derivatives, oracles, with explicit attention to gaps that materially affect Aave’s operation (e.g. absent stablecoin venues, missing perp markets for hedging, missing critical oracle infrastructure such as Chainlink).
DEX liquidity depth on major pairs documented; LP fragmentation and concentration assessed under the same standards applied at the asset level.
Bridge accessibility: bridge stacks supported, each evaluated under the standing requirements in Layer 2.
On-ramp and off-ramp infrastructure documented, including fiat and CEX withdrawal corridors.
Wallet and portfolio support across major wallets documented.
Competing lending markets on the chain documented, including their parameter settings and any market-distorting incentive programmes.
Ecosystem resilience properties: presence of community or foundation entities positioned to coordinate liquidity restoration during stress, depth of grants programmes, partnerships with adjacent ecosystems.

Ecosystems with insufficient DEX depth for liquidation execution, single-bridge dependence on the chain, missing critical DeFi primitives, or absent crisis-response coordination capacity materially constrain the chain’s exposure tier.

4.8 Tooling and Monitoring Support

Aave’s standing monitoring and risk-management infrastructure depends on chain-level tooling support. A chain that lacks indexing, analytics, or RPC infrastructure cannot be monitored at the cadence Layer 3 requires, and the monitoring layer’s coverage gaps translate directly into standing exposure constraints.

Requirements:

Block explorer with full functional parity to Etherscan available (verified-source uploads, event decoding, contract interaction).
Indexing and analytics platforms support the chain (Dune, DeFiLlama, TokenTerminal, Flipside, theGraph, or equivalents covering the same use cases).
RPC provider diversity is documented; single-RPC dependence is treated as a binding constraint on the monitoring layer’s coverage.
Wallet integration across major wallets documented.
Risk-monitoring tooling and oracle providers (Chainlink, Chainlink CRE, and equivalents) operate on the chain at the cadence the monitoring layer requires.
On-chain data availability supports the asset-state, authority-queue, and infrastructure signals the monitoring layer depends on.

Chains where the monitoring layer cannot operate at the required cadence, or where indexing and analytics support is materially below the standard expected for an Aave deployment, materially constrain the chain’s exposure tier.

4.9 Native and Major Asset Liquidity

The chain’s own native asset and the major assets bridged to the chain (ETH, BTC, stablecoins) are typically the deepest liquidity pools on the chain and form the structural backbone for any other asset’s liquidation depth. Their depth and stability are evaluated as chain-level properties because they propagate to every other listing.

Requirements:

Native token DEX volume distribution, price stability, and collateralisation rates documented.
Major asset availability and liquidity depth on the chain documented across the asset classes Aave intends to list (ETH-correlated, BTC-correlated, stablecoins).
Volume distribution evaluated for organic versus incentive-driven flow, under the same qualitative framework applied at the asset level.

Insufficient depth on the chain’s major assets, native-token instability, thin LP diversity on the chain’s deepest pools, or volume materially supported by active incentive programmes constrains the standing exposure tier for every asset listed on the chain.

4.10 Per-Asset and Per-Deployment Implications

The chain’s evaluation tier under this layer sets standing constraints on every asset deployed on the chain and propagates into the cross-chain exposure tier of any asset bridged onto the chain.

Operational treatment:

The chain’s tier sets an upper bound on the LTV, supply cap, and borrow cap of every asset listed on the chain, regardless of the asset’s own Layer 1 evaluation.
Cross-chain expansion onto a chain with a weaker tier carries the chain’s standing constraints onto the bridged asset’s exposure tier on that chain.
Whole-deployment deprecation under the Market Deprecation rules in Layer 1 is triggered when chain risk degrades materially without remediation, in addition to the existing economic and asset-stability triggers.
The chain’s tier is published as part of Aave’s standing risk classification and updated at every quarterly refresh.

Chain risk is therefore a standing constraint on every asset on the chain.

JosueMpia · June 9, 2026, 1:50pm

Thanks for the detailed breakdown.

robtg4 · June 9, 2026, 9:12pm

I’ve been waiting for someone to write this document. Protocols had risk teams, they had dashboards, they had ad hoc parameter recommendations, but they didn’t have a document that said “here is what we require, here is what triggers a hard block, here is who holds veto authority, and here is what happens when someone fails to comply.” LlamaRisk has written that document, and the Aave DAO should understand the significance: if adopted, this becomes the most comprehensive formalized risk governance framework in DeFi.

Let me walk through what I think the framework gets right, where I see gaps, and what questions the DAO should be asking before ratification.

What it gets right. The four-layer structure (Asset, Bridging, Monitoring, Chain) maps the actual attack surface of a multi-chain lending protocol. Most risk frameworks stop at Layer 1 — they evaluate the asset and call it done. But any protocol operating on L2s inherits bridge risk (Layer 2) and chain risk (Layer 4) whether they model it or not, and the monitoring infrastructure (Layer 3) determines whether theoretical risk parameters translate into actual protection during incidents. The fact that LlamaRisk treats these as four co-equal layers rather than one primary layer with footnotes is structurally correct.

The hard-block taxonomy is the most important operational innovation. Historically, Aave onboardings have proceeded despite outstanding deficiencies because there was no formal mechanism to say “no.” The framework gives service providers explicit veto authority on enumerated conditions — undisclosed claims seniority, absent timelocks, inadequate bug bounty coverage — and creates a bright line between “recommendation with flexibility” and “non-negotiable prerequisite.” The $50K minimum bug bounty for critical findings, scaling with TVL, is a concrete threshold that will immediately filter out a class of hastily launched protocols seeking Aave listings for credibility.

The MPC vs. multisig analysis is subtle and correct. Accepting MPC custody with heightened disclosure requirements (private NDA disclosure of shard composition) rather than outright rejection reflects the reality that some of the highest-value assets in the ecosystem use MPC custody. The framework creates a disclosure asymmetry where on-chain multisig gets lower friction because the signing structure is publicly observable, while MPC requires private disclosure because the shard structure is opaque. That asymmetry is the right one.

Where I see gaps. The quarterly due diligence cadence with one-month remediation windows is appropriate for steady-state operations, but the framework doesn’t clearly address what happens during rapid market regime changes. In the span of two weeks in November 2022, FTX collapsed, contagion spread to BlockFi, Genesis, and Gemini Earn, and every lending protocol’s collateral assumptions changed overnight. A quarterly cadence with monthly remediation means the framework could take up to five months to formally respond to a regime shift. The material-change taxonomy that triggers out-of-cycle re-evaluation needs to be explicit about what constitutes a material change in market structure, not just in individual asset characteristics.

The claims seniority disclosure requirement — “undisclosed or ambiguous claims seniority on assets with multiple holder classes is a hard-block condition” — is excellent in principle but may be difficult to enforce for assets backed by legal structures in jurisdictions that don’t recognize DeFi-specific claim hierarchies. What happens when the issuer says “our legal counsel advises that claims seniority depends on the jurisdiction of the claimant”? The framework should address the case where disclosure is legally ambiguous, not just the case where it’s withheld.

The third gap is structural and, I’d argue, the one to resolve before ratification: the framework specifies what must be disclosed in exhaustive detail, but not how disclosures are delivered, verified, or kept current. As written, the obligations across 1.8–1.12, 1.15, and 2.1 will arrive as PDFs and NDA’d documents. That undermines the framework’s own logic in three places:

Attestation format determines monitoring feasibility. Layer 3 mandates automated monitoring of backing state, reserve composition, and authority changes — but if the underlying disclosures are unstructured documents, the monitoring layer is reconstructing machine-readable state from prose. Disclosures under 1.9, 1.10, and 1.15 should be required in a structured, cryptographically signed format the Freeze Guardian and Cap Oracle can consume directly. A backing attestation that stops updating or fails signature verification is itself a hard adverse signal — and a cleaner, earlier one than waiting for price effects to surface on-chain.
Quarterly delta reports should be diffs, not re-collection. Section 1.14 requires a delta report against the prior baseline every quarter. If disclosures are versioned, signed credential state, the delta is computed rather than compiled. That cuts the risk provider’s per-asset refresh cost and makes the change history auditable by construction — which is the stated goal.
Pre-notification under 1.15 needs to be provable. The framework makes failure to disclose a material change in advance a remediation trigger. Without a timestamped, signed disclosure rail, “we notified in advance” is unverifiable in both directions. A signed change-event stream resolves those disputes before they happen and gives the monitoring layer a clean feed to suppress false-positive anomaly alerts on announced changes.

Note that a structured attestation standard also answers my claims-seniority concern above: a machine-readable seniority credential can encode conditional hierarchies — “holders in jurisdiction X take priority Y under condition Z” — where a prose disclosure collapses into “it depends.” Legally ambiguous seniority becomes a structured, priceable input rather than a hard-block stalemate between the issuer’s counsel and the risk provider.

A concrete suggestion. Add a subsection (1.10.x, or a new 1.21) establishing a machine-readable attestation standard for backing composition, claims seniority, and material-change pre-notification — format-agnostic, but requiring (a) cryptographic signature by the issuer, (b) component-level granularity matching 1.10, (c) versioned state supporting automated deltas, and (d) an ingestion path into the CRE-based oracle layer defined in 3.2. This is the same move the framework already makes with Chainlink risk tiers: take something previously evaluated episodically and make it a continuous, binding input.

For RWA assets on Horizon specifically — where value depends on legal arrangements the chain cannot observe — this is the difference between the framework being enforceable and being aspirational. Episodic attestation on assets whose backing surface shifts daily is exactly the mismatch 1.10 warns against.

Disclosure: I work on machine-readable compliance attestation infrastructure for tokenized RWAs (CPO at Bluprynt), so I have an obvious interest in this gap — which is why the standard should be open and vendor-neutral. The framework gets stronger if any qualified attestation provider can plug into it, and weaker if disclosures stay in PDF. Happy to contribute a draft schema for 1.9/1.10/1.15 attestations if useful to LlamaRisk’s process.

– Robby Greenfield | CPO, Bluprynt | Tokedex.org

Kazuki · June 10, 2026, 7:40am

Strong framework. The shift from point-in-time review to continuous due diligence, plus defensive-only automated freeze/cap logic, is the right structural move — and the bridging baseline (≥3 independent verifiers, no 1-of-N or 2-of-N default) is a clean, direct answer to the root cause.

One observation on the part I think is hardest to close from inside any single protocol. §1.11 (dependencies “shared with… other listed assets”) and §1.9 (cross-chain symmetry / loss-bearing hierarchy) both point at a horizontal surface — what an asset shares with actors and positions that live outside Aave. That’s where the rsETH event actually propagated: the shared WETH Reserve connected exposure with nothing to do with rsETH — Fluid loops and other looped positions on the same reserve — to the impaired collateral. From one vantage you can see your own reserve’s locked-vs-minted state (L3.1 captures that well), but “who else, across protocols, inherits this same reserve / collateral / verifier set” isn’t visible from inside a single protocol.

The more useful version of §1.11 is to trace that surface, not just disclose it: start from a shared reserve or verifier set, list every actor and protocol exposed to it, and follow where a break spreads. That cross-protocol map is the one piece no single protocol can own — by definition it sits between them.

Disclosure: this is what we build at ZKSC / Ninja — a neutral, cross-protocol dependency graph — so I have an obvious interest in this surface being treated as first-class. Which is exactly why it has to be neutral: no single protocol can map the exposure it shares with its competitors. Happy to share how the rsETH cascade looks reconstructed across protocols, or to contribute to how the horizontal surface gets specified in §1.9 / §1.11, if useful to LlamaRisk’s process.

-– Kazuki Kaneshiro, ZKSC / Ninja

LlamaRisk · June 12, 2026, 8:59pm

Changelog

v1.1 — 2026-06-12

Edits resolving bridge-stack role definitions with LayerZero. The
common thread: requirements that assumed a single “vendor” are
reallocated across the messaging vendor, the verification operators,
and the issuer/application, to match which party actually holds each
control.

Normative:

§2.6 Pause pathways: vendor-side pause requirement broadened to a
“vendor or verification-operator-enforced” ability to halt
verification, exercisable by the vendor or operator’s incident team.
Dropped the “(typically the vendor)” framing.
§2.10 Incident response: monitoring-responsibility requirement
reworded — security/integrity monitoring of the verification-and-
messaging layer sits with the entity operating that layer, alongside
the issuer’s application-level monitoring of cross-chain correctness.
§2.11 Monitoring teams: rescoped so verification-layer integrity sits
with the operating entity and application-level monitoring/response
sits with the issuer; bullet 1 reworded accordingly. Removed the
requirement that both vendor and issuer teams hold pause/rate-limit
authority (this authority remains required at the on-call level under
§2.10). Final bullet reworded to a mutual non-offloading obligation.

Editorial:

§2.6 Moved the single-pause-path line from the requirements list into
the closing paragraph (no change in meaning).
§2.12 “Per-lane initial limits” → “Per-route initial limits” for
consistency with the rest of Layer 2.

v1.0 — 2026-06-09

Initial ARFC.

chainza · June 17, 2026, 2:32pm

Building on Kazuki’s map vs. simulation framing above: §1.9/§1.11 are hard from inside one protocol for a reason worth naming explicitly. V4’s close factor design means correlated spokes (Lido, EtherFi, Kelp) ramp to 100% almost immediately once HF dips below 1, while spokes like Main stay lenient much longer. If a shared dependency stresses several correlated spokes at once, you get near-simultaneous aggressive liquidations across positions that look isolated in the spoke design but aren’t behaviorally isolated under stress. That’s exactly the kind of thing a dependency map alone won’t catch, because the map is static and this failure mode only shows up once you run the position math forward under stress. Feels like a genuinely different engineering problem from the map itself – tracking who depends on whom is one thing, simulating what happens when that dependency actually breaks is another. Curious whether @LlamaRisk sees that as something §1.9/§1.11 should formally call out as a separate layer, or whether it’s meant to be folded into the same dependency-mapping scope.

Kazuki · June 18, 2026, 12:45am

@chainza — agreed it’s a separate layer. The part worth adding is that the layer needs a substrate that isn’t a first-class artifact yet.

Two things sit inside §1.9/§1.11 and are easy to conflate:

1 — The neutral cross-protocol surface (the map). From a shared reserve / collateral / verifier set: who across protocols inherits it, and where a break propagates. rsETH is the obvious example — the exposure that mattered ran through a shared WETH reserve and the looped positions on it, none of it visible from inside any single protocol.

Figure 1 — T-1 (pre-incident)

Pre-incident. The dependency between rsETH, Aave’s shared WETH reserve, and the Fluid Lite positions exists but is latent — from inside any single protocol these look isolated.

Figure 2 — T+2 (into the incident)

T+2 into the incident. The latent edges are now live: impairment propagates rsETH → shared WETH reserve → Fluid Lite vault → downstream holders. The cross-protocol surface a static, single-protocol view never shows.

This horizontal piece is the one no single protocol can own — by definition it lives between them, and it isn’t a first-class artifact in any framework yet. That’s the gap I’d close first.

2 — Forward stress on that surface (the simulation). Running the position math forward into the close-factor cascade you describe. Worth being precise about ordering: a stress-sim is only as good as the surface it runs on — you can’t simulate edges no one has mapped, and a single-protocol sim misses exactly the cross-protocol edges that carry these events. So it’s map → simulation, not either/or.

Concretely I’d frame it as three stages, not one:

(1) Establish the neutral map as first-class — the shared reserve / collateral / verifier sets and who inherits them across protocols.
(2) Scenario path-tracing — freeze or impair an asset / verifier set and follow where the break propagates, and in what order. Deterministic.

(3) The quantitative model you’re describing — position math forward into the close-factor dynamics. The genuinely new engine, built on (1)+(2).

I’ve reconstructed the rsETH episode cross-protocol and am glad to walk @LlamaRisk, or anyone speccing §1.9/§1.11, through it.
The constraint I’d keep first-class throughout: this only works if the map is neutral — no single protocol can map the exposure it shares with its competitors.

–– Kazuki Kaneshiro, ZKSC / Ninja

Abel189 · July 7, 2026, 5:22am

I support the introduction of a unified risk framework as an important step toward improving consistency across Aave V3, V4, and Horizon. Defining clear standards for asset evaluation, bridge security, chain assessment, and continuous monitoring helps ensure that governance decisions are based on transparent and repeatable criteria rather than case-by-case judgments.

I particularly appreciate the emphasis on continuous due diligence, material-change reviews, and automated monitoring systems. As Aave expands across multiple chains and supports an increasingly diverse range of assets, a structured framework becomes just as important as the individual risk parameters themselves.

Going forward, it will also be valuable to periodically review and refine the framework as new technologies, bridge architectures, and risk models emerge, ensuring that the governance process remains both rigorous and adaptable.

Topic		Replies	Views
[ARFC] Technical Asset Listing Framework General	5	1030	July 9, 2026
LlamaRisk: Ensuring Continuity of Aave's Risk Management Risk	5	861	June 22, 2026
[TEMP CHECK] Post-rsETH Collateral Framework: Tier-Based LTV Reductions and Wrap-Depth Ineligibility Limits Risk	16	995	June 16, 2026
MetaMask USD (mUSD) on Aave Monad Assessments Assets Assessments	1	58	July 1, 2026
LlamaRisk - Monthly Community Update Governance	25	2633	July 3, 2026

[ARFC] Aave Risk Framework

Summary

1. Asset Risk

1.1 Asset Classification Adherence

1.2 Multi-Chain Evaluation Scope

1.3 Smart Contract Audit Coverage

1.4 Bug Bounty Coverage

1.5 Liquidity and Market Structure

1.6 Timelock Requirements

1.7 Signing Authority Decentralisation and Custody

1.8 Legal Disclosures

1.9 Holder Claims Seniority and Loss-Bearing Hierarchy

1.10 Asset Backing Structure and Visibility

1.11 Issuer Operational Stack Disclosure

1.12 Pre-Agreed Incident Communication Baseline

1.13 Hard-Block Conditions and Veto Authority

1.14 Continuous Due Diligence Cadence

1.15 Material-Change Taxonomy

1.16 Remediation Timelines and Residual Risk Treatment

1.17 Asset Deprecation Triggers

1.18 Oracle and Price-Feed Treatment

1.19 Market (Deployment) Deprecation Criterion

1.20 Market Deprecation Playbook

2. Bridging Risk

2.1 Bridge Topology Disclosure

2.2 Verifier Set Threshold Requirement

2.3 Verifier Independence Requirements

2.4 Mutable Send and Receive Libraries

2.5 Bridge Authority and Ownership Timelocks

2.6 Separate Pause Pathways

2.7 Custody Requirements at the Bridge Layer

2.8 Per-Route Rate Limiting Requirement

2.9 Rate Limit Sizing Methodology

2.10 24/7 Redphone and Incident Response Requirements

2.11 Dedicated Security and Monitoring Team Requirements

2.12 Bridge Configuration Lifecycle: Initial Limits

2.13 Bridge Configuration Lifecycle: Review

2.14 Bridge Configuration Lifecycle: Cadence and Out-of-Cycle Triggers

2.15 Bridge Stack Evaluation Pillar: Additional Infrastructure Risk

2.16 Bridge Stack Evaluation Pillar: Uniformity vs. Configuration Flexibility

3. Monitoring and Automated Risk Oracle Systems

3.1 Enforced Continuous Monitoring of Aave-external Layers

3.2 Continuous Risk Oracles and Automated Freeze Guardians

3.3 Risk Stewards as Human-in-the-loop Complement

3.4 Umbrella Coverage Role

4. Chain Risk

4.1 Chain Evaluation Scope

4.2 Network Architecture and Security Model

4.3 Decentralisation

4.4 Finality, Withdrawal, and Escape Mechanics

4.5 Chain Governance and Upgrade Control

4.6 Operational History

4.7 Ecosystem Adoption and Market Infrastructure

4.8 Tooling and Monitoring Support

4.9 Native and Major Asset Liquidity

4.10 Per-Asset and Per-Deployment Implications

Changelog

v1.1 — 2026-06-12

v1.0 — 2026-06-09

Related topics