Cowrie Research

aave-wsteth-capo-snapshot-misalignment-liquidations-2026-03-10

11 min read

Aave wstETH CAPO Snapshot-Misalignment Liquidations (2026-03-10)

  • Name: Aave wstETH CAPO snapshot-misalignment liquidations
  • Date: 2026-03-10
  • Protocol: Aave
  • Chain: Ethereum Core and Prime instances
  • Category: oracle configuration failure / protective-oracle misfire / liquidation cascade / no protocol bad debt
  • Loss: roughly 10,938 wstETH of liquidations across 34 accounts, with about $27.78M of affected collateral value and hundreds of ETH of liquidation-linked value extracted before reimbursement
  • Summary: On 2026-03-10, Aave’s Correlated Asset Price Oracle (CAPO) for wstETH misfired. The protective overlay was designed to cap suspicious upward exchange-rate moves, but an update pushed snapshotTimestamp fully to a seven-day-old reference while snapshotRatio remained onchain-rate-limited and could only move part of the way. CAPO then computed a maximum allowed wstETH/stETH exchange rate below the live market rate and overrode the protocol’s effective price by about 2.85%. Liquidators immediately used that false discount to force liquidations on otherwise healthy E-Mode positions. Aave incurred no bad debt, but users were liquidated against a protocol-self-inflicted price error and Aave later had to organize reimbursement.
  • Trigger / entry point:
    • At 2026-03-10 11:46 UTC, Chaos Labs’ offchain Edge Risk engine computed and submitted a snapshotRatio update to the wstETH CAPO oracle.
    • The parameter update transaction was 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95.
    • BGD Labs’ AgentHub execution layer then executed the update one block later via Chainlink Automation in transaction 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.
    • CAPO was not a third-party oracle replacing Chainlink. It was Aave’s own defensive overlay on top of the underlying feed, designed to prevent donation-style and exchange-rate inflation attacks.
  • Root cause:
    • CAPO depended on three variables staying aligned: snapshotRatio, snapshotTimestamp, and maxYearlyRatioGrowthPercent.
    • The offchain logic targeted a seven-day-old reference ratio near 1.2282, but the onchain contract only allowed snapshotRatio to increase by 3% every 3 days.
    • Because the prior onchain ratio was about 1.1572, the contract could only accept an increase to roughly 1.1919, not the intended 1.2282.
    • snapshotTimestamp, however, still advanced to the seven-day-old reference point (1772535647) as if the full ratio update had occurred.
    • That mixed state made CAPO extrapolate from a ratio anchor that was too low for the elapsed-time basis being used, yielding a calculated cap near 1.1939, below the already-prevalent live exchange rate.
    • The result was an artificial ~2.85% downward move in the effective wstETH price used by Aave, which the liquidation engine then honored as real.
  • Exploit path:
    1. Aave’s risk-oracle stack prepared a CAPO update intended to keep the defensive bound aligned with the live wstETH/stETH exchange rate.
    2. Onchain rate limits prevented snapshotRatio from moving fully to the intended target in one update.
    3. snapshotTimestamp still advanced to the full seven-day-old reference window, leaving the two CAPO anchor variables inconsistent.
    4. CAPO computed a maximum allowed exchange rate below the live market rate and overrode the effective price seen by the lending markets.
    5. Liquidators immediately targeted E-Mode accounts whose health factors fell below the artificial threshold; the incident affected about 34 accounts and about 10,938 wstETH of liquidation volume.
    6. Chaos Labs reduced the wstETH borrow cap to 1 on Aave Core and Aave Prime, then manually realigned the snapshot parameters so the oracle reverted to its true value.
    7. Aave later pursued reimbursement using recovered BuilderNet refunds, protocol fees, and DAO treasury support.
  • What the attacker needed to be true:
    • No attacker had to move the wstETH market itself; the protocol only needed to publish a wrong protective cap and let liquidators consume it.
    • Aave’s liquidation engine had to trust CAPO’s effective output immediately.
    • The risk stack needed paired variables that could diverge under different update constraints.
    • Liquidations had to remain permissionless, allowing searchers to crystallize the error before humans intervened.
  • Technical anatomy worth remembering:
    • This was not an oracle-manipulation attack against Chainlink or wstETH. The underlying market and underlying feed were fine.
    • The failure lived in Aave’s own anti-manipulation overlay: a defensive mechanism became the source of the bad price.
    • The decisive invariant was snapshotRatio and snapshotTimestamp alignment. CAPO only makes sense when both describe the same reference point.
    • The incident is a strong reminder that safety layers deserve the same adversarial review as the underlying thing they are protecting. A cap, bound, or anti-inflation wrapper is still an oracle once the protocol honors it.
    • Recovery mechanics are also worth preserving: Aave reported no bad debt, about 141.5 ETH recaptured through BuilderNet refunds, about 13 ETH in liquidation fees, and a compensation process for impacted users.
  • Representative transactions and artifacts:
    • CAPO parameter update submission: 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95
    • AgentHub execution transaction: 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e
    • Emergency borrow-cap reduction: 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8
    • Intended offchain reference ratio: ~1.2282
    • Prior onchain snapshot ratio: ~1.1572
    • Maximum allowed onchain update under contract constraints: ~1.1919
    • Mis-set timestamp reference: 1772535647
  • Impact summary worth preserving:
    • About 10,938 wstETH of liquidation volume across 34 accounts
    • Roughly 2.85% downward deviation in the effective wstETH/stETH exchange rate used by the protocol
    • Approximately 116 ETH in liquidation bonuses and protocol liquidation fees captured during the incident according to the postmortem framing
    • Approximately 382 ETH in additional liquidator profit captured from the underpriced oracle path
    • Reimbursement proposal size: about 513.19 ETH total, offset by 141.60 ETH recovered from Titan Builder / BuilderNet-linked recovery and 13.32 ETH of recovered liquidation fees, leaving about 358.56 ETH net DAO cost at proposal time
    • No protocol bad debt
  • Response / mitigation:
    • Aave and Chaos Labs quickly reduced the wstETH borrow cap to 1 on the affected instances.
    • Manual Risk Steward intervention realigned the snapshot parameters so CAPO no longer capped the live price incorrectly.
    • Aave later proposed reimbursement for affected users, using recovered builder-linked refunds, protocol fees, and DAO resources to make users whole.

