Risk Stewards: Supply and Borrow Cap Adjustments on Aave V3 / 2026.04.24

[LlamaRisk]

Summary

Following the Kelp-induced market stress and the subsequent unwinding cycle, supply across many Aave V3 reserves has contracted well below previously calibrated caps. This proposal recommends a coordinated cap reduction across the affected reserves on Aave V3, removing the stale headroom that accumulated as positions exited the protocol, and deprecating a small set of reserves that no longer serve their listed markets.

The intent is twofold: (i) bring caps back in line with realistic near-term usage so that concentration risk does not reappear silently if a single large deposit arrives between monitoring cycles, and (ii) keep the path back to higher caps short and procedurally cheap, with each reduction sized to remain reversible through the Risk Steward framework as conditions normalize.

Context

The recent stress event prompted broad de-risking across the protocol. Many reserves now sit at low utilization of their existing caps, with the gap between current cap and current supply ranging from material to extreme. Caps that sit far above actual usage provide no operational benefit and expose the protocol to abrupt concentration if a single depositor enters during a parameter review.

Rather than freezing reserves outright, the approach here is to right-size caps to current conditions while leaving room for organic recovery, and to mark a small subset of reserves for deprecation where their continued presence no longer serves the market they sit in.

Methodology

Adjustments are grouped by asset role and observed behavior rather than applied uniformly across the book. Each group has its own rationale, summarized below.

Collateral assets

For collateral-enabled reserves, supply caps are reduced so that the resulting headroom above current supply sits in the range of 50% to 75%. This buffer is wide enough to absorb plausible recovery flows without triggering an immediate cap top-out, and tight enough to keep concentration manageable. The sizing also preserves the option to lift the cap back toward its prior level in a single Risk Steward action if the unwinding reverses, since the steward’s per-action limit of ±100% relative to the current cap covers a one-step revert from the new value.

Where a collateral reserve has not historically attracted meaningful borrow activity, the borrow cap is set to 1, a soft freeze that closes new borrowing without formally freezing the reserve. This removes unused configuration surface and concentrates the asset’s role on the supply side, where it actually serves the market.

Stablecoins

Stablecoin reserves receive a wider buffer on both supply and borrow caps. Stable liquidity is most likely to return first as conditions normalize, and oversized headroom in stablecoins carries less concentration risk than in volatile collateral. Borrow caps are set so that returning supply can be productively borrowed without requiring a fresh governance action in the immediate aftermath of this cleanup.

Reserves with no proven borrow usage

A subset of assets across markets has shown no meaningful borrow demand since listing or since the last parameter review. For these, the borrow cap is set to 1. Supply caps for these assets are still adjusted under the collateral or stablecoin rule above, depending on the asset type. The borrow side is closed because there is no demand to serve, not because of a risk concern with the asset itself.

Deprecation track

A small group of reserves is being moved toward deprecation via a soft freeze, with the supply cap set to 1. Soft-freeze leaves existing positions untouched while preventing new deposits, which is the cleanest way to retire a reserve without disrupting users still holding it. Three sub-cases are included:

• Persistently low utilization across markets: assets such as mUSD that have not gained meaningful traction on the markets where they are listed. Continuing to maintain calibrated caps for them is operational overhead that does not offset the benefits.
• Assets that no longer fit the market composition: USDS on Ethereum Prime, where the stablecoin lineup of the instance has shifted, and USDS no longer plays a useful role alongside the assets that have grown around it.
• Matured Pendle Principal Tokens: PTs whose maturity date has passed, on Ethereum Core and Plasma. Once a PT matures, supply unwinds mechanically toward zero, and the reserve no longer serves its original purpose, so soft-freeze formalizes a state the asset is already converging on.

Markets and assets not addressed

A few markets and assets are intentionally excluded from this round:

• X Layer and MegaETH: both deployments are entering their bootstrapping phase shortly, with caps already calibrated to the incoming liquidity commitments. Adjusting them now would conflict with the launch parameters and is left out of scope.
• Polygon: the market currently exhibits balanced supply-to-cap usage across reserves, with no material headroom to reclaim. Changes are omitted at this time, and the market will be revisited on the next regular cadence.
• GHO: GHO parameters are managed under the broader multichain GHO strategy curated by the GHO Stewards and remain outside the scope of this proposal.

Specification

