wstETH Chaos Labs Risk Oracle Failure

Last update: March 10, 2026, 19:45 UTC Executive Summary On March 10, 2026, Chaos Labs’ newly deployed CAPO (Correlated Asset Price Oracle) Risk Agent pushed its first parameter update to the wstETH/stETH exchange rate cap adapter on Ethereum mainnet. The update, executed at block 24626860 (approximately 11:46 UTC) via transaction [0x32c641...5a1e](https://etherscan.io/tx/0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e), contained an internal risk oracle error between the exchange rate reference and the dynamic cap calculation. This wrongful update of the SnapshotRatio caused the CAPO adapter to report a wstETH/stETH exchange rate below the actual internal exchange rate, artificially depressing the wstETH price reported by the Aave Oracle by approximately 2.84%. This was the very first update pushed by the CAPO Risk Agent, whose authorization via governance AIP had passed only approximately 2 hours prior. The mispriced oracle triggered 47 liquidations across both the Aave V3 Core and Prime markets between approximately 11:46 UTC and 11:48 UTC. Liquidators covered approximately $26.6 million in WETH debt and seized approximately $27.6 million in wstETH collateral. The total borrower damage attributable to the oracle error amounts to approximately $1.03 million, composed of two distinct layers: $760,806 in excess collateral seized due to the depressed oracle price and $266,989 in liquidation bonuses on positions that would not have been liquidatable at the correct price. The issue was resolved at 15:53:59 UTC (block 24628089) when the oracle price was corrected via the Risk Stewards (BGD Labs and Chaos Labs), approximately 4 hours and 8 minutes after the faulty update. Source: LlamaRisk, March 10, 2026 This report renews the call for full transparency from Chaos Labs regarding the root cause, agent decision logic, and validation procedures that failed. It further underscores that the current model, which involves limited operational oversight over mission-critical dependencies, is structurally insufficient. Effective oversight requires LlamaRisk to have enforceable checks and balances, including RiskSteward co-signing authority and a mandatory pre-execution review, built into the operational framework. We are calling for a pause on any further implementation of Risk Oracles and a thorough review of those currently in use, especially the CAPO Risk Agents live for other CAPO-protected assets on Aave Core and Prime markets. Background: CAPO and the Risk Agent The Correlated Asset Price Oracle, or CAPO, is a wrapper mechanism designed by BGD Labs to protect Aave from sudden spikes in correlated asset exchange rates. For assets like wstETH whose price is derived from an underlying exchange rate against stETH (and, by extension, ETH), the oracle computes a maximum allowed ratio based on a stored snapshot and a configurable growth rate. Specifically, the adapter computes: text{maxRatio} = text{snapshotRatio} + text{growthPerSec} times (text{blockTimestamp} - text{snapshotTimestamp}) If the current market ratio exceeds this maximum, the adapter “caps” it and returns the lower, capped value. In July 2025, Chaos Labs proposed Dynamic Calibration of CAPO Parameters via Risk Oracles, an ARFC to automate updates to the CAPO’s snapshotRatio, snapshotTimestamp, and maxYearlyRatioGrowthPercent parameters through their Risk Oracle infrastructure. The AIP authorizing on-chain deployment executed on the morning of March 10, 2026, and the Risk Agent’s first-ever parameter push followed approximately two hours later. Timeline of Events The sequence began with the execution of the AIP authorizing the CAPO Risk Agent deployment on March 10, 2026. Approximately two hours later, at block 24626860 (11:46 UTC), the agent’s first transaction executed on-chain. The triggering transaction (0x32c641…5a1e) updated the snapshot parameters of the wstETH CAPO adapter: Source: Chaos Labs Oracles Dashboard, March 10, 2026 At block 24626859, one block before the update, the Aave Oracle reported wstETH at $2,534.76 and WETH at $2,062.71. At block 24626860, immediately after the update, wstETH dropped to $2,462.77 while WETH remained unchanged at $2,062.71, a sudden 2.84% depression in the reported wstETH price. The first liquidations began appearing immediately in the same block (at approximately 11:46 UTC) as aggressive LST looping positions that had been hovering near their liquidation thresholds were pushed below the threshold by the artificial price depression, and as liquidation bots identified and acted upon the newly liquidatable positions. Over the next 2 minutes, 47 liquidation events occurred: 20 on the Core market and 27 on the Prime market. Every affected position involved wstETH collateral against WETH debt in E-Mode, which carries a 1% liquidation bonus. At 13:13 UTC, Chaos Labs internally confirmed that all Risk Oracle updates had been paused, and at 14:11 UTC further confirmed that the root cause had been identified (not known to us at the time of writing). The full reversion of the incorrect CAPO parameter update landed at 15:53:59 UTC (block 24628089), restoring the price to $2,551.25, slightly above the original $2,534.76 due to natural ETH price movement over the intervening four hours. In total, the oracle reported a depressed wstETH price for approximately 4 hours and 8 minutes. Root Cause Analysis The CAPO adapter enforces a ceiling on the wstETH/stETH exchange rate by comparing the live market ratio against a dynamically computed maximum. The maximum is derived from a stored snapshot ratio, a stored snapshot timestamp, and a constant growth rate per second. When the Risk Agent pushed its first update, it set a new snapshot ratio and snapshot timestamp. However, the snapshot timestamp did not correctly match with the actual snapshot ratio at the snapshot timestamp. Concretely, the cap formula: text{maxRatio} = text{snapshotRatio} + text{growthPerSec} times (text{blockTimestamp} - text{snapshotTimestamp}) produced a value lower than the current market exchange rate. This meant the isCapped() Check returned true, and the adapter returned a suppressed exchange rate rather than the actual internal exchange rate. Since the Aave Oracle for wstETH derives its USD price by multiplying this exchange rate by the ETH/USD price feed, the entire wstETH price was depressed by the capping error. At block 24626859 (before the update), isCapped() returned false, and the adapter faithfully reported the market exchange rate. At block 24626860 (after the update), isCapped() returned true, and the adapter returned a ratio that was approximately 2.84% below the true market value. The chart below illustrates the mechanism: the blue line (getRatio) represents the actual wstETH/stETH exchange rate reported by the adapter, while the red dashed line (maxAllowedRatio) represents the dynamically computed ceiling, based on the underlying CAPO parameters: Source: LlamaRisk, March 10, 2026 Impact Assessment Borrowers suffered two distinct layers of loss from the oracle error. The first layer consists of the liquidation bonuses extracted from positions that should never have been liquidated. Health factor analysis reveals that every liquidated user had a health factor above 1.0 at block 24626859 (before the CAPO update) and was pushed below 1.0 solely by the artificial price depression at block 24626860. For these users, the full 1% liquidation bonus (totaling approximately $266,989 across all 47 events) represents a loss entirely attributable to the oracle error. The 10% protocol fee ($27,307) is carved from this bonus and does not represent additional borrower cost; it merely determines how the bonus is split between liquidators (90%) and the Aave treasury (10%). The second layer is the seizure of excess collateral. Because the Aave liquidation formula computes collateral seized as text{collateral} = frac{text{debtToCover} times P_{text{WETH}}}{P_{text{wstETH}}} times 1.01 a lower P_{text{wstETH}} means more wstETH is seized for the same amount of WETH debt repaid. The excess (the difference between what was actually seized at the capped price and what would have been seized at the correct price) amounts to approximately $760,806 across all liquidations. This excess collateral was transferred from borrowers to liquidators purely as a consequence of the oracle misquoting. Combining both layers, the total oracle-attributable borrower damage amounts to approximately $1,027,795. Aggregate Impact by Market Market Liquidations Debt Covered (USD) Collateral Seized (USD) Excess Loss (USD) Bonus (USD) Core 20 $20,913,716 $21,707,501 $598,704 $210,077 Prime 27 $5,657,690 $5,872,428 $162,102 $56,912 Total 47 $26,571,406 $27,579,929 $760,806 $266,989 Largest Individual Liquidations Market User Collateral Liquidated Debt Repaid Bonus Core 0x4Ba…7DF 1,870 wstETH ($4.62M) 2,220 WETH ($4.58M) $41.2K Core 0xf82…0De 1,150 wstETH ($2.84M) 1,370 WETH ($2.82M) $25.4K Prime 0x1E2…6A5 792 wstETH ($1.95M) 937 WETH ($1.93M) $17.4K Prime 0x6C9…85e 478 wstETH ($1.18M) 565 WETH ($1.17M) $10.5K Note: Full list of impacted borrowers will be shared on demand Estimated Per-Layer Loss Breakdown Loss Component Amount (USD) % of Total Excess collateral seized (Layer 2) $760,806 74.0% Wrongful liquidation bonus (Layer 1) $266,989 26.0% Total oracle-attributable damage $1,027,795 100.0% of which: protocol fees (carved from bonus) $27,307 - of which: liquidator profit (from bonus) $239,682 - Resolution The immediate issue has been fully resolved. The oracle price was corrected at block 24628089 (15:53:59 UTC), restoring the wstETH oracle to $2,551.25. Chaos Labs paused all CAPO Risk Oracle updates at 13:13 UTC and confirmed at 14:11 UTC that the root cause had been identified. Emergency borrow cap restrictions (set to 1 on both Core and Prime via Aave stewards) were applied to prevent further exposure during the remediation phase of this incident. At the time of writing, the CAPO oracle is performing as expected, with the wstETH borrow cap reversion intended to be executed via a separate AIP proposal. Separately, an investigation into the triggering transaction revealed that the Chainlink Automation node, which executed the CAPO update, passed by Chaos Labs Risk Oracle, received approximately 141 ETH from the block builder via a Flashbots backrun bundle ([0x9064b5...8a9c](https://etherscan.io/tx/0x9064b507f16bd8b85fb5aea0185153b01fa23b3205f7153f986e5107ce988a9c)). The transaction was independently in the public mempool and was picked up by a searcher who profited from the resulting liquidation opportunity. Under Flashbots’ OFA (Order Flow Auction) defaults, 90% of the backrun value was refunded to the originating address, in this case, the Chainlink node. Chainlink Labs has confirmed that these funds will be returned to the Aave DAO. While the 141 ETH (approximately $291,000 at the time of the incident) does not fully offset the $1.03 million in borrower damages, it provides a partial recovery that may be directed toward affected user remediation at the governance’s discretion. Chainlink’s efforts to identify relevant searchers and recover more of the funds are ongoing. Conclusion The affected borrowers suffered quantifiable financial harm of approximately $1.03 million as a direct consequence of a parameter error in an automated system. The governance community should determine what, if any, remediation is appropriate for these users, recognizing that the liquidations were not the result of market movements but of a technical error in a governance-approved system. The black-box nature of the Risk Oracle infrastructure makes independent verification of the underlying issue difficult. LlamaRisk does not have access to Chaos Labs’ internal parameters, calibration logic, or the agent’s decision-making pipeline. We can observe the on-chain effects: the snapshot parameters that were pushed, the resulting cap that activated, and the price depression that followed, but we cannot independently audit the software that generated those parameters or confirm the precise nature of the “timestamp synchronization error” described by Chaos Labs. This is not the first time Chaos Labs’ automated risk systems have produced unexpected outcomes. Just two weeks prior, the Slope2 Risk Oracle exhibited behavior that materially diverged from its published specification during WETH utilization spikes in February 2026, reducing slope2 during stress conditions rather than escalating it, and remaining below its published floor for over 125 hours. That incident, while different in mechanism, raised similar concerns about the opacity and reliability of automated parameter-update systems operating with delegated governance authority. Taken together, these two incidents within a span of weeks underscore the need for greater transparency, independent auditability, and robust safeguards around automated risk agents operating on Aave. Reference Links Triggering transaction ARFC: Dynamic Calibration of CAPO Parameters via Risk Oracles Retro: WETH Utilization Spike and Slope2 Risk Oracle Performance Disclaimer This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work. The information provided should not be construed as legal, financial, tax, or professional advice. 1 post - 1 participant Read full topic