Pattern tags

Why the exploit worked

  • CAPO’s safety logic relied on a paired-state invariant that the protocol did not enforce onchain: snapshotRatio and snapshotTimestamp had to describe the same historical anchor point, but each variable could effectively move under different practical constraints.
  • Aave’s offchain risk logic targeted a coherent end state that the contract could not realize in one step. The dangerous state was therefore not the intended target but the partially realized intermediate state that still became live oracle truth.
  • The protocol treated its own defensive overlay as immediately authoritative for liquidation decisions. Once CAPO published a lower effective exchange rate, searchers did not need to attack wstETH, stETH, Chainlink, or Ethereum liquidity; they only had to liquidate against the protocol’s self-inflicted discount.
  • Response speed was asymmetrical with liquidation speed. Even though the team intervened quickly, the system still gave the inconsistent state enough time to liquidate about 10,938 wstETH before alignment was restored.

Detection and audit pivots

  • For every capped or anchored oracle, ask whether the safety object is actually one state vector rather than a bag of separately writable parameters. If a cap only makes sense when ratio, timestamp, and growth assumptions describe the same historical point, they should update atomically or fail closed.
  • Review not only the target numbers an offchain agent intends to publish, but also the numbers the contract can actually accept under current rate limits. A logically correct target can still be unsafe if contract constraints force a half-step.
  • Diff the post-update effective price against both the previous onchain answer and an independent external reference before the new state gains liquidation authority.
  • Treat protocol-local anti-manipulation layers as first-class oracle publishers. A bound, cap, or guardrail that can override the base feed should have the same plausibility checks and canary treatment as any fresh oracle deployment.
  • Ask whether emergency containment can remove liquidation authority faster than bots can consume a bad defensive update. If not, borrow-side quarantine or canary rollout should be part of the normal activation path.