The full parameter set is provided in the tables below, grouped by chain. Each entry lists the current cap, the proposed new cap, and the resulting utilization at the new value.

Collateral assets, supply, and borrow cap reductions

Asset	Chain	Current Supply cap	Proposed Supply cap	Current Borrow cap	Proposed Borrow cap
AAVE	Arbitrum	43,000	21,500	-
ARB	Arbitrum	101,300,000	52,000,000	-
LINK	Arbitrum	1,889,000	1,000,000	-
rETH	Arbitrum	1,600	1,300	-
WBTC	Arbitrum	5,000	3,500	416
weETH	Arbitrum	121,000	70,000	-
wstETH	Arbitrum	69,000	34,000	1,300
BTC.b	Avalanche	6,000	3,000	79
LINK.e	Avalanche	308,000	155,000	-
sAVAX	Avalanche	12,130,000	10,000,000	-
WETH.e	Avalanche	38,000	20,000	31,930	18,000
AAVE	Base	30,000	10,000	-
cbBTC	Base	5,800	3,500	380
cbETH	Base	9,000	5,000	1,010
ezETH	Base	5,000	500	-
LBTC	Base	80	50	-
tBTC	Base	30	20	-
weETH	Base	150,000	100,000	-
wstETH	Base	41,000	25,000	1,200
Cake	BSC	1,200,000	600,000	-
ETH	BSC	13,000	10,000	8,000
WBNB	BSC	187,000	160,000	12,000
WETH	Celo	3,000	2,100	900
1INCH	Ethereum Core	18,000,000	7,000,000	-
AAVE	Ethereum Core	1,850,000	1,000,000	-
BTC.b	Ethereum Core	600	10	-
cbBTC	Ethereum Core	32,000	25,000	1,440
CRV	Ethereum Core	17,250,000	11,000,000	-
eBTC	Ethereum Core	1,800	400	-
ENS	Ethereum Core	100,000	50,000	-
ezETH	Ethereum Core	120,000	20,000	-
LBTC	Ethereum Core	5,700	3,000	-
LDO	Ethereum Core	5,000,000	2,000,000	-
LINK	Ethereum Core	20,000,000	15,000,000	1,000,000
osETH	Ethereum Core	200,000	180,000	-
rETH	Ethereum Core	90,000	60,000	-
RPL	Ethereum Core	840,000	550,000	-
tBTC	Ethereum Core	3,000	2,800	-
tETH	Ethereum Core	10,000	1,000	-
UNI	Ethereum Core	6,000,000	1,500,000	-
WBTC	Ethereum Core	49,875	42,000	4,000
weETH	Ethereum Core	2,600,000	2,200,000	-
WETH	Ethereum Core	3,800,000	3,400,000	3,600,000	3,060,000
wstETH	Ethereum Core	1,760,000	1,400,000	-
XAUt	Ethereum Core	30,000	25,000	-
tETH	Ethereum Prime	60,000	45,000	-
WETH	Ethereum Prime	150,000	60,000	143,000	54,000
wstETH	Ethereum Prime	200,000	100,000	-
GNO	Gnosis	140,000	110,000	20,000
WETH	Gnosis	4,600	3,500	2,400
wstETH	Gnosis	15,000	13,000	150
ezETH	Linea	35,000	20,000	-
WBTC	Linea	100	40	-
weETH	Linea	64,000	5,000	-
wstETH	Linea	7,000	500	1,000	450
FBTC	Mantle	50	30	-
WMNT	Mantle	5,000,000	1,900,000	-
LINK	Optimism	235,000	100,000	-
OP	Optimism	14,050,000	8,000,000	-
rETH	Optimism	1,200	1,000	-
WBTC	Optimism	480	350	32
WETH	Optimism	23,000	20,000	16,000
wstETH	Optimism	23,000	16,000	190
weETH	Plasma	52,000	10,000	-
XAUt0	Plasma	7,000	3,500	-
stS	Sonic	126,000,000	100,000,000	-
WETH	Sonic	5,000	2,500	500
wS	Sonic	300,000,000	220,000,000	130,000,000

Stablecoin reserves, supply, and borrow cap reductions

