Aave experienced a temporary oracle malfunction on its Ethereum Core and Prime instances on March 10, 2026, resulting in approximately $26 million worth of wstETH positions being unfairly liquidated across 34 accounts.
The incident stemmed from a misconfiguration in the Correlated Asset Price Oracle system, which caused the oracle to report a capped exchange rate below the actual market rate, triggering erroneous E-Mode liquidations with no bad debt accrued to the protocol.
Incident Overview and Impact
Scale of Liquidations
The oracle glitch resulted in the liquidation of approximately 10,938 wstETH across 34 accounts, with total unfair liquidations valued at around $26 million. Third-party liquidators captured approximately 499 ETH in gains from the incident, including liquidation bonuses and value realized through the exchange rate deviation.
According to the post-mortem from Chaos Labs, Aave’s primary risk management provider, the protocol did not incur any bad debt from the incident. However, affected users faced significant losses as their positions were liquidated due to the artificially depressed oracle price.
Timeline of Events
The issue occurred on March 10, 2026, affecting Aave’s Ethereum Core and Ethereum Prime instances. Chaos Labs and BGD, the infrastructure partner behind Aave’s codebase, intervened quickly to contain further risk and restore correct oracle values.
Technical Root Cause
CAPO Oracle Mechanism
The Correlated Asset Price Oracle is designed as a safety mechanism to protect lending protocols from oracle-driven inflation attacks and donation-style exploits. CAPO places a deterministic, time-weighted upper bound on the exchange rate between a yield-bearing asset like wstETH and its base asset like stETH.
The system uses three key parameters: a snapshot ratio serving as the reference exchange rate, a snapshot timestamp associated with that reference, and a maximum yearly ratio growth percent that caps allowable growth. The maximum permitted ratio is computed from the snapshot ratio plus a time-based growth allowance based on elapsed time since the snapshot.
Configuration Mismatch
The incident was caused by an inconsistency between the configured snapshot ratio and the snapshot timestamp used for CAPO. Chaos Labs’ offchain process determined that the snapshot ratio should be updated to approximately 1.2282, corresponding to the exchange rate 7 days earlier.
However, the snapshot ratio parameter is subject to an onchain constraint: it can only be increased by 3 percent every 3 days. Because the previously configured snapshot ratio was approximately 1.1572, it was not possible to set it to 1.2282 in a single update. Instead, the ratio could only be increased to approximately 1.1919.
At the same time, the snapshot timestamp was set to the value corresponding to 7 days earlier, as intended by the offchain algorithm. This created a mismatch where the timestamp assumed a 7-day-old anchor, but the ratio was not actually updated to the 7-day-old exchange rate.
Resulting Oracle Deviation
The CAPO formula extrapolated growth from a reference point that was too low, calculating a maximum exchange rate of roughly 1.1939—well below the actual market rate of approximately 1.228. This lower CAPO-derived value overrode the existing exchange rate used by the protocol, producing an effective downward move of around 2.85 percent.
That artificial decrease triggered liquidations, particularly in E-Mode, affecting positions with a health factor lower than 1.0288. The root cause was differing update constraints at the smart contract level: the snapshot ratio was rate-limited while the snapshot timestamp was not, causing them to fall out of sync.
Immediate Response and Remediation
Containment Actions
Following the incident, Chaos Labs and BGD took immediate steps to contain further risk:
-
Temporarily reduced wstETH borrow caps to 1 on Aave Core and Aave Prime to minimize additional exposure
-
Manually aligned the snapshot ratio parameter with the current snapshot timestamp reference window through Risk Steward intervention
-
Restored the oracle price to its true value by bringing configured onchain parameters back into a consistent state
Following the reversion, the team proposed reinstating wstETH borrow caps to their original levels of 180,000 on Ethereum Core and 70,000 on Ethereum Prime.
Recovery of Funds
During the incident, Aave recaptured 141.5 ETH of liquidation bonus revenue through BuilderNet refunds, in addition to roughly 13 ETH in liquidation fees. These recovered funds will be used to compensate impacted users who were liquidated as a result of the incident.
Active work is ongoing to contact relevant ecosystem players to further recoup possible liquidation-linked revenue. No more than 345 ETH will need to be compensated from the DAO treasury.
Compensation Plan
Affected Users
The incident impacted approximately 34 accounts, with total unfair liquidations estimated at around $26 million. Third-party liquidators made approximately 499 ETH worth of gains from the glitch.
Reimbursement Process
A compensation plan is underway using 141.5 ETH recovered from the incident and up to 345 ETH from the DAO treasury to reimburse affected users. The Aave DAO service providers are finalizing the reimbursement plan and will publish it shortly.
Notably, Aave has already recaptured 141 ETH of liquidation bonus revenue through BuilderNet refunds, which will be used to partially compensate affected users.
CAPO System Background
Purpose and Design
CAPO was introduced as a safeguard against inflation attacks and oracle manipulation. The system is designed to protect lending protocols from scenarios including compromised EOAs controlling oracle inputs, centralized oracle dependencies, contract upgrade vulnerabilities, and donation attacks or exchange-rate manipulation.
Risk Oracles have been operating for over a year, streaming more than 1,200 payloads for approximately 3,000 parameters with zero incidents prior to this event. The CAPO configuration operates as a separate defense mechanism to bolster protocol security.
Official Statement
Chaos Labs founder Omer Goldberg provided detailed analysis of the incident on X, explaining that the issue stemmed from smart contract-level constraints rather than a flaw in the underlying CAPO or offchain risk oracle design. The onchain configuration misalignment under differing update constraints led the snapshot ratio and snapshot timestamp to become misaligned.
FAQ: Aave Oracle Incident
Q: What caused the Aave oracle glitch?
A: The incident resulted from a misconfiguration in the Correlated Asset Price Oracle system. An inconsistency between the snapshot ratio and snapshot timestamp—caused by differing onchain update constraints—led CAPO to calculate a maximum exchange rate below the actual market rate, triggering unfair liquidations.
Q: How many users were affected and what was the total loss?
A: Approximately 34 accounts were impacted, with total unfair liquidations valued at around $26 million. Roughly 10,938 wstETH was liquidated during the incident.
Q: Will affected users be compensated?
A: Yes. A compensation plan is underway using 141.5 ETH recovered from the incident and up to 345 ETH from the DAO treasury. The Aave DAO service providers are finalizing the reimbursement plan to be published shortly.
Q: Did Aave incur any bad debt from the incident?
A: No. The protocol did not accrue any bad debt. However, third-party liquidators captured approximately 499 ETH in gains, including liquidation bonuses and value from the exchange rate deviation.
Q: What immediate actions were taken to resolve the issue?
A: Chaos Labs and BGD temporarily reduced wstETH borrow caps, manually aligned the snapshot ratio with the timestamp, and restored the oracle price to its true value. Borrow caps are being proposed for reinstatement to original levels.
