#Background
In February 2026, the WETH reserve on Aave V3 Ethereum Core experienced two significant utilization spikes — the first reaching 95.42%, and the second, 99.85%. These events constituted the first real stress test of the Slope2 Risk Oracle since its implementation. LlamaRisk tracked on-chain IRM parameter updates alongside actual borrow rates and derived utilization, discovering that the oracle's behavior diverged from its published specification in several material ways: the slope2 parameter dropped below its published floor during active stress, the oracle's first response to a kink breach was a reduction rather than an escalation, and multi-day periods passed with no parameter updates while utilization sat well above the kink.
This report examines what drove the disruption, how the oracle appears to have failed to respond, and where the response diverged from the behavior described in the published ARFC and Risk Stewards specification. Each finding is cross-referenced against specific governance claims, and its practical consequences for depositors and the protocol's liquidity buffer are detailed.
Based on these findings, we outline a concrete set of recommendations in the Proposed Path Forward below — including a request for Chaos Labs to publish a full post-mortem with deployed parameter values, an explanation of the floor breach, and a broader commitment to the transparency the DAO requires to govern delegated rate-setting mechanisms.
#Specified Oracle Behavior
The Slope2 Risk Oracle mechanism is described in two governance publications: the original ARFC on slope2 automation (passed via Snapshot roughly six months ago) and a follow-up Risk Stewards post specifying the initial parameter values for each reserve.
The core idea is straightforward. The standard Aave interest rate model uses a piecewise-linear curve with a "kink" at optimal utilization $u_k$. Below the kink, borrowing cost rises gently along slope1. Above the kink, a steeper slope2 kicks in to penalize excess utilization and incentivize repayment. Historically, slope2 was a static governance parameter — for WETH on Ethereum Core, it was set at 20%.
The oracle replaces this static value with a dynamic one. The ARFC describes three clearly defined phases:
1. The "Initial Grace Phase"
"when utilization crosses the kink, the interest rate increases gradually via a parameterized slope above the kink ($s_2$) in accordance with a minimum viable deterrent."
The post-kink slope evolves as $s_{2,t+1} = s_{2,t} \cdot \exp(k \cdot \phi_t \cdot \Delta t)$, where $k$ is the growth coefficient and $\phi_t = \left(\frac{u_t - u_k}{1 - u_k}\right)^+$ is the normalized overshoot. The ARFC states this "gentle escalation signals borrowers to unwind positions orderly without inducing panic or simultaneous exits."
2. The "Escalation Phase"
The phase where "slope growth compounds multiplicatively and exponentially. The longer the stress persists, the more expensive it becomes to stay levered." The ARFC requires that "for all $u > u_k$, the incremental cost of remaining levered must increase monotonically with both the magnitude of excess utilization and the duration spent above the kink."
3. The "Decay Phase"
The ARFC states:
"Once utilization falls below the kink, the elevated slope decays exponentially on a predictable half-life. Borrowers who remain can re-enter at lower rates without facing a sharp reset. Governance does not need to flip switches; decay is automatic."
The decay follows $s_{2,t+1} = s_{2,t} \cdot \exp(-\lambda \cdot \Delta t)$.
Throughout all phases, the ARFC is explicit about mechanical boundedness. Under the heading "Boundedness: Hard Caps, Credible Floors," the ARFC specifies that rate bounds "are enforced mechanically, not heuristically" and that "a non-trivial floor prevents the resurgence of recursive carry trades at negligible cost once stress subsides." The value of $s_2$ is described as "always clamped within predefined limits $[s_{\min}, s_{\max}]$."
For WETH on Ethereum Core specifically, the Risk Stewards post set the recommended slope2 at 8%, down from the previous static value of 20%. The post explained that "the specification initially sets slope2 to its minimum value in each market, ensuring alignment with the parameterized algorithm of the respective reserve" — in other words, 8% is $s_{\min}$, the floor from which the oracle would escalate dynamically. The AGRS framework was configured to "allow a maximum absolute change of 4% every 8 hours."
#Observed Oracle Behavior
Source: Dune Analytics, February 17, 2026
#The baseline (Feb 1–5)
Through the first five days of February, everything behaved as expected. Slope2 sat at 8.0%, consistent with the published $s_{\min}$. The optimal utilization threshold was set at 92%, with a base rate of 0% and a slope1 of 2.35%. Derived utilization hovered in the 85–88% range, well below the kink. The borrow rate was steady at around 2.2%. Nothing to report.
#First breach and the oracle's response (Feb 6–7)
On February 6 at 07:00 UTC, derived utilization crossed above the 92% kink for the first time, reaching 92.53%. The borrow rate at that moment was 2.88%. This is precisely the scenario the oracle's "Initial Grace Phase" was designed for: utilization has crossed the kink, and the compounding growth term $\exp(k \cdot \phi_t \cdot \Delta t)$ should activate on the next update cycle.
What happened instead was the opposite of what the specification describes. The first slope2 update came six hours later, at February 6 13:00 UTC — and it was a reduction, not an increase (in opposition to the expected behavior). Slope2 dropped from 8.0% to 6.5%. At that moment, utilization was at 95.42% (3.42 percentage points above the 92% kink), and the borrow rate had already spiked to 5.13%. The oracle's first action during a stress event was to cut the parameter designed to deter excess utilization.
Source: Dune Analytics, February 17, 2026
This 6.5% value persisted for 14 consecutive hours, from February 6 13:00 through February 7 02:00. Throughout this entire window, utilization remained well above the kink, with borrow rates fluctuating between 4.5% and 6.5%.
The first upward adjustment came at February 7 03:00 UTC, when slope2 jumped to 8.36%. Eight hours later, at 11:00 UTC, it stepped up again to 9.75% — the peak slope2 value for the entire first spike. This was 20 hours after utilization first breached the kink, and 14 hours after the oracle had cut slope2 to 6.5%.
The oracle's peak escalation was 9.75%. The previous static slope2 was 20%. What we observed was a parameter that briefly rose from 8% to 9.75% — a 1.75 percentage-point increase — after spending its first 14 hours below its floor. The entire range of slope2 during this two-week stress test was 6.5% to 9.75%, barely a 3.25 percentage-point band.
#The kink change — a parallel intervention (Feb 7)
At February 7 15:00 UTC, the optimal utilization parameter was changed from 92% to 94% by the Chaos Labs Risk Stewards, and slope1 was simultaneously adjusted from 2.35% to 2.45%. This shifted the kink threshold upward by 2 percentage points, instantly dropping the market out of the slope2 regime — the derived utilization at that hour was 93.82%, now below the new 94% kink.
#The decay below the floor (Feb 8–13)
After the first spike, utilization oscillated around the new 94% kink before settling below it, around February 10. Slope2 should have decayed exponentially toward its floor per $s_{2,t+1} = s_{2,t} \cdot \exp(-\lambda \cdot \Delta t)$, clamped at $s_{\min} = 8%$.
Instead, slope2 remained at 9.75% for 97 hours with no updates. Then the step-wise reductions began:
Source: Dune Analytics, February 17, 2026
Slope2 remained at 6.73% for an additional 71 hours without correction. In total, it spent 125 consecutive hours below the published 8% floor (Feb 12 05:00 through Feb 16 10:00).
#Second spike — the market caught exposed (Feb 14–15)
On February 14, utilization began creeping above the 94% kink starting at 15:00 UTC. Slope2 was sitting at 6.73%. Then at 23:33 UTC, the address 0xF744f66621Df59861fe621444E473b595bb83Ad4 withdrew 69,378.37 WETH (approximately $138.6M) in transaction 0x23932f... via the Aave ETH Staking Contract. A second entity had executed an additional large withdrawal 7 hours earlier (0x7d6c7c...).
Source: Dune Analytics, February 17, 2026
At the 23:00 UTC hourly reading — the closest data point to the whale exit — the numbers were stark: derived utilization 99.76%, borrow rate 8.91%, slope2 still at 6.73%. The borrow rate peaked at 9.01% on February 15 at 02:00 UTC, when utilization hit 99.85%. At that moment, the rate was 98.2% of the theoretical maximum the curve could produce at a slope2 of 6.73% (max rate = 9.18%).
For context: with slope2 at the published 8% floor, the maximum rate would have been 10.45%. With the pre-oracle static slope2 of 20%, it would have been 22.45%. With a properly escalated slope2 — had the oracle been compounding upward since utilization first breached the kink at 15:00 — it would have been substantially higher still. Instead, the market hit 99.85% utilization with a rate curve that could only offer 9.18% as its absolute maximum deterrent.
Slope2 did not respond to the second spike for 43 hours. It remained at 6.73% from February 13, 11:00, until February 16, 10:00, when it finally jumped to 9.15%. Another update on February 17, 03:00 brought it to 9.67%. By this point, the unprecedented utilization spike had passed.
#The aftermath (Feb 15–17)
Borrow rates subsided from the 9% peak as utilization gradually improved, though it never returned below the 94% kink through the end of our observation window (February 17 17:00 UTC). Slope2 at 9.67% represents the highest value the oracle has reached since the second spike — still less than half of the old static 20%.
#Verification Gaps in the Deployed Configuration
LlamaRisk does not have access to the actual deployed values of $k$, $\lambda$, $s_{\min}$, or $s_{\max}$ for the WETH reserve. The on-chain behavior suggests that $s_{\min}$ was not set to 8% as published, or that the clamping logic is not functioning as described— or both. We do not know why slope2 dropped to 6.5% when utilization was above the kink, and the specification calls for compounding growth. We cannot explain why slope2 dropped to 6.5% when utilization was above the kink, and the specification calls for compounding growth. We cannot explain the 97-hour plateau at 9.75% or the 71-hour freeze at 6.73%. The published specification provides no mechanism that would produce any of these behaviors.
#Proposed Path Forward
In practice, the Slope2 Risk Oracle — as configured and operated during February 2026 — does not appear to have responded with sufficient urgency to preserve the available liquidity buffer during either WETH stress event. The oracle's peak slope2 of 9.75% remained well below the previous 20% static value, and its trough of 6.5% fell beneath its own published floor. At the time of the largest supply shock in the period, the maximum deterrent on the rate curve stood at 9.18%, compared to 22.45% under the prior regime. The result was that utilization shocks appear to have persisted longer than they would have under the previous configuration.
We recommend the following:
- Post-mortem disclosure: ChaosLabs to publish a post-mortem covering the February WETH events, disclosing the exact parameter values ($k$, $\lambda$, $s_{\min}$, $s_{\max}$) in effect throughout the period, any manual interventions or parameter overrides that occurred, and the root cause of the floor breach and the anomalous initial drop from 8.0% to 6.5%.
- Public parameter registry: A public registry of the internal oracle parameters for each covered reserve, updated whenever they change, so that the community can independently verify that deployed values match approved specifications. Accordingly, this will allow to transparently re-evaluate the model and parameters in order to more closely reflect the market behavior and tune the range of expected actions.
- AGRS interaction analysis: A formal evaluation of the interaction between the AGRS rate-limiting framework ("maximum absolute change of 4% every 8 hours") and the oracle's continuous-compounding design. A mechanism whose specification assumes minute-by-minute compounding cannot deliver its promised behavior if constrained to infrequent, irregularly timed step changes. The February events suggest this interaction may be the binding constraint on response speed.
- Effective range reassessment: An evaluation of whether the oracle's observed operating range of 6.5%–9.75% is adequate for a market where utilization spikes to 99.85%, as initially flagged by LlamaRisk in our response to the Risk Stewards deployment post. The gap between the oracle's maximum deterrent (9.18%) and the prior regime's (22.45%) should be explicitly justified or corrected.
The DAO's approval of this mechanism rested on specific mathematical properties — mechanical clamping, autonomous exponential decay, continuous compounding growth — and the ARFC itself positioned "calibratability" and "reproducibility" as core design goals. At present, neither the community nor LlamaRisk has the means to independently confirm whether the deployed configuration reflects the approved specification. The events of February 2026 demonstrate that delegating rate-setting authority to an off-chain oracle requires a commensurate commitment to transparency: the DAO cannot meaningfully govern a mechanism whose internal parameters are not publicly observable, whose update logic is not independently verifiable, and whose behavior during stress diverges from its specification without explanation. Transparency is not an optional courtesy — it is a structural prerequisite for the continued delegation of risk parameter authority to oracle-based systems within Aave governance. We call on Chaos Labs to treat it as such, and on the broader community to hold all risk oracle operators to this standard going forward.
#Disclaimer
This review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. This report is based on publicly available on-chain data (Dune query 6699430) and our analysis of ChaosLabs' published governance proposals (ARFC, Risk Stewards). We welcome corrections and look forward to a constructive exchange with Chaos Labs on these findings.
The information provided should not be construed as legal, financial, tax, or professional advice.