Asset	Chain	Current Supply cap	Proposed Supply cap	Current Borrow cap	Proposed Borrow cap
DAI	Arbitrum	9,815,000	4,900,000	7,481,000	4,410,000
USDC	Arbitrum	512,300,000	300,000,000	386,900,000	270,000,000
USDC.e	Arbitrum	4,412,000	1,700,000	2,395,000	1,530,000
USD₮0	Arbitrum	179,000,000	120,000,000	112,400,000
AUSD	Avalanche	1,371,000	1,000,000	1,142,000	900,000
DAI.e	Avalanche	9,639,000	6,200,000	5,414,000
EURC	Avalanche	12,000,000	6,000,000	11,200,000	5,400,000
sUSDe	Avalanche	5,000,000	1,000,000	-
USDC	Avalanche	240,300,000	150,000,000	173,800,000	135,000,000
USDe	Avalanche	5,000,000	1,000,000	4,250,000	700,000
USDt	Avalanche	144,500,000	100,000,000	88,850,000
EURC	Base	35,830,000	25,000,000	12,000,000
syrupUSDC	Base	200,000,000	100,000,000	-
USDbC	Base	1,193,000	500,000	1,085,000	450,000
USDC	Base	685,200,000	230,000,000	485,000,000	207,000,000
FDUSD	BSC	12,000,000	1,200,000	10,800,000	1,080,000
USDC	BSC	49,080,000	21,000,000	28,710,000	18,900,000
USDT	BSC	164,000,000	67,000,000	117,000,000	60,300,000
EURm	Celo	160,000	100,000	144,000	90,000
USDC	Celo	3,500,000	2,000,000	3,150,000	1,800,000
USDm	Celo	1,300,000	1,100,000	1,170,000	990,000
USD₮	Celo	24,000,000	5,800,000	7,200,000	5,220,000
EURC	Ethereum Core	105,000,000	46,000,000	96,000,000	41,400,000
LUSD	Ethereum Core	7,000,000	5,000,000	-
mUSD	Ethereum Core	5,000,000	1,000,000	4,500,000	900,000
PT-srUSDe-25JUN2026	Ethereum Core	120,000,000	100,000,000	-
PT-sUSDE-7MAY2026	Ethereum Core	550,000,000	300,000,000	-
PT-USDe-7MAY2026	Ethereum Core	45,000,000	30,000,000	-
PT-USDG-28MAY2026	Ethereum Core	80,000,000	40,000,000	-
PYUSD	Ethereum Core	500,000,000	300,000,000	300,000,000	270,000,000
RLUSD	Ethereum Core	750,000,000	100,000,000	300,000,000	27,900,000
sUSDe	Ethereum Core	1,700,000,000	900,000,000	-
syrupUSDT	Ethereum Core	150,000,000	100,000,000	-
USDC	Ethereum Core	7,500,000,000	5,000,000,000	7,000,000,000	4,500,000,000
USDe	Ethereum Core	2,700,000,000	2,000,000,000	2,500,000,000	1,800,000,000
USDS	Ethereum Core	80,000,000	50,000,000	76,000,000	34,200,000
USDT	Ethereum Core	9,500,000,000	6,000,000,000	8,800,000,000	5,400,000,000
USDC	Ethereum Prime	30,000,000	25,000,000	27,600,000	22,500,000
EURe	Gnosis	27,000,000	25,000,000	22,500,000
sDAI	Gnosis	24,000,000	20,000,000	-
USDC.e	Gnosis	12,000,000	10,000,000	11,000,000	9,000,000
mUSD	Linea	5,000,000	500,000	4,000,000	450,000
USDC	Linea	25,000,000	20,000,000	23,000,000	18,000,000
USDT	Linea	25,000,000	20,000,000	23,000,000	18,000,000
sUSDe	Mantle	320,000,000	300,000,000	-
USDC	Mantle	80,000,000	60,000,000	76,000,000	54,000,000
USDe	Mantle	160,000,000	100,000,000	72,000,000
USDT0	Mantle	800,000,000	450,000,000	550,000,000	405,000,000
DAI	Optimism	2,000,000	1,000,000	1,800,000	900,000
USDC	Optimism	39,940,000	28,000,000	27,270,000	25,200,000
USDC Bridged	Optimism	2,000,000	1,800,000	-
USDT	Optimism	14,570,000	10,000,000	9,060,000
sUSDe	Plasma	1,575,000,000	1,000,000,000	-
syrupUSDT	Plasma	550,000,000	450,000,000	-
USDe	Plasma	1,750,000,000	1,200,000,000	600,000,000
USDT0	Plasma	6,000,000,000	3,000,000,000	5,000,000,000	2,700,000,000
USDC	Sonic	50,000,000	20,000,000	20,000,000	18,000,000

