Aave's $27M Glitch: When the Oracle Was Right and the Cap Was Wrong
On March 10, 2026, Aave's wstETH oracle on Ethereum Core and Prime returned a price that was 2.85 percent below the market. The gap lasted long enough for liquidation bots to close 34 E-Mode positions. Total liquidations: roughly 27 million dollars.
Nobody lost funds to an exploit. The users who got liquidated lost real money to a system that was working exactly as configured. That is the part that makes this one worth writing about.
There was no smart contract bug. The code did what it was told. The problem was that what it had been told to do did not match what the market was doing, because two configuration parameters had drifted out of sync.
This is an oracle misconfiguration in the classical sense. Not a missing multiplication, like Moonwell. A subtler one. The kind that only shows up when the market moves against you.
Aave's CAPO System
CAPO stands for Correlated Asset Price Oracle. It is Aave's mechanism for pricing LSTs and other "correlated" assets like wstETH, weETH, rsETH.
The design goal: an LST like wstETH is worth ETH times a ratio that grows over time as staking rewards accrue. You should not let that ratio spike due to an oracle error or a manipulation attack, because an artificially high LST price lets borrowers borrow more than they should against collateral that is not actually worth more.
The CAPO solution is a capped growth rate. It takes a snapshot ratio and a snapshot timestamp, and calculates a maximum allowed ratio at any future time based on an expected growth rate per second. If the real ratio comes in below the cap, use the real ratio. If it comes in above, use the cap.
It is a safety ceiling. In normal conditions you do not hit it.
uint256 maxAllowedRatio =
snapshotRatio * (1 + growthRatePerSec * (now - snapshotTimestamp));
uint256 usedRatio = min(realRatio, maxAllowedRatio);
The logic is conservative in the direction of caller risk. If the cap is too low, you underprice the asset. If it is too high, you overprice. Aave bet on the first direction.
Most of the time, this is fine. LSTs grow slowly. The cap is loose. Users see real prices.
What Went Wrong
The snapshot ratio and snapshot timestamp on the wstETH CAPO fell out of sync. The specifics of how are detailed in Chaos Labs' post-mortem. The practical effect: the cap was being calculated against a timestamp that no longer matched the ratio it was meant to pair with.
Result: the capped rate came in at roughly 1.1939. The actual wstETH/ETH rate at the time was roughly 1.228. That is a 2.85 percent gap.
For positions near their liquidation threshold in E-Mode (which allows extremely high LTV ratios specifically because wstETH and ETH are correlated), a 2.85 percent price drop is plenty to trigger liquidation. E-Mode exists to let users take out large loans against correlated collateral with slim margins. The slim margin is the product feature. It is also the thing that makes mispricing catastrophic.
Thirty-four user accounts got liquidated. Third-party liquidation bots captured approximately 499 ETH in liquidation bonuses. The protocol itself accrued no bad debt, which is the correct outcome from a protocol-safety perspective but not a consoling one if you were one of the 34.
Why This Class of Bug Is Subtle
This was not a missing feed. The oracle returned a number. It was not a wildly wrong number. It was 2.85 percent off.
That distance is too small to trip most sanity checks. Any reasonable bounds would expect wstETH to trade within a few percent of its mathematical ratio. 2.85 percent below would not trigger a circuit breaker unless the circuit breaker was unusually tight.
The failure was not in the oracle returning nonsense. It was in the parameters that defined what "correct" meant for the oracle. Those parameters were off, and the oracle faithfully applied them.
This is a category of bug that standard monitoring tools miss. Price feed monitors look for wild swings. Protocol monitors look for TVL anomalies. Neither of them catches "the cap parameter was snapshotted at a time that does not match the ratio it is supposed to bound." That is a deep configuration check, and it lives in the specific math of CAPO.
What Odin Scan Looks For
We catch LST-oracle configuration issues through several complementary checks.
Feed identity check. We flag cases where a feed returning an exchange rate (like wstETH/ETH) is used directly as a USD price. That is the Moonwell class. Not applicable here, but it is the most common misconfiguration.
Snapshot pair consistency. For contracts that use capped-growth oracle patterns, we check that any snapshot ratio value is paired with a timestamp sourced from the same block as that ratio. If the two are updated independently (e.g. in different transactions or by different roles), we flag the configuration pattern as high risk for drift.
Growth rate bounds. We flag growth rates that are too tight relative to the observed historical volatility of the feed. A growth rate that just barely contains normal market noise is a growth rate that will trigger during any unusual event.
E-Mode parameter sanity. High LTV E-Mode configurations combined with oracles that have tight caps are a high-leverage, low-margin combination. We flag this specific interaction and recommend stress testing with historical mispricing scenarios.
For the wstETH CAPO setup as it stood on March 10, Odin Scan would have flagged the snapshot update mechanism during a review of how the CAPO parameters are administered. Any system where snapshot ratio and timestamp can be updated separately is a system where they can drift.
The Upstream Fix
Chaos Labs responded quickly. They reduced wstETH borrow caps on both Aave Core and Prime to 1, effectively freezing new borrowing against wstETH. They manually re-aligned the snapshot parameters. The oracle returned to the correct value.
They then announced a compensation plan: 141.5 ETH recovered from the incident plus up to 345 ETH from the DAO treasury, earmarked for the 34 affected users.
The response was fast, transparent, and materially addressed user harm. If you have to suffer an oracle incident, the Chaos Labs style of response is the one you want. Other protocols could learn from it.
What the response did not address is the structural issue: CAPO as a design has a coupled-parameter surface that can drift. The fix was to re-align. The durable fix is to make drift impossible by enforcing that snapshot ratio and timestamp are always read together from a single atomic source.
What This Means for Other LST Integrations
Anyone integrating LSTs as collateral on a lending protocol should read the Aave incident as a specific warning about their own oracle setup.
Do you use CAPO or a CAPO-like capped growth oracle? If yes, audit how the snapshot parameters are updated. Are they always paired? What happens if one updates and the other does not? What is the blast radius of a 2 or 3 percent mispricing in your loan book?
Is your LST market in E-Mode or a high-LTV isolated pool? The higher the leverage ratio, the smaller the mispricing needed to cause liquidations. E-Mode at 94 percent LTV needs less than 3 percent of mispricing to force liquidations. Your monitoring should be at least that sensitive.
Do you have circuit breakers? Not just on prices, on price gaps. If your oracle price deviates from a secondary source by more than some defined threshold, liquidations should pause automatically while humans investigate. The Aave incident could have been a pause instead of 499 ETH of liquidation bonuses.
Are your oracle parameter changes going through a timelock? CAPO parameters are critical inputs. They should change only through governance, only with a timelock, and only with documented snapshot-time alignment. If your ops team can rotate these parameters without a public proposal, that is a Drift-shaped risk.
The Takeaway
Oracle misconfigurations are not always as dramatic as the Moonwell cbETH/ETH direct-as-USD bug. Sometimes they are a 2.85 percent cap drift that bleeds 27 million out of 34 innocent users over an afternoon.
The difference between those two bugs is the visibility. A 50 percent off-by-feed error is visible to anyone who reads the oracle name. A 2.85 percent cap drift is only visible to someone who understands the CAPO math and can check whether two specific parameters are in sync.
Automated scanning has to catch both. The dramatic bug is the easier one. The subtle bug needs a tool that knows specific oracle designs and can reason about how their parameters interact.
Odin Scan catches both. We have specific heuristics for capped oracle patterns, LST/LRT feed identity, and E-Mode configuration sanity. These run on every PR, every governance proposal, every deployment. The value of catching a subtle oracle drift before it hits users is exactly the difference between 27 million in user liquidations and a fixed config that nobody noticed.
If you operate a lending protocol with LST collateral, we should talk. Start a free Odin Scan trial and get an oracle configuration review as part of your first scan.
For direct support or a custom review of your oracle setup: support@odinscan.ai.
Sources: Chaos Labs post-mortem via The Block, CoinDesk coverage, BeInCrypto analysis, DEV Community technical breakdown.