Aave wstETH Oracle Error: Why One Bad Cap Triggered $27M

Aave wstETH oracle error was not a hack, an oracle manipulation attack, or a market crash. On March 10, a misconfigured update to Aave’s CAPO oracle pushed the effective wstETH price about 2.85% below the valid market rate, triggering liquidations across 34 healthy accounts and about 10,938 wstETH, or roughly $26.6 million to $27.78 million depending on the pricing snapshot used.

The liquidation cascade came from Aave’s own safety layer

Rekt’s reconstruction is blunt: Aave’s anti-manipulation system misfired on the users it was built to protect. Rekt says Chaos Labs’ Edge Risk engine pushed a single parameter update on March 10, AgentHub executed it one block later, and the resulting CAPO cap left wstETH priced below reality. The governance post-mortem confirms the same mechanism at a protocol level, saying the reported wstETH/stETH exchange-rate cap fell below the currently valid market exchange rate on Ethereum Core and Prime and triggered about 10,938 wstETH in E-Mode liquidations.

This distinction matters because it changes the story from “DeFi got hacked” to “delegated automation misconfigured a live risk control.” Omer Goldberg, founder of Chaos Labs, said publicly that the incident caused a loss of 345 ETH, incurred no bad debt, and that affected users would be fully reimbursed. A later Aave governance reimbursement proposal put the gross refund figure higher, at 513.19 ETH, with a net DAO cost of 358.56 ETH after recoveries already identified. That difference is not a contradiction so much as an accounting split between user loss, liquidation flows, and funds later recovered from builders and fees.

Aave governance post-mortem

wstETH CAPO reimbursement proposal

CAPO failed because two interdependent parameters drifted out of sync

The most useful technical source here is Aave governance, not social media. The reimbursement proposal says a configuration misalignment between snapshotRatio and snapshotTimestamp caused the reported wstETH/stETH exchange-rate cap to fall about 2.85% below the actual market rate. LlamaRisk’s independent post-mortem goes further: the onchain constraint only allows snapshotRatio to increase by a maximum of 3% every three days, but the offchain risk oracle pushed a snapshotTimestamp that assumed a seven-day-old anchor while the corresponding snapshotRatio could not be updated enough in one transaction to match it. The result was deterministic, not random.

That also explains why the protocol’s contracts can all be “working as intended” while users still get liquidated incorrectly. The contracts enforced the posted oracle result and liquidation rules exactly as designed. The design problem sat one layer above: the automated system that generated the new parameters produced an internally inconsistent state transition. LlamaRisk says pre-execution simulation against a forked mainnet environment, or even a simple check that the resulting maxRatio still exceeded the live exchange rate, would have surfaced the failure before any onchain transaction was broadcast.

Rekt’s Aave incident reconstruction

BGD correlated-asset price oracle design

CAPO’s design philosophy left a narrow but real failure path

Aave introduced CAPO, the Correlated Asset Price Oracle, to guard highly correlated assets such as LSTs and stablecoins against upward manipulation. BGD Labs’ original governance explanation described it as an extra upper-price protection layer for assets like wstETH, built around a ratio provider, configurable growth assumptions, and a bounded time progression. The same design thread explicitly said the initial release prioritized upper protections first, with lower-bound handling for downward scenarios left for a following iteration because the security procedures would be simpler that way.

That context makes the March 10 incident more understandable and more uncomfortable. The system was not primarily designed to catch a harmful downward deviation created by its own parameter update path. It was designed to stop artificially accelerated upward exchange-rate growth from making collateral look too valuable. On March 10, the protection mechanism became the source of underpricing instead. This does not mean CAPO was a bad idea. It means its threat model was narrower than the operational reality of handing parameter updates to an automated delegated agent. A safety layer built around one direction of failure can still create the opposite one if update logic is brittle.

Human error was not the only problem; review architecture was too thin

The easy explanation is “someone set the wrong cap.” The harder and more useful explanation is that the system let one bad update move from offchain computation to live execution in one block. Reakt says AgentHub fired the update onchain one block after the Edge Risk engine submitted it. LlamaRisk argues that this incident shows meaningful room for improvement in how automated risk systems operating under delegated governance authority are tested, validated, and overseen. It also says other service providers could observe what landed onchain, but could not independently verify the offchain code and calibration logic that generated it.

That is the structural failure. A protocol can have good contracts, good oracle adapters, and reputable service providers, and still be too trusting of the last mile between offchain decision logic and onchain execution. If a risk agent has authority to move pricing parameters on a production lending market, then at least four things should exist before execution: a fork simulation that proves the update does not make healthy positions liquidatable, a live-state invariant check on resulting price bounds, an independent co-signer or second service provider review for sensitive markets, and a short delay window for abnormal updates. LlamaRisk explicitly proposed co-signing authority through the RiskSteward role after the event.

The reimbursement process solved trust damage, not the design problem

Aave responded quickly after the incident. Governance posts say the wstETH borrow caps on Ethereum Core and Prime were immediately reduced to 1 as a containment step, and a later governance item proposed re-enabling them after the CAPO issue was resolved. TokenLogic’s reimbursement proposal says the DAO should refund users who were erroneously liquidated, with 513.19 ETH approved for refunds and the net cost expected to decline as further recoveries came in. The Aave governance app also shows a dedicated proposal page for the reimbursement item dated March 16.

That is good governance hygiene, but it should not end the analysis. The deeper question is what automated checks should have prevented a parameter mismatch from liquidating $27 million of healthy positions in the first place. The answer is not “more monitoring” in the abstract. It is very concrete: shadow execution on a fork before broadcast, live-position impact simulation, onchain sanity guards that reject a cap below an independently sourced live ratio unless explicitly overridden, and slower execution for first-time deployments of new autonomous agents. The post-mortem itself says this was the first update pushed by the CAPO Risk Agent. First updates on production risk infrastructure should not have one-block blast radiuses.

The next signal to watch is not whether Aave covers the losses; it has already committed to that in governance and public statements. The real signal is whether delegated risk automation on Aave gets redesigned so one inconsistent parameter pair cannot again jump from offchain logic to forced liquidation before anyone has time to say no.

• Aave Governance — Post-Mortem: Exchange Rate Misallignment on wstETH Core and Prime Instances — https://governance.aave.com/t/post-mortem-exchange-rate-misallignment-on-wsteth-core-and-prime-instances/24269
• Aave Governance — [Direct To AIP] wstETH CAPO Oracle Incident User Reimbursement — https://governance.aave.com/t/direct-to-aip-wsteth-capo-oracle-incident-user-reimbursement/24275