Borrow caps set to 1 (no proven borrow usage)

Asset	Chain	Current Supply cap	Proposed Supply cap	Current Borrow cap	Proposed Borrow cap
tBTC	Arbitrum	50	35	25	1
cbETH	Ethereum Core	18,000	9,000	2,400	1
ezETH	Ethereum Prime	20,000	2,000	100	1
sUSDe	Ethereum Prime	5,000,000	3,000,000	1,000	1

Supply caps set to 1 (deprecation track)

Asset	Chain	Current Supply cap	Proposed Supply cap	Current Borrow cap	Proposed Borrow cap
ETHx	Ethereum Core	40,000	1	-
PT-srUSDe-2APR2026	Ethereum Core	200,000,000	1	-
PT-sUSDE-5FEB2026	Ethereum Core	720,000,000	1	-
PT-USDe-5FEB2026	Ethereum Core	360,000,000	1	-
USDS	Ethereum Prime	40,000,000	1	36,000,000	1
PT-sUSDE-9APR2026	Plasma	1,200,000,000	1	-
PT-USDe-9APR2026	Plasma	80,000,000	1	-

Next Steps

We will move forward and implement these updates via the Risk Steward process.

Disclosure

This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

[robtg4]

Supportive of the overall approach. Right-sizing caps after a stress-induced contraction is the correct move, and the methodology here — grouping adjustments by asset role rather than applying uniform haircuts — reflects the kind of risk-differentiated thinking that was missing in the cap architecture the rsETH exploit exposed.

That said, a few observations on what this proposal does well, where it leaves gaps, and what it reveals about the structural limits of manual cap management.

What This Gets Right

The 50-75% headroom target for collateral assets is well-calibrated. It threads the needle between two failure modes: caps set so tight they choke organic recovery (which would extend the confidence crisis), and caps left so loose they recreate the exact concentration vectors the exploit used. The key insight in the methodology is that the headroom is sized to be reversible in a single Risk Steward action. That’s operationally intelligent — it means governance doesn’t need a full AIP to re-expand if capital returns faster than expected. One step out, one step back. Clean.

The stablecoin differentiation is correct. Stable liquidity carries fundamentally different concentration risk than volatile collateral. A single large USDC deposit doesn’t introduce the same oracle/depeg cascading risk as a single large weETH or ezETH deposit. Wider headroom here is the right asymmetric bet: the downside of too-tight stable caps (grinding borrowing to a halt during recovery) is worse than the downside of too-wide ones.

The deprecation track for matured Pendle PTs is overdue good hygiene. Once a PT matures, its collateral value converges to its underlying mechanically. Maintaining active cap parameters for an asset whose economic function has expired is configuration debt. Soft-freezing via supply cap = 1 is the right tool — it preserves existing positions while preventing new surface area. Should have been automated at maturity, but better late than manual.

Where I’d Push Back

1. The ezETH and weETH reductions on Linea are aggressive enough to warrant separate justification. ezETH on Base goes from 5,000 → 500 (90% cut). weETH on Linea goes from 64,000 → 5,000 (92% cut). weETH on Ethereum Core goes from 2,600,000 → 2,200,000 (15% cut). These aren’t the same risk profile receiving different treatment — they’re radically different treatments that the “50-75% headroom” framework doesn’t explain. If weETH on Linea lost >90% of its supply, that tells a story about Linea as a deployment environment, not just about weETH as a collateral asset. That distinction matters for understanding where capital will return and where it won’t.

Similarly, tETH on Ethereum Core going from 10,000 → 1,000 (90% cut) versus tETH on Ethereum Prime going from 60,000 → 45,000 (25% cut) suggests either very different utilization profiles or very different confidence in the two instances. The proposal would benefit from making that explicit rather than leaving it to inference.