Failure-prevention checklist

  • Make paired oracle-anchor state atomic. If snapshotRatio, snapshotTimestamp, and growth-limit assumptions only make sense together, publish them as one committed object or reject the update entirely.
  • Validate the realizable post-update state, not just the intended target. Offchain agents should simulate contract-side clamping and refuse to submit updates whose constrained result would move effective price outside an allowed plausibility band.
  • Gate liquidation authority behind a canary phase for protective overlays. A newly updated CAPO-style bound should first be observable and alertable before it can liquidate live positions.
  • Add independent sanity checks between the overlay and the base oracle. If the protective cap would force a material discount versus a healthy underlying feed, freeze the cap, freeze liquidations, or fall back to the safer source.
  • Require emergency controls that close faster than searchers can monetize the bad state: per-asset liquidation pause, temporary collateral factor downgrade, borrow-cap reduction, and overlay bypass or de-recognition.
  • Separate research and experimentation from live solvency publication. If an offchain risk engine can synthesize novel parameter states, those states need stricter staging than ordinary maintenance updates.
  • Monitor for configuration-impossible or economically implausible states: capped price below a healthy correlated market, anchor timestamps that imply more elapsed growth than the ratio actually captured, or one-step protective-price moves large enough to liquidate clustered E-Mode books.
  • Design reimbursement and recovery paths in advance. If a protocol-local oracle mistake can liquidate healthy users without causing bad debt, the system still needs a precommitted compensation lane.

Audit prompts

  • What exact invariant proves that the protective oracle’s anchor variables still describe the same historical point after onchain rate limits, clamping, rounding, and delayed execution are applied?
  • Can the contract advance timestamp, ratio, cap window, or growth assumptions independently even though the liquidation engine later interprets them as one object?
  • If the offchain agent proposes a state the contract cannot fully realize, what intermediate state becomes live, and has that half-updated state been adversarially reviewed?
  • What magnitude of overlay-vs-base-oracle divergence automatically disables liquidation authority, and is that threshold based on economics rather than operator intuition?
  • Does a new defensive cap become immediately borrow-, collateral-, and liquidation-relevant, or is there a preview / canary phase where humans and monitors can reject it?
  • Which path fails closed when the protective layer disagrees with the underlying feed: the cap itself, liquidation eligibility, the correlated asset’s collateral factor, or nothing at all?
  • How quickly can responders remove liquidation authority compared with MEV searchers’ ability to consume a bad update in the next block?
  • Are reimbursement, refund capture, and fee clawback mechanics already specified for false-liquidation events, or is the protocol improvising after users have already been harmed?

Lessons that should already be standard

  • Defensive oracle overlays are still oracles. Once a protocol honors them for liquidation, they deserve the same adversarial design standards as the feed they are meant to protect.
  • Intended target state is not the security boundary. The live risk surface is the exact state the contract can accept after clamping, timing, and automation constraints.
  • Partial updates are not neutral maintenance states when liquidations are permissionless. A half-updated protection layer can be more dangerous than no protection layer at all.
  • Safety mechanisms need rollout discipline too. Canarying, fallback logic, and plausibility checks are not optional just because the feature was added to reduce risk.
  • No-bad-debt outcomes can still be protocol failures. If healthy users were liquidated against a protocol-authored false price, the absence of insolvency does not make the event benign.
  • Emergency response must be measured against bot speed, not team intent. If the system cannot close liquidation authority before searchers can exploit a bad config, the control plane is too slow.

Why this incident matters

  • It is a clean example of a protocol’s own anti-manipulation machinery becoming the source of forced liquidations.
  • It broadens the incident corpus beyond attacker pushed the market into the protocol published the wrong bound and bots monetized it.
  • It also preserves an operational lesson: when offchain logic targets a state the contract cannot actually realize under current constraints, the dangerous state is the half-updated one, not the intended one.

Internal linkages

Control surface

Graph View

Backlinks