Supportive of rETH specifically — Rocket Pool is one of the most thoughtfully designed staking protocols in the ecosystem. But I want to use this proposal to argue for something broader: a systematic infrastructure stack audit framework for every new LST/LRT listing on Aave, starting now.
The rsETH incident gave us an expensive lesson in what happens when collateral risk assessment stops at the asset layer and ignores the infrastructure beneath it. We shouldn’t repeat that mistake.
rETH Through the Collateral Risk Stack
When evaluating any staked derivative as collateral, I think about risk in layers:
Layer 1 — Validator/Staking Risk: What happens if validators get slashed?
- rETH: Distributed across permissionless node operators with individual 4 ETH bonds (post-Saturn 1). Slashing risk is diversified, not concentrated. A single operator failure doesn’t cascade. This is structurally strong.
Layer 2 — Protocol Risk: What happens if Rocket Pool itself has a bug?
- Mature protocol. Battle-tested contracts. Saturn 1 upgrade completed. Saturn 2 (megapools) is upcoming but not a dependency for the current rETH mechanism. Risk exists but is well-understood and has survived multiple market cycles.
Layer 3 — Oracle/Price Feed Risk: How does Aave know what rETH is worth, and what can break that?
- This is where rsETH failed catastrophically. Kelp’s price feed depended on a single DVN (Decentralized Verifier Network) across a LayerZero bridge — one entity controlling the price signal for a multi-billion dollar collateral asset. When that was compromised, the price feed became the attack vector.
- For rETH: What oracle infrastructure will the Aave V4 Spoke use? Is there Chainlink redundancy? Is there a TWAP fallback? Is there any bridge dependency in the price feed path? This needs explicit documentation before listing.
Layer 4 — Cross-Chain/Bridge Risk: Does the asset travel across chains, and what trust assumptions does that introduce?
- rETH on Ethereum mainnet: no bridge dependency. rETH on L2s: depends on the bridge. If this Spoke serves cross-chain rETH, the bridge security model matters enormously. rsETH’s entire exploit originated in this layer.
What rETH Gets Right (That rsETH Didn’t)
The structural comparison is worth making explicit:
Decentralization of the operator set. Rocket Pool has thousands of permissionless node operators. Kelp relied on centralized infrastructure with a single DVN as a critical dependency. When you have one point of failure in your trust chain, you don’t have decentralization — you have a single point of failure with extra steps.
No rehypothecation chain. rETH represents a direct claim on staked ETH. rsETH was a liquid restaking token — a derivative of a derivative, adding layers of smart contract risk and infrastructure dependency at each level. Simpler is more auditable.
Mature oracle infrastructure. rETH has established Chainlink price feeds with years of operational history. New assets inherently carry more oracle risk because the feed infrastructure hasn’t been stress-tested across market conditions.
The Proposal: An Infrastructure Stack Audit Standard
Here’s what I’d like to see governance adopt — not just for rETH, but as a prerequisite for any future staked/liquid derivative listing:
1. Dependency Chain Documentation. Before listing, the proposer must map every infrastructure dependency from the underlying asset to Aave’s risk engine. Every smart contract, every oracle, every bridge, every external service in the path. No exceptions.
2. Single Point of Failure Analysis. For each dependency, identify: is there redundancy? What happens if this component fails? What’s the blast radius? The rsETH incident would have been caught by this analysis — a 1-of-1 DVN controlling a price feed for billions in collateral is a textbook single point of failure.
3. Degradation Scenarios. Not just “what if it breaks” but “what if it degrades?” Oracle staleness, partial bridge failures, temporary loss of consensus — the gray-zone failures that don’t trigger circuit breakers but still create exploitable conditions.
4. Cross-Chain Governance Coordination. If the asset involves any cross-chain component, document: which chain’s governance controls which piece? What happens if governance decisions conflict? Who can freeze what, and how fast?
rETH likely passes all of these tests. That’s exactly why it’s the right asset to establish the standard with — it demonstrates that good assets can meet rigorous requirements, and sets the bar for everything that follows.
Recommendation
Support listing rETH. It’s well-designed, well-decentralized, and structurally different from the assets that have caused problems.
But make it conditional on publishing the full infrastructure dependency map, and adopt that requirement as standing policy for all future listings. The rsETH incident cost the ecosystem hundreds of millions. The cost of an infrastructure audit is a rounding error by comparison.
-– Robby Greenfield | tokedex.org