2. The borrow-cap-to-1 soft freeze for cbETH on Ethereum Core deserves scrutiny. Setting a borrow cap to 1 based on “no proven borrow usage” makes sense for niche assets, but cbETH is Coinbase’s staked ETH — not a fringe token. If cbETH borrow demand hasn’t materialized, the question is whether that’s because the market doesn’t want it or because the parameters never made it attractive. Soft-freezing borrowing on a major institutional asset during a period of suppressed activity risks cementing temporary disinterest as permanent policy. At minimum, this should carry an explicit review trigger — not just a path back through Risk Steward escalation, but a timeline.

3. The RLUSD reduction from $750M → $100M supply cap (87% cut) with borrow cap from $300M → $27.9M (91% cut) is the single most aggressive move in this proposal. For a Ripple-backed institutional stablecoin that was likely listed with strategic partnership considerations, this isn’t just cap management — it’s a signal. If RLUSD never attracted meaningful deposits, that’s valuable market data about institutional stablecoin demand on Aave. But governance should be explicit about whether this is a parameter adjustment or a de facto deprecation step, because the market will read it as one or the other regardless.

The Structural Question This Proposal Can’t Answer

This is the fourth time in six days that governance has spent time on supply cap parameters. The AaveShield proposal, the Automated Supply Cap Updater, the rsETH incident response, and now this cleanup. Each is individually justified. Together, they reveal a structural problem: manual cap management doesn’t scale across 23 markets, 20 chains, and 100+ reserves.

The methodology here is thoughtful. But it’s also a snapshot — calibrated to post-crisis supply levels on April 24, 2026. If capital returns over the next two weeks (which it will, partially), caps will need re-expansion. If another stress event hits a different asset class, caps will need re-contraction. Each adjustment requires a Risk Steward action, forum post, and community review cycle. That’s weeks of latency for a system where the exploit demonstrated that hours matter.

This proposal is the right short-term response. The Automated Supply Cap Updater, currently in Temp Check, is the right medium-term architecture. The fact that both are needed simultaneously is the strongest possible argument for fast-tracking the latter.

Support. Execute via Risk Steward as proposed. But treat this as the last manual cap recalibration of this scale — build the automation so the next stress cycle is handled by code, not by governance posts.

-– Robby Greenfield | tokedex.org

[LlamaRisk]

The changes have been executed across all deployments. We will continue evaluating the changing conditions and propose further Risk Stewards parameter changes as needed.

[gnarvaja]

Check [TEMP CHECK] Automated Supply Cap Updater – Restricting Short-Term Supply Increases in Aave V3 - #4 by robtg4 for an automated alternative to all this manual tweaking of the parameters

[GoldETH]

proposal is excellent crisis management, but mediocre long-term architecture. It’s like a city lowering all speed limits to 5 mph after a massive car crash. It definitely stops people from dying in high-speed collisions, but it also stops the city from functioning. It’s a reactive “band-aid” designed to show the market that someone is at the steering wheel.

To fundamentally change Aave so that a user feels safe coming back with their life savings, we have to move past “adjusting caps” and change how the protocol thinks.

Here are four realistic, fundamental solutions that would actually eliminate the fear of “contagion” loss:

---

1. Hard Siloing (The “Siloed Risk” Model)

The biggest problem with Aave V3 right now is contagion. If one weird asset like rsETH (which depends on a bridge and a restaking protocol) fails, it can drain “safe” assets like USDC and WETH because they all live in the same “Core” pool.

• The Solution: Move toward Isolated Lending Pairs. If you want to use a high-risk Liquid Restaking Token (LRT) as collateral, you can only borrow against a specific “Risk Pool.”

• The Result: If rsETH goes to zero tomorrow, only the people in the “rsETH-Risk Pool” lose money. The millions of users in the “USDC-WETH” pool are physically unable to be affected.

• Why it brings users back: It gives them a choice. “I want 3% yield with 0% risk of contagion” vs. “I want 15% yield and I accept the risk of the bridge.”

2. On-Chain Proof of Reserves (PoR)

Aave currently trusts the token balance it sees on the blockchain. In the Kelp hack, Aave saw “116,500 rsETH” and thought it was real. It didn’t know those tokens weren’t actually backed by ETH on the other side of the bridge.

• The Solution: Integrate Chainlink Proof of Reserve into the smart contract’s “Borrow” function.

• The Logic: Before the code allows a user to borrow $1 against rsETH, it must verify—cryptographically and in real-time—that the ETH actually exists in the Kelp vault. If the backing drops below 100%, the LTV (Loan-to-Value) for that asset instantly and automatically drops to 0.

