[Discussion] Post-rsETH Post-Mortem: Evolving Our Risk Framework & Prioritizing Security Over TVL

Risk General
1

The rsETH situation left a mark. Not just on the numbers, but on how I think about what we’re actually building here.

Our emergency response worked, fine. But that’s almost beside the point. The fact that we got there at all is the problem. Same story we’ve seen before with CRV. The DAO absorbs the hit, we patch things up, and then one year later we’re having the same conversation with a different asset.

I don’t want to keep having this conversation.

What’s been bugging me is that we’ve been evaluating collateral assets as if liquidity and volatility data tell the whole story. They don’t. A token can have great volume, tight spreads, decent market depth; and still be sitting on a contract architecture that’s one edge case away from chaos. rsETH taught us that again.

I think most of the community would rather have a smaller, cleaner TVL than an inflated one with hidden bombs in it.

I’d love clear answers on how we are moving forward:

@LlamaRisk

  • Evaluation Hard Gates: When evaluating a new asset, at what stage does smart contract robustness, bridge security, and overall architecture become a hard gate? Does this happen before even looking at market metrics?
  • Security Scoring: Is there (or will there be) a security score or red-flag checklist strong enough to say “no” to complex LRTs, regardless of their yield or potential TVL?

@AaveLabs

  • Automated Safeguards: Are you building automated circuit breakers that could have flagged protocol-level anomalies in rsETH before full integration?
  • Exploit Mitigation: Specifically, are there new mechanisms being designed to prevent someone from dumping massive garbage collateral and instantly borrowing huge amounts of clean assets (like the $200M+ wETH that was pulled) without raising immediate red flags?

Thanks for your time.

4 Likes
2

So here are the main views I have with this post:

  • Conservative View: Aave should return to its roots as a protocol for blue-chip assets (ETH, WBTC, USDC). By excluding complex LRTs, Aave secures its position as the safest place for institutional capital, even if it loses “Degen” market share to more aggressive competitors. (Which I favor most, since this incident has proven that Aave is too large to fail)
  • Progressive View: DeFi thrives on composability. Instead of banning complex assets, the protocol should develop more sophisticated risk engines that can handle these assets without endangering the entire core market. I think Aave v4 is implementing this, if it hasn’t already
  • The Governance View: The recurring nature of these incidents (CRV, rsETH) suggests a fatigue with whack-a-mole risk management. There is a push for a rigid, code-enforced risk manifesto that removes discretionary human error from the onboarding process.

To put this bluntly, Aave needs to adopt a posture closer to traditional banking regulation where security and solvency are non-negotiable hard gates, regardless of the potential for profit.

2 Likes
3

@ApuMallku, @litostarr — I’ve been thinking about this a lot since the rsETH incident, and I’ve been active in both the Post-rsETH Collateral Framework ([TEMP CHECK] Post-rsETH Collateral Framework: Tier-Based LTV Reductions and Wrap-Depth Ineligibility Limits) and Risk Firewalls ([TEMP CHECK] Risk Firewalls: Tier-Based Isolation & Liquidity Silos) threads. Let me tie some of those ideas together here.

THE CORE PROBLEM: We’ve been treating market metrics (liquidity depth, volume, spread tightness) as sufficient proxies for collateral safety. They aren’t. rsETH had perfectly adequate market data right up until the moment it didn’t. CRV had the same profile. The pattern is that market-metric screening catches assets that are obviously bad, but lets through assets that are structurally fragile — and those are the ones that actually blow up in size.

ON HARD GATES — YES, THEY NEED TO EXIST, AND THEY NEED TO BE SEQUENTIAL:

The evaluation pipeline should look something like:

  • Gate 1: Architecture audit. Contract complexity, upgrade mechanisms, oracle dependencies, bridge exposure, wrap depth. If an asset requires more than one layer of trust assumptions beyond the base chain, it gets flagged for enhanced scrutiny before anyone even looks at market data. This should be a documented checklist with binary pass/fail criteria, not a judgment call.

  • Gate 2: Dependency mapping. What breaks if a dependency fails? For rsETH, the question was: what happens if the underlying staking/restaking layer has an edge case? That question should have a concrete answer before listing, not after the $200M+ in wETH has already been pulled.

  • Gate 3: Market metrics. Only after Gates 1 and 2 are passed should liquidity, volume, and volatility even enter the conversation.

Right now, the order is roughly reversed. Market data is the first thing evaluated because it’s the easiest to quantify. That needs to flip.

ON @LITOSTARR’S THREE VIEWS:

I understand the conservative position, and the instinct is right — Aave’s existential value proposition is safety, full stop. But I think the binary between “blue-chips only” and “list everything with better risk engines” is a false choice. The answer is tiered exposure with hard isolation:

  • Tier 1 (core): ETH, WBTC, major stablecoins. Shared liquidity pool, high LTVs, the Aave everyone trusts.
  • Tier 2 (established derivatives): stETH, rETH, cbETH — single-wrap LSTs with years of battle-testing. Moderate LTVs, still in the shared pool but with tighter parameters.
  • Tier 3 (complex/novel): LRTs, multi-wrap assets, newer protocols. Isolated pools. Lower LTVs. Supply caps enforced on-chain. If they blow up, the blast radius is contained to that silo.

This is basically what I proposed in the Collateral Framework TEMP CHECK, and it lets Aave serve both institutional capital (Tier 1 safety) and DeFi-native users (Tier 3 access) without either group threatening the other.

ON AUTOMATED CIRCUIT BREAKERS:

ApuMallku’s question to AaveLabs about automated safeguards is the right one. Specifically, what I’d want to see:

  1. Oracle deviation triggers. If a collateral asset’s price moves more than X% from its peg/expected value within Y blocks, borrowing against it pauses automatically. No governance vote required, no emergency multisig delay.

  2. Withdrawal velocity monitoring. The $200M+ wETH drain should have triggered alerts and potentially automatic supply-side freezes well before manual intervention was needed. If net outflows from a specific collateral market exceed a threshold within a time window, circuit breaker activates.

  3. Collateral concentration limits enforced at the smart contract level, not just as governance-set supply caps that require a vote to change. Dynamic caps that tighten as utilization increases.

The governance view litostarr raised — code-enforced risk manifesto — is where this all converges. The recurring pattern (CRV, rsETH) happens because the current process depends too much on discretionary human assessment at the listing stage and manual intervention at the crisis stage. Both need to shift toward automated, on-chain enforcement.

The DAO’s emergency response to rsETH was competent. But competent emergency response to a preventable event is not the standard we should be aiming for.

2 Likes