We appreciate the engagement from the community and welcome the opportunity to address the questions raised. We take this incident seriously. Regardless of where the root cause sits across the system’s components, we operated the oracle that produced the update, and we accept the responsibility that comes with it.
Operational Track Record and QA Testing
Chaos Labs operates a robust simulation engine and testing environment that has underpinned Aave’s risk management for over three years. This infrastructure has supported the deployment of multiple Risk Oracles across Aave instances and enabled thousands of parameter updates to be executed safely and without incident. The overall system is designed with multiple layers of safeguards: offchain simulations generate candidate outputs, those outputs are subjected to extensive tests and rule-based validations, and deployment artifacts are then encoded for onchain execution. Once published onchain, updates pass through the standard execution flow and associated validation layers before being applied.
CAPO itself has operated reliably for approximately two years across a broad set of assets and market conditions, consistently protecting against oracle manipulation without false positives or unintended price impacts. This incident does not reflect the system’s normal operating baseline, nor does it indicate a flaw in the core Risk Oracle design. Rather, it arose from a narrow edge case tied to an unusually stale parameter configuration that fell outside the scenario space typically covered under normal operational cadence, and to prevent this from recurring we will extend the simulation and validation framework to more explicitly cover this class of stale-state and constrained-update scenarios.
Design Failure or Edge Case
@PrudentiaLabs, @Frida, @hsim.dev
The incident arose from an integration gap between offchain and onchain components. In particular, the offchain oracle logic and the onchain enforcement path were not aligned in how they handled updates to the snapshot reference state when the target adjustment was too large to be applied in a single transaction.
This produced a configuration where the timestamp emitted assumed a more advanced anchor than the ratio could support. This edge case was contingent on a snapshotRatio that had not been updated for over a year, producing a drift between the stale onchain value and the intended target that exceeded what the rate-limiter could bridge in a single step. Under regular operational cadence, this misalignment cannot arise.
More fundamentally, when the targeted snapshotRatio is constrained, enforcing the snapshot directly onchain as the pair (snapshotTimestamp, snapshotRatio) is itself suboptimal and can be prone to incorrect configurations. Historical snapshot ratios and their associated snapshotTimestamp do not reliably correspond to the intended target exchange rate, or even a close approximation of it, because there is no guarantee about when a rate-constrained onchain snapshot could actually have been emitted in the past. In some cases, this construction can even undercut the intended bound.
The 3% bound was analytically derived as a system-wide parameter and not chosen ad hoc. CAPO applies the same onchain snapshotRatio update constraint across all covered assets, so the threshold must be robust not just for wstETH, but also for assets with faster accrual dynamics and for configurations that apply over windows longer than 7 days. While wstETH’s own 7-day change is only about 0.06–0.08%, the shared constraint was designed against these broader requirements. A 6.1% required move is therefore not something that would emerge in the course of normal upkeep; it was a consequence of prolonged staleness. We are implementing additional controls to ensure this type of edge case does not recur.
Mitigation
Following the incident, we immediately handled the situation and implemented multiple mitigation steps to contain further exposure and restore correct oracle behavior:
- Temporarily reduced the wstETH borrow cap to 1 on Aave Core and Aave Prime to limit additional risk while remediation was underway.
- Manually realigned
snapshotRatiowith the currentsnapshotTimestampreference window via Risk Steward intervention, restoring the oracle to its correct value.
Prevention Measures
Additionally, we are aiming to implement the following guardrails at both the onchain and offchain levels:
- Risk Steward escalation protocol: Where gradual convergence under onchain constraints would require an excessive number of automatic update steps, Risk Steward or Governance intervention will be used to accelerate resolution in a controlled and validated manner.
- Consistent snapshot construction under constrained updates: To prevent a recurrence of this edge case, snapshot updates will avoid forcing the nominal target timestamp directly when the corresponding
snapshotRatiocannot be reached in a single onchain step. Instead, the update process will derive the effectivesnapshotTimestampthat is economically equivalent to the intended target timestamp under unconstrained assumptions, ensuring that the resulting (snapshotTimestamp,snapshotRatio) pair remains internally consistent while still approximating the intendedmaxRatio. - Explicit offchain boundary checks: We are adding an explicit validation step in the offchain update process to ensure that any candidate onchain configuration cannot imply an exchange rate bound below the current exchange rate plus an expected growth buffer. This is intended to prevent a configuration from being propagated if it would artificially depress the exchange rate cap relative to a reasonable forward expectation.
- Additional onchain prevention measures: We are actively discussing with BGD further onchain safeguards that would reduce the possibility or impact of an erroneous CAPO configuration or exchange rate update while preserving the protocol’s core protective function, and will share more information on this in the coming days.
Compensation
The compensation process, prior to the posting of the post mortem, has been coordinated jointly with ACI, BGD Labs, TokenLogic, and Aave Labs. Funds recovered through BuilderNet refunds, totaling 141.5 ETH in recaptured liquidation bonus revenue, will be applied directly toward reimbursing affected users. Any remaining gap will be covered through the Aave DAO treasury. Active efforts to recoup additional value from liquidation-linked activity are ongoing. A detailed compensation plan has been communicated in the following post.
CAPO’s parameter flexibility
It is not a goal of the CAPO system to push the effective exchange rate downward under normal market conditions. The system exists to cap upward deviations that could be used to generate unbacked borrowing power. However, the flexibility for the computed cap to fall below the live rate is a necessary consequence of how the bounding mechanism works, without it, the system could not function as a guardrail against rapid upward manipulation.
On the question of whether a circuit breaker could be introduced to detect anomalous downward deviations and pause liquidations: while the intent behind this suggestion is sound, implementing such a mechanism could in practice interfere with CAPO’s core function. The system needs to be able to enforce a cap that may, in edge cases, sit below the live rate in order to reject manipulated prices. There are design approaches for introducing constraints that reduce the hypothetical impact of an erroneous exchange rate outlier update that artificially lowers the exchange rate price, while still preserving CAPO’s core security objective. We are currently discussing such approaches with BGD Labs, and will share more in the coming days on this front.