• Why it brings users back: It removes the “Bridge Blindness.” You aren’t trusting a bridge message; you’re trusting mathematics.

3. The “Sovereign” Safety Module

Currently, Aave’s insurance (the Safety Module) relies on the AAVE token. If there is a hack, AAVE tokens are sold to cover the debt. The problem? During a hack, the price of AAVE usually crashes, making the insurance worth less exactly when you need it most.

• The Solution: Pivot the Safety Module to a Diversified Reserve. Aave should take a percentage of all protocol fees and store them in a mix of “Hard Assets” (WETH, PAXG, and stablecoins).

• The Result: Aave would have a $500M+ “War Chest” that isn’t tied to the price of its own governance token.

• Why it brings users back: It’s a “DeFi FDIC.” Knowing there is a massive vault of neutral, liquid cash waiting to cover bad debt provides the same psychological safety as a real bank.

4. Dynamic “Bridge-Risk” Oracles

Right now, Aave treats a token’s risk based on its liquidity. But as we saw, the risk was actually in the LayerZero bridge.

• The Solution: Aave should implement Bridge-Aware Risk Parameters. Every asset on Aave should have a “Bridge Health Score” calculated by third-party auditors.

• The Result: If a bridge’s security configuration changes or a validator becomes unresponsive, the supply caps on Aave would automatically shrink in real-time without needing a human to vote.

• Why it brings users back: It turns Aave into a “Smart Guard.” It monitors the infrastructure underneath the tokens so the user doesn’t have to.

[MconnectDAO]

On the putting together what is arguably one of the more methodologically rigorous cap recalibration proposals this protocol has seen. And to for the thorough breakdown the observations raised in that reply deserve to be part of the governance record here, not just noted in passing… @LlamaRisk @robtg4

[robtg4]

Hey everyone, hope all is well and appreciate the tag. Let’s get into it

@GoldETH , appreciate the thoughtfulness here — but I think you’re drawing a false dichotomy between cap management and architectural reform, and the analogies overstate the tradeoff.

The speed limit metaphor doesn’t hold. @gnarvaja’s automated supply cap updater isn’t lowering speed limits to 5 mph — it’s installing automatic braking that only activates when someone is accelerating toward a wall. Normal organic growth (legitimate deposits flowing in over hours and days) passes through with near-zero friction. The 3% headroom with hourly cadence means legitimate users functionally never notice it. The only thing that gets blocked is burst deposits — which is exactly the attack vector.

That said, your four proposals aren’t wrong — they’re just solving different problems on different timescales:

Hard Siloing — Directionally correct, and Aave is already moving this way with isolated markets (Prime, EtherFi, etc.). But full isolation fragments liquidity and increases borrowing costs for everyone. The practical path is tiered isolation — which is essentially what Aave V3 is doing with separate market instances. The more important principle here is eligibility gating: assets beyond a certain risk threshold simply shouldn’t be collateral-eligible in shared pools. Period. Siloed pools for riskier assets, ineligibility for the rest. That’s cleaner than trying to engineer safety around inherently fragile collateral types.

On-Chain PoR — This sounds right in theory, but it wouldn’t have caught the rsETH depeg in time. Chainlink PoR relies on periodic attestations — it doesn’t operate in sub-block time. By the time the oracle updates, the damage is already done: the collateral is posted, the borrows are executed, and the cascade is in motion. What you’d actually need is real-time credential attestation tied to the underlying assets — something like a proof-of-collateral registry that can invalidate borrowing eligibility before the transaction settles. That infrastructure doesn’t exist yet. And critically, you’re not removing trust from bridges — you’re just shifting it to the oracle layer with its own failure modes and manipulation surface. Which brings us back to the simpler, more effective answer: don’t let these assets serve as collateral in shared pools in the first place. Siloed pooling and eligibility gating avoid the entire problem without depending on infrastructure that doesn’t exist yet.

Diversified Safety Module — This is actually happening. Aave’s Umbrella upgrade is moving toward protocol-owned liquidity reserves denominated in the assets they protect, not just AAVE. The direction is right; the implementation is already underway.

Dynamic Bridge-Risk Oracles — Interesting, but adds oracle surface area. Every new oracle feed is a new dependency that can fail or be manipulated. The risk calculus isn’t straightforward.

