A misconfigured Oracle system in Aave triggered $27 million in forced liquidations on March 10, undervaluing wrapped staked Ether by 2.85% against its actual market rate.
According to the post-mortem by Chaos Labs, the CAPO oracle error caused Aave V3 Ethereum Core and Prime instances to apply an exchange rate of roughly 1.1939 wstETH-per-ETH when the live onchain rate was approximately 1.228, enough of a gap to push 34 high-leverage E-Mode positions below their liquidation thresholds automatically.
It resulted in the liquidation of 10,938 wstETH. The protocol says it incurred no bad debt and is moving to compensate all affected users.
The Damage: 34 Users, $27M in Liquidations, and 499 ETH in Bot Profits
The oracle glitch liquidated 34 users, with the total volume reaching $27 million in wstETH positions.
Liquidation bots moved quickly, capturing 499 ETH in bonuses, approximately $1.2 million, by executing against positions that should not have been eligible for liquidation at that moment.
Aave founder and CEO Stani Kulechov confirmed in a Wednesday post that the protocol generated no bad debt from the incident.
Of the 499 ETH that went to liquidators, Aave recaptured 141 ETH ($285,000) through BuilderNet refunds and an additional 13 ETH in liquidation fees.
Those recovered funds will flow directly to affected users as compensation, with DAO treasury funds covering any remaining shortfall up to the full 345 ETH identified as the excess liquidation windfall.
Lido contributors confirmed the event had no connection to wstETH or the Lido staking protocol itself; the issue originated entirely within Aave’s oracle configuration layer.
With Ethereum price defending the $2,000 support zone around the time of the incident, the liquidation values were amplified by the broader market context for ETH-denominated collateral.
Discover: The best pre-launch crypto sales
Chaos Labs Confirms Aave CAPO Oracle Misconfiguration: Here Is What They Found
Chaos Labs, Aave’s external risk management partner, confirmed the incident stemmed from what it described as an onchain configuration misalignment under differing onchain update constraints, not a design flaw in the CAPO system or in the core oracle infrastructure of Aave.
The team emphasized that Chaos Risk Oracles had processed over 1,200 payloads and more than 3,000 parameters across Aave markets without incident prior to March 10.
Chaos Labs quickly contained the situation: borrow caps on wstETH were reduced immediately, and snapshot parameters were manually realigned to restore oracle accuracy. Kulechov noted in his public statement that the configuration issue had already been remediated by the time the post-mortem was published, and praised the team’s response speed in limiting broader DeFi risk contagion.
The Aave governance post-mortem marks this as the first operational failure in CAPO’s deployment history on Aave V3, despite more than a year of live operation across multiple markets.
What Traders and Aave Users Are Watching Next
The immediate focus is on the full reimbursement timeline. Aave DAO service providers are finalizing compensation for all 34 affected users following the initial 141 ETH refund via BuilderNet, with a formal governance announcement expected shortly.
Beyond compensation, governance teams are conducting a broader review of CAPO parameters across all Aave markets, updating stale snapshots and building out enhanced monitoring to flag rate divergences before they reach liquidation-threshold proximity.
Whether that review produces binding parameter update standards or remains advisory is the governance question to watch.
If the DAO formalizes automated CAPO sync requirements and publishes updated risk oracle documentation, the incident may ultimately strengthen Aave’s operational credibility. If the review stalls at the discussion stage, the reputational cost will compound the financial one.
Discover: The best new cryptocurrencies
The post Aave Oracle Glitch Causes $27M Liquidations: CAPO Misconfiguration Confirmed appeared first on Cryptonews.
Credit: Source link
