Executive Summary
On March 10, 2026, a newly deployed CAPO Risk Agent pushed a parameter update that artificially depressed the wstETH oracle price by approximately 2.85%, triggering roughly $26.6 million in liquidation volume across Aave V3 Core and Prime markets. LlamaRisk detected the anomalous liquidation activity within minutes and immediately flagged the issue to other service providers. While we have completed our own independent post-mortem, we defer to @ChaosLabs’ published report to avoid redundancy. We believe this incident highlights meaningful room for improvement in how automated risk systems operating under delegated governance authority are tested, validated, and overseen. This response outlines our assessment of the root cause, opportunities to strengthen testing and transparency standards across delegated risk infrastructure, and the structural changes we believe are necessary to prevent recurrence, including LlamaRisk co-signing authority through the RiskSteward role.
Detection and Initial Response
LlamaRisk detected the anomalous liquidation activity within minutes on March 10 and immediately flagged the issue to other service providers. Upon identifying the liquidations, we initiated an internal war room focused on two priorities: determining whether the incident was contained to the wstETH adapter on Core and Prime, or whether other CAPO-protected markets were similarly at risk. We also began work on our own independent post-mortem and impact analysis.
Observed oracle deviation vs. Market Price
Root Cause
The onchain rate-limiting constraint on snapshotRatio updates (a maximum 3% increase every 3 days) is a known, static property of the smart contract. The offchain risk oracle, under Chaos Labs’ purview, is responsible for computing parameter updates that satisfy these constraints. The agent pushed a snapshotTimestamp that assumed a 7-day-old anchor while the corresponding snapshotRatio could not be updated to the matching value in a single transaction. In our assessment, the root cause traces back to the offchain system producing a configuration that was inconsistent with the onchain constraints it was operating within. We raise this not to assign blame, but because precise root-cause attribution is essential for the Aave protocol to understand what needs to change and where.
Opportunities to Strengthen Pre-Deployment Validation
This failure mode was deterministic and reproducible, the type of issue that pre-execution simulation is specifically designed to catch. Running the proposed parameter update against a forked mainnet environment and checking whether isCapped() would return true, or simply verifying that the resulting maxRatio exceeded the current live exchange rate, which would have surfaced the issue before any transaction was broadcast.
As this was the first update pushed by the CAPO Risk Agent, it presents a valuable learning opportunity to establish robust validation as a standard requirement for both initial deployments and ongoing operations. The Aave protocol should expect, at a minimum, that any automated agent operating with delegated governance authority over pricing infrastructure runs pre-execution simulation checks as standard practice.
Strengthening Independent Oversight and Transparency
While the Risk Agent’s methodologies are typically posted on the governance forum at the proposal stage, it is currently not possible for LlamaRisk or any other party to independently verify the offchain code executed. The agent’s internal parameters, calibration logic, and decision pipeline are not yet open to independent verification. We can observe what lands onchain, but we cannot audit what generates it.
We believe this is an area where the ecosystem would benefit from greater transparency. Two weeks prior, we documented that the Slope2 Risk Oracle exhibited behavior that diverged from its published specification during the WETH utilization spikes of February 2026, reducing slope2 under stress rather than escalating it, and remaining below its stated floor for over 125 hours. That experience, together with this CAPO incident, suggests that the current oversight framework would benefit from greater visibility into offchain systems, enabling divergences to be identified earlier in the process.
LlamaRisk’s Role Going Forward
With @bgdlabs’ departure, Aave protocol’s operational resilience depends more than ever on ensuring that critical infrastructure benefits from meaningful external checks, regardless of the operator. Today, LlamaRisk’s visibility is limited to onchain contracts and transactions. We have no access to the internal agent parameters, no co-signing authority over RiskSteward operations, and no mechanism for mandatory pre-execution review. Our current oversight capacity is structurally limited to what is observable onchain, which constrains the value we can deliver to the Aave protocol.
With that in mind, we’d like to offer the following recommendations:
- Adding LlamaRisk to the RiskSteward co-signing role. Current signers will need to be rotated due to @ACI and @bgdlabs departures, and this presents a natural opportunity to incorporate independent validation of mission-critical parameter updates before execution. We would welcome the opportunity to serve in this capacity.
- Pre-deployment failure mode reviews for future delegations of parameter authority. Before new Risk Agents are approved, we believe the Aave protocol would benefit from an independent, publicly documented analysis evaluating behavior under worst-case allowable parameter values — explicitly asking: what happens if the agent pushes the most extreme update its onchain constraints permit? For the CAPO agent, this would have revealed that the
snapshotTimestamp/snapshotRatiorate-limited interaction could result in an artificially capped price. - A review of live Risk Agents. Even without access to offchain agent code, a useful review can be conducted of each agent’s onchain integration points, permissioned roles, rate-limiting bounds, and a failure-mode analysis assessing the consequences if each agent pushes the worst allowable values within its current constraints.
- Private review of Risk Agent testing suites. To move beyond reactive post-incident analysis toward more proactive oversight, it would be valuable for LlamaRisk to privately review the testing and validation suites underpinning Risk Agent deployments. This would help build confidence across stakeholders without requiring full disclosure of proprietary logic, while meaningfully expanding the surface area that independent review can cover.
Aave protocol has entrusted multiple service providers precisely so that no single point of failure can put user funds at risk. That design works best when oversight mechanisms are empowered with the access and authority to fulfill their mandate.
Disclaimer
This review was independently prepared by LlamaRisk, a community-led decentralized organization 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.