The key point: @gnarvaja’s proposal and @LlamaRisk’s cap recalibration aren’t alternatives to architectural reform — they’re what you ship while the architectural work is being built. You don’t wait for the perfect seatbelt to stop driving. The supply cap updater is deployable now, requires zero core contract changes, and would have reduced rsETH exposure by 72-98%. That’s not a band-aid — that’s a materially effective control that buys time for the longer-term changes you’re describing.

Both tracks should run in parallel in My honest opinion - but to be honest the way things are looking for how community sentiment is considered in the Aave ecosystem, I’m growing less confident that these findings matter

-— Robby Greenfield | tokedex.org

[GoldETH]

no solution is acceptable unless it works for all three parties at the same time. Every previous proposal in this thread optimizes for one and creates friction for another. That is why they have not achieved consensus.

---

The Root Problem — One Sentence

A conservative ETH lender on Ethereum mainnet was exposed to a bridge vulnerability in a protocol they had never heard of, caused by a collateral listing decision they had no voice in, and had no structural guarantee they would be made whole.

Every element of that sentence needs to be fixed. This framework fixes all of them.

---

Pillar 1 — Three-Pool Architecture: Let Every Participant Choose Their Own Risk

The fundamental architectural problem was a shared pool where a conservative lender’s capital was commingled with exotic collateral they never agreed to. The fix is not better risk management of a single shared pool — it is separating pools by risk profile so that a failure in one cannot contaminate another.

Aave V4’s hub-and-spoke architecture already supports this. What is missing is a formal governance decision to implement it explicitly with binding collateral rules per pool.

Conservative Pool — for lenders who want maximum safety at lower yield

Accepted collateral: ETH, wBTC, USDC, USDT only. No bridged assets. No LRTs. No wrapped tokens with cross-chain dependencies. Full Umbrella coverage guaranteed. Yield: 2–4% APY. A failure in any other pool cannot touch this pool’s liquidity under any circumstances — enforced by the Hub credit limit architecture, not by governance promise.

Standard Pool — for lenders comfortable with established LSTs

Accepted collateral: stETH, rETH, cbBTC, and similar assets with multi-year track records. Hard concentration caps enforced on-chain. MACRO score above 500 required for borrows exceeding $500K. Yield: 4–7% APY. Partial Umbrella coverage.

High Yield Pool — for lenders who explicitly accept higher risk for higher return

Accepted collateral: LRTs, bridged assets, newer protocols. Higher yield: 8–15% APY. Lenders enter knowing and accepting the risk profile. Losses from this pool are contained within this pool only — they cannot drain the Conservative or Standard Pool under any circumstances. MACRO score above 700 required for borrows exceeding $100K.

The key principle: every lender chooses their own risk explicitly at deposit time. Nobody is ever again exposed to collateral risk they did not choose.

---

Pillar 2 — Collateral Validity Gate: Verify Backing Before Accepting

The rsETH attack succeeded because Aave accepted collateral whose backing had been compromised at the bridge layer — and had no way to detect this in real time. The price oracle showed rsETH still trading at $2,400. The backing was already broken.

Before any bridged or wrapped asset is accepted as collateral — in any pool — the protocol must be able to verify one on-chain invariant in the same transaction as the deposit:

minted supply on destination chain ≤ locked supply on source chain

If this check cannot be answered reliably on-chain — the asset is ineligible as collateral in any pool, regardless of its price, liquidity, or TVL. This is not a new oracle dependency. It is a direct query to the bridge contract itself, executed within the deposit transaction before funds are accepted.

Applied to rsETH: the moment the attacker minted 116,500 unbacked rsETH, this invariant broke. Any subsequent deposit attempt would have been rejected in the same transaction — not frozen hours later, not paused after damage was done — rejected instantly before entering the system.

Additionally: a continuous keeper monitors this invariant for every listed bridged asset. The moment it breaks for any reason — borrowing against that asset pauses automatically across all Aave deployments in the next block. No human required. No monitoring gap possible.

---

Pillar 3 — Decentralized Credit Gate: MACRO Score for Large Borrows

Deposits should remain fully permissionless — anyone can provide liquidity to any pool at any time. But borrowing is not a right. It is a credit extension by the protocol, and the protocol takes risk every time it lends. Requiring demonstrated on-chain creditworthiness for large borrows is not censorship — it is basic risk management that every functioning financial system in history has applied.

