Aave CAPO Oracle Incident: What Happened With the wstETH Liquidations
Recently, Aave experienced a technical incident involving the CAPO risk oracle that resulted in a series of unintended liquidations affecting wstETH positions. While the protocol itself did not incur bad debt, a number of users with otherwise healthy positions were liquidated due to a temporary mispricing in the oracle system.
This article breaks down what happened, why it occurred, and how the protocol responded.
Overview of the incident
A misconfiguration in the CAPO oracle system caused the effective wstETH/stETH exchange rate used by Aave to drop by roughly 2.85% below the actual market rate.
This artificial decrease triggered liquidations, particularly in E-Mode positions, where leverage assumptions rely on a strong correlation between assets such as wstETH and ETH.
Key figures from the incident:
Approximately 10,938 wstETH liquidated across 34 accounts
Around $26M in liquidation volume
Roughly 499 ETH captured by liquidators through bonuses and exchange-rate deviation
No bad debt accrued by the protocol
Although liquidators initially captured significant value, Aave has already recaptured about 141 ETH through BuilderNet refunds, in addition to approximately 13 ETH in liquidation fees, with the recovered funds intended to compensate affected users.
Understanding CAPO and its role
The incident involved CAPO (Correlated Asset Price Oracle), a protection framework designed to prevent manipulation attacks involving correlated assets.
CAPO places a deterministic upper bound on the exchange rate between yield-bearing assets and their underlying asset.
For example:
wstETH → stETH
This mechanism helps prevent scenarios where attackers artificially inflate exchange rates to create unbacked borrowing power.
The system relies on three main parameters:
snapshotRatio – reference exchange rate
snapshotTimestamp – time associated with that reference
maxYearlyRatioGrowthPercent – maximum annualized growth allowed
From these inputs, CAPO computes the maximum permitted exchange rate, allowing normal yield growth while rejecting abnormal spikes.
What went wrong
The root cause of the incident was a misalignment between the snapshot ratio and the snapshot timestamp used by the CAPO oracle.
The off-chain risk engine determined that the snapshot ratio should be updated to approximately:
1.2282
However, an on-chain constraint limited how quickly the snapshot ratio could increase.
Specifically:
The ratio can only increase 3% every 3 days
Since the previous on-chain value was about:
1.1572
the system could only increase it to:
1.1919
in the first update.
At the same time, the snapshot timestamp was already updated to reflect a 7-day reference window, assuming the full ratio update had occurred.
This created an inconsistency:
The timestamp assumed a 7-day reference
The ratio was only partially updated
As a result, CAPO computed a maximum allowed exchange rate of about 1.1939, which was below the actual market exchange rate (~1.2285).
Because CAPO enforces the upper bound, the oracle overrode the correct price with the lower capped value, effectively reducing the price used by the protocol by around 2.85%.
Why liquidations happened
The artificially lower exchange rate made wstETH collateral appear less valuable.
Positions that previously had a health factor above 1 suddenly dropped below the liquidation threshold.
In E-Mode, where liquidation thresholds are tighter due to assumed asset correlation, this effect was amplified.
Positions with a health factor below approximately 1.0288 became eligible for liquidation.
Liquidators were able to capture value in two ways:
Standard liquidation bonuses
Profits from the temporary oracle mispricing
Timeline of events
The configuration change originated from an automated risk recommendation generated by an off-chain risk engine.
The update process followed this flow:
Risk recommendation generated off-chain
Update proposal pushed on-chain
Execution handled automatically by an agent system using Chainlink Automation
However, due to the ratio update constraint on-chain, the intended configuration could not be fully applied in a single step.
This resulted in the ratio and timestamp drifting out of alignment, which produced the incorrect oracle value.
Once the issue was identified, the system was corrected through a manual intervention that realigned the parameters.
Immediate mitigation steps
To prevent further exposure while the system was corrected, the following actions were taken:
Borrow cap temporarily reduced
The borrow cap for wstETH was reduced to 1 token on the affected Aave instances:
Ethereum Core
Ethereum Prime
This effectively halted new borrowing activity involving the asset.
Oracle parameters corrected
The snapshot ratio and timestamp were manually aligned to restore the correct price computation.
Borrow caps restored
Once the oracle was fixed, governance proposed restoring the original caps:
Ethereum Core: 180k wstETH
Ethereum Prime: 70k wstETH
Recovery and compensation
Efforts to recover funds extracted during the incident are ongoing.
So far:
141 ETH recovered via BuilderNet refunds
13 ETH collected through liquidation fees
Recovered funds will be used to compensate affected users.
The remaining compensation, estimated at no more than 345 ETH, will be covered by the Aave DAO treasury if necessary.
Additional efforts are underway to recover further liquidation-linked revenue from ecosystem participants.
Key takeaways
This incident did not involve a protocol exploit or security breach. Instead, it resulted from a configuration mismatch between on-chain constraints and off-chain risk engine assumptions.
Important observations:
CAPO itself functioned according to its design
The issue emerged from parameter misalignment during updates
The protocol remained solvent and incurred no bad debt
A large portion of extracted value is already being recovered for affected users
Final thoughts
Oracle systems for correlated assets are designed to protect lending protocols from manipulation attacks. However, they also introduce operational complexity, particularly when off-chain automation interacts with on-chain constraints.
This incident highlights how small configuration inconsistencies in risk infrastructure can propagate into large market effects, even when the core protocol mechanisms remain secure.
The protocol has since reverted to the correct oracle configuration and continues to coordinate compensation for affected users.