The solution must be fully decentralized. No gatekeeper. No KYC. No trusted authority. The answer already exists: Spectral Finance’s MACRO Score — a permissionless, on-chain credit scoring system that computes creditworthiness from over 150 features of on-chain history. Payment history, liquidation history, repayment behavior, credit mix, wallet age. The blockchain decides — not a human. Spectral has already backtested the MACRO Score specifically against Aave’s own borrowing data and demonstrated improved capital efficiency.

Borrow size	Requirement	Impact on legitimate users
Under $10K	None — fully permissionless	Zero friction — new users fully included
$10K — $500K	MACRO ≥ 500	Basic DeFi history — most real users qualify easily
$500K — $5M	MACRO ≥ 650	Established users — 6+ months clean history
Above $5M	MACRO ≥ 750 + DAO whitelist	Institutions — publicly listed, transparent, revocable

The obvious objection is Sybil resistance — an attacker builds unlimited fresh wallets. This objection is correct against naive per-wallet limits. But the MACRO Score is not a wallet age check. It is 150+ features of genuine on-chain behavior computed by a machine learning model. An attacker cannot fake years of legitimate DeFi activity across thousands of wallets at scale. The preparation cost and forensic visibility increase by orders of magnitude. The rsETH attacker had unlimited wallets. What they did not have — and could not fake — was verified on-chain credit history. Under this system, every fresh wallet scores approximately 300. Every borrow above $10K from a score-300 wallet is rejected. Unlimited wallets, same result.

---

Pillar 4 — Automated Real-Time Risk System: No Human Required

The rsETH crisis exposed two automated system failures: the Chaos Labs rate oracle was unmaintained at the moment of crisis, and the response window between exploit and containment was hours rather than blocks. Both failures are preventable with systems that require no human to trigger.

Automated supply cap updater — already proposed by @gnarvaja and supported unconditionally. Cap tracks actual supply plus 15% headroom in real time. No stale headroom. No single wallet fills a $7.5B cap when actual supply is $3B. This is deployable now with zero core contract changes.

Depeg circuit breaker — any collateral asset moves more than 10% from its expected value within 30 minutes, LTV drops to zero automatically and new borrowing pauses. Triggers in the next block. No governance vote required. No human needs to be awake.

Utilization early warning system — at 80% utilization, automatic rate increase activates to attract new supply. At 90%, alerts broadcast on-chain to all integrated dashboards. At 95%, new borrows pause automatically. Lenders always have time to make informed decisions before reaching 100%.

Rate oracle continuity requirement — no automated risk system should be operable without a named maintainer and a backup. The Chaos Labs exit on April 6 left the rate system unmaintained 12 days before the exploit. This must never be possible again. Governance should require a named primary and backup maintainer for every automated risk system as a condition of deployment.

---

Pillar 5 — Codified Loss Hierarchy: Decided Before Crisis, Not During One

This is the most important pillar. The technical systems in Pillars 1 through 4 reduce the probability of a crisis. But no system eliminates all risk. When something goes wrong — and eventually something will — the question of who bears losses must be answered before the crisis, not negotiated under panic with $200M of innocent deposits at stake.

I propose the following loss hierarchy be codified as a binding governance resolution — not a blog post, not a forum discussion, a formal on-chain resolution that every future crisis response must follow:

Order	Who absorbs loss	Rationale
1st	Protocol that listed the asset	Made the listing decision, earned fees from it
2nd	Umbrella stakers	Took extra yield explicitly to be first-loss backstop
3rd	DAO treasury	Protocol revenue is a protocol responsibility
4th	AAVE token holders via dilution	They govern the protocol and approved the listing
Never	Innocent lenders	No voice in listing decision, no way to assess the risk

This hierarchy is not radical. It maps exactly onto how Aave’s safety architecture was already designed to work. What is missing is the formal codification that makes it binding — not dependent on governance goodwill during a crisis when token holders have conflicting incentives.

The institutional capital watching DeFi from the sidelines — family offices, treasuries, funds — is not afraid of smart contract risk. They are afraid of the question: “what happens when something goes wrong?” This resolution answers that question permanently and makes Aave the first DeFi protocol with a formally guaranteed lender protection hierarchy. That answer alone is worth more future TVL than any yield optimization.