# \[ARFC\] Dynamic Calibration of CAPO Parameters via Risk Oracles **URL:** \ **Category:** Governance\ **Created:** [July 15, 2025, 10:06pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601 "2025-07-15T22:06:36Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ChaosLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/chaoslabs/32/6850_2.png) [@ChaosLabs](https://governance.aave.com/u/ChaosLabs)\ **Post date:** [July 15, 2025, 10:06pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601/1 "2025-07-15T22:06:36Z")
## Abstract This document presents a formal framework for dynamically calibrating the core parameters of the Correlated Asset Price Oracle (CAPO) system, namely `maxYearlyRatioGrowthPercent` and `snapshotRatio`, through autonomous Risk Oracles. These parameters jointly enforce a time-weighted upper bound on the permissible growth of a yield-bearing asset’s exchange rate relative to its base asset, thereby protecting downstream protocols from artificial inflation and oracle manipulation. Rather than relying on static limits or infrequent governance actions, the CAPO system leverages real-time analytics on yield behavior, reward distribution cadence, and market deviations to continuously constrain oracle outputs. The parameter `maxYearlyRatioGrowthPercent` defines the maximum annualized compound growth allowable in the asset’s exchange rate, while `snapshotRatio`, anchored by a past reference timestamp, serves as the historical baseline against which this growth is measured. Importantly, the effectiveness of CAPO is contingent not only on defensively parameterizing `maxYearlyRatioGrowthPercent`, but also on updating `snapshotRatio` at regular intervals. Without timely snapshots, even well-bounded growth parameters can permit excessive drift between the oracle’s upper bound and the asset’s true economic behavior. Continuous `snapshotRatio` refreshes are therefore critical to ensuring that CAPO remains tight, responsive, and manipulation-resistant across a diverse range of yield-bearing asset types. Risk Oracles act as autonomous agents that monitor these dynamics off-chain and reparameterize the CAPO system accordingly, enabling secure, low-overhead integration into protocols that depend on yield-sensitive exchange rates. ## Overview of CAPO and the Importance of Risk Oracles As detailed in the original CAPO [framework](https://governance.aave.com/t/chaos-labs-correlated-asset-price-oracle-framework/16605), the system is architected to safeguard lending protocols against oracle-driven inflation vectors and donation-style exploits by imposing a deterministic, time-weighted upper bound on the exchange rate between a yield-bearing derivative (e.g., wstETH) and its base asset (e.g., stETH), capturing the upper envelope of organic yield accrual. This upper bound ensures that, even under adversarial conditions, such as unauthorized control of the price feed via compromised EOAs, centralized oracle dependencies, contract upgrade vulnerabilities, or donation attacks that exploit favorable exchange rate misalignments, the protocol remains protected against artificially inflated valuations that could otherwise be used to extract unbacked borrowing capacity or induce bad debt. This enforcement is governed by three key parameters: - `snapshotRatio`: the reference exchange rate - `snapshotTimestamp`: time of reference - `maxYearlyRatioGrowthPercent`: the annualized cap on exchange rate growth The maximum ratio is determined via: ```python function _getMaxRatio() internal view returns (int256) { return int256(_snapshotRatio + _maxRatioGrowthPerSecond * (block.timestamp - _snapshotTimestamp) ``` where maxRatioGrowthPerSecond = (snapshotRatio \* maxYearlyRatioGrowthPercent)/SECONDS\_PER\_YEAR, effectively transforming a multiplicative derivation into fixed point arithmetic. To enforce temporal smoothing and prevent manipulation via micro-timeframe extrapolation, as discussed [here](https://governance.aave.com/t/chaos-labs-correlated-asset-price-oracle-framework/16605#motivation-behind-minimum_snapshot_delay-5), the `snapshotRatio` ensures the snapshot is taken at a sufficient temporal offset from the current block timestamp. The `snapshotRatio` functions as the foundational reference rate from which the upper bound on the exchange rate, denoted `maxRatio`—is derived. The parameter `maxRatioGrowthPerSecond` thus imposes a cap on the permissible rate of change in `maxRatio` relative to the time elapsed between the `snapshotTimestamp` and the current timestamp. This structure inherently positions `snapshotRatio` as the anchor for time-weighted evolution, with `maxRatioGrowthPerSecond` encoding the maximal compound growth over time. Importantly, this design implies that if `snapshotRatio` is not refreshed at a consistent cadence, the derived `maxRatio` becomes increasingly detached from real-world exchange rate dynamics. Over long intervals, the temporal averaging embedded in the model begins to dilute responsiveness, effectively introducing drift between the enforced upper bound and the actual prevailing rate. To illustrate this phenomenon, consider an example where `maxRatioGrowthPerSecond` is set to 9.68%, as wstETH is. If the factual growth in the exchange rate over the elapsed period is only 3.1%, then as the time delta increases, the upper bound `maxRatio` diverges significantly from the true rate. As observed below, the exchange rate can grow as much as 9% before reaching the upper bound during an inflation attack, which represents an equivalent 7 day APY of 450% in order to hit the upper bound. This growing discrepancy stems from the assumption of compounding at 9.68% per second, whereas reality reflects a much more tempered rate, thus highlighting the need for timely `snapshotRatio` updates to maintain effective control and fidelity in rate enforcement. ![output - 2025-07-11T132107.335 (1) (2)](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/1/177013890c2f3d8e5dbae7d85b1fe8e2983987a9.png) Assuming the `snapshotRatio` is updated monthly with a 7-day delay, the same `maxYearlyRatioGrowthPercent` constraint results in a substantially tighter upper bound on the exchange rate trajectory and its derived annualized growth. Empirically, the realized exchange rate remains within ~0.7% of the computed maximum exchange rate at all times, demonstrating effective rate bounding. Notably, this occurs even as the implied annualized growth, computed as a function of the local exchange rate delta, ranges between 12% and 37%. This discrepancy illustrates how regular `snapshotRatio` updates act as a mechanism for bounding short-term rate expansions, minimizing artificial inflation in annualized growth metrics induced by infrequent updates or stale snapshots. ![output - 2025-07-14T093255.820 (1)](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/6/6dc6763c56be47670aedf3d810556d00adf24902.png) ## Dynamic Responsiveness to Local Yield Spikes: Automating `maxYearlyRatioGrowthPercent` In the general case, updating `maxYearlyRatioGrowthPercent` is a relatively frictionless and statistically grounded process. Most yield-bearing assets, such as those driven by lending interest, validator rewards, or liquidity mining, exhibit deterministic or semi-deterministic return profiles, enabling historical data to reliably inform an optimal cap value in a relatively infrequent manner. The CAPO algorithm leverages this regularity by using observed historical behavior to tune bounds that are both tight and appropriate, minimizing over-constraining during periods of normal growth. However, in assets with more sporadic or bursty yield distributions, where updates occur less frequently and `snapshotTimestamp` values may trail current conditions, large injections of rewards, such as DAO-driven emissions, retroactive drops, or sudden staking incentives, can cause abrupt local spikes. In these cases, the growth rate inferred from such snapshots can become outdated or unrepresentative, lagging behind the true yield trajectory. Under the assumption that yield rates are experiencing local upward spikes, such that organic accrual temporarily approaches the configured `maxYearlyRatioGrowthPercent`, the CAPO algorithm, informed by its multidimensional parameter configuration, is designed to adaptively respond. It minimizes false positives by dynamically tightening or relaxing bounds in proportion to observed volatility, thereby reducing unnecessary artificial constraining during periods of legitimate growth. The parameter `maxYearlyRatioGrowthPercent` is computed as follows: ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/1/199f161e116370c5d2cb7c0e34d515b1cc3ba11e.png) ### **Update Decision Rule under Rate Escalation** Given the constraint that CAPO parameters can only be updated every 3 days, it is essential to design a conservative yet precise mechanism for deciding when to trigger an update of `maxYearlyRatioGrowthPercent`. The objective is to ensure that if a sudden escalation in staking yield begins, the CAPO mechanism still maintains an enforceable cap on the exchange rate before the next available update window. To achieve this, we introduce a decision rule that relies on short-term yield velocity as a proxy for immediate risk. ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/8/8ee471cee71eb930f78ad39e184b64c1ce9d7a57.png) In contrast, under the assumption that observed rates decrease over time, per the algorithm above, the recommended output is derived as a function of the last 90 days of data, hence updating downward when necessary. In this context, the underlying “decision rule” is structured such that half of the defined maximum relative change serves as the threshold for permissible deviation, effectively acting as the trigger condition for downward rate updates. ### Practical Examples and Backtesting To illustrate the behavior and responsiveness of the rate calibration framework under varying market conditions, we present two contrasting case studies, ezETH and wstETH, analyzed through historical reward dynamics, APY trajectories, and parameter updates observed during recent backtesting. ezETH’s reward distribution has historically been highly irregular, characterized by intermittent and uneven emissions. In March, ezETH’s exchange rate experienced a notable upward distortion due to the protocol’s one-time injection and distribution of EIGEN rewards directly into the ezETH contract. This distribution materially inflated the exchange rate by increasing the cumulative rewards per token, effectively front-loading yield accrual. Prior to this event, the system exhibited significant short-term volatility in reward emissions and the associated annualized APY, as reflected in elevated dispersion metrics and an initially calibrated maximum rate of 12.38%. ![image - 2025-07-15T174645.490](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/0/0759d212d470e3da63bf2dd1745aef25dd7279ae.png) Post-spike, the rate-setting algorithm executed a parameter recalibration in response to the updated reward trajectory. The underlying statistical properties, such as recent APY momentum and rate-of-change in cumulative rewards, registered an upward shift, thereby impacting the computed max rate recommendation. Crucially, the required minimum 3-day trailing APY, used as a guardrail to prevent excessive rate increases, converged below the observed realized 3-day APY. As a result, the updated max rate, governed by the 3-day constraint, was deemed optimal and within bounds, thereby increasing the associated maxYearlyGrowthPercent. The system thus exhibited resilience by adapting to the anomalous input while maintaining rate integrity and responsiveness. ![image - 2025-07-15T174647.459](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/0/0d3fe77e903af91ae3787c614fa3a9aa8eb4888d.png) By contrast, wstETH exhibits highly deterministic rate growth and a stable state trajectory, which minimizes the need for active updates. The protocol operates under a dynamically constrained cap, continuously adjusted through real-time updates to the `snapshotRatio`. Given the low volatility and predictable accrual pattern, updates to the `maxYearlyRatioGrowthPercent` have been largely unnecessary, with the current value of 4.6% remaining sufficient to accommodate its steady yield progression. ![image - 2025-07-15T174649.416](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/1/1be608fc2f91d5f2d549d41f043a6c92aff5be1a.png) Internally, while the effective recommended rate evolves, the magnitude of change remains within the tolerance defined by the existing `maxYearlyRatioGrowthPercent`, thereby not triggering an update. Specifically, the required 3-day APY has consistently remained below the observed 3-day APY, ensuring that the rate adjustment constraint remains satisfied. It is only toward the later stages of the observation window that we see a decline in the recommended rate, driven by the sustained smoothing of short-term yield signals, reflected in both the capped maximum rate and a concurrent reduction in measured volatility. ![image - 2025-07-15T174815.428](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/f/f7089e48ce0794bfd91b0cea3cc82b3d43b0f6c2.png) ### **Proposed Parameter Constraints for CAPO Risk Oracle Updates** To maintain the integrity, predictability, and neutrality of the CAPO system, Risk Oracle parameter updates are subject to explicit constraints that govern their frequency and magnitude. These constraints are designed to ensure that CAPO remains a minimally trusted, credibly neutral mechanism, where bounded reactivity to market conditions does not come at the expense of system stability or over-centralized control. **`snapshotRatio` Constraint** : The `snapshotRatio`, which serves as the historical anchor for computing the time-weighted upper bound on exchange rates, can be updated at most once every 14 days and by no more than 5% relative to the prior value. The underlying algorithm will in practice only update once a month in most settings, representing an approximate upper bound of ~60% APR over a monthly horizon, aligned with aggressive but plausible yield scenarios. Importantly, snapshotRatio is simply obtained from the relevant smart contract currently utilized to calculate the exchange rate for a given asset, at a given timestamp snapshotTimestamp, which adheres to the associated time-weighted logic expressed [here](https://governance.aave.com/t/chaos-labs-correlated-asset-price-oracle-framework/16605#motivation-behind-minimum_snapshot_delay-5) (generally 7-14 days prior). **`maxYearlyRatioGrowthPercent` Constraint** : The parameter that controls the annualized rate ceiling can be adjusted once every 3 days, with a maximum 10% relative change per update. This strikes a balance between responsiveness to dynamic yield environments and measured, rate-limited evolution of the enforced cap. | **Parameter** | **Max Relative Change per Update** | **Timelock** | | --- | --- | --- | | `snapshotRatio` | 5% | 14 Days | | `maxYearlyRatioGrowthPercent` | 10% | 3 Days | # **Disclaimer** Chaos Labs has not been compensated by any third party for publishing this ARFC. # **Copyright** Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain) ---
**Author:** ![LlamaRisk](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/llamarisk/32/12865_2.png) [@LlamaRisk](https://governance.aave.com/u/LlamaRisk)\ **Post date:** [July 21, 2025, 8:50pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601/2 "2025-07-21T20:50:35Z")
LlamaRisk supports the proposal of @ChaosLabs for the dynamic calibration of CAPO parameters. The automation of `maxYearlyRatioGrowthPercent` and `snapshotRatio` parameters reduces the operational burden on service providers who would otherwise need to perform frequent manual updates. We acknowledge that the proposed methodology is designed to be a safe enhancement, tracking and updating bounds without fundamentally altering the core, battle-tested CAPO components. The proposal correctly identifies the risks of stale parameters. A widening gap between the real exchange rate and the CAPO upper bound does not create the attack vector in itself, but it significantly exacerbates the potential damage from price inflation or donation attacks. We concur that maintaining tight bounds is crucial for protocol security. At the same time, there is a trade-off, as overly restrictive bounds could lead to a negative user experience. Specifically, if the `maxYearlyRatioGrowthPercent` is set too low, the oracle will cap the asset’s price below its true, organically grown exchange rate. This would cause a user’s collateral to be undervalued by the protocol, unfairly limiting their borrowing power. The document outlines a decision rule for upward adjustments under rate escalation, which preemptively triggers a parameter update if the observed short-term yield velocity suggests the current cap could be breached before the next scheduled update window. This rational approach ensures the system can react to legitimate asset yield growth. While the proposal also mentions a trigger for downward adjustments based on longer-term historical data without specifying it, more transparency regarding the thresholds of this mechanism would also help to reason about the safety of the CAPO adjustments methodology. Finally, the proposal introduces a conservative constraint on the `maxYearlyRatioGrowthPercent`, limiting updates to a maximum 10% relative change with a 3-day timelock. While this rate-limiting is a prudent safety measure against sudden, unwarranted spikes, it may prove insufficient during sustained, aggressive changes in an asset’s yield profile. When a legitimate yield source rapidly increases (e.g., sUSDe yield increases from 10% to 30% APY), the 3-day delay and 10% relative increase cap might cause the CAPO bound to lag behind the true organic growth. This parameter may require observation and potential tuning by governance as the system matures and encounters more diverse market conditions. ### 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. ---
**Author:** ![ChaosLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/chaoslabs/32/6850_2.png) [@ChaosLabs](https://governance.aave.com/u/ChaosLabs)\ **Post date:** [July 22, 2025, 1:58pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601/3 "2025-07-22T13:58:53Z")
The current proposal has been escalated to [ARFC Snapshot](https://snapshot.box/#/s:aavedao.eth/proposal/0x66aa6904f140d56ada880f45c911994c5c6cc20109b55081f508ccdd6417066d). Voting will commence in approximately 22 hours, within the following timeframe: **Start** July 23, 2025 11:31 AM UTC **END** July 26, 2025 11:31 AM UTC ---
**Author:** ![ChaosLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/chaoslabs/32/6850_2.png) [@ChaosLabs](https://governance.aave.com/u/ChaosLabs)\ **Post date:** [July 29, 2025, 8:39pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601/4 "2025-07-29T20:39:11Z")
After Snapshot monitoring, the current [ARFC Snapshot](https://snapshot.box/#/s:aavedao.eth/proposal/0x66aa6904f140d56ada880f45c911994c5c6cc20109b55081f508ccdd6417066d) ended recently, reaching both Quorum and YAE as the winning option with 778k votes. Therefore, [ARFC](https://snapshot.box/#/s:aavedao.eth/proposal/0x66aa6904f140d56ada880f45c911994c5c6cc20109b55081f508ccdd6417066d) has PASSED. As a next step, an AIP will be published for final confirmation and enforcement of the proposal. ---
**Author:** ![system](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/e/e11637c36f45ffa158f2146f5c19438d46e0824d.svg) [@system](https://governance.aave.com/u/system)\ **Post date:** [August 28, 2025, 8:40pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601/5 "2025-08-28T20:40:05Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed. ---
**Author:** ![ACI](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/aci/32/4780_2.png) [@ACI](https://governance.aave.com/u/ACI)\ **Post date:** [February 16, 2026, 2:06pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601/6 "2026-02-16T14:06:52Z")
---
**Author:** ![ChaosLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/chaoslabs/32/6850_2.png) [@ChaosLabs](https://governance.aave.com/u/ChaosLabs)\ **Post date:** [February 16, 2026, 2:27pm UTC](https://governance.aave.com/t/arfc-dynamic-calibration-of-capo-parameters-via-risk-oracles/22601/7 "2026-02-16T14:27:11Z")
As we prepare the AIP to deploy CAPO Risk Oracles into the protocol via Chaos Risk Agents, we’d like to share an update with the community on our initial launch phase and the accompanying on-chain constraint updates. In the initial phase, we will enable CAPO automation on the Ethereum network. The following PriceCapAdapter oracles will be whitelisted: | Asset/Price Cap Adapter | | --- | | [wstETH](https://etherscan.io/address/0xe1D97bF61901B075E9626c8A2340a7De385861Ef) | | [weETH](https://etherscan.io/address/0x87625393534d5C102cADB66D37201dF24cc26d4C#readContract) | | [rsETH](https://etherscan.io/address/0x7292C95A5f6A501a9c4B34f6393e221F2A0139c3) | | [osETH](https://etherscan.io/address/0x2b86D519eF34f8Adfc9349CDeA17c09Aa9dB60E2) | | [ezETH](https://etherscan.io/address/0xF3d49021fF3bbBFDfC1992A4b09E5D1d141D044C) | | [cbETH](https://etherscan.io/address/0x889399C34461b25d70d43931e6cE9E40280E617B) | | [rETH](https://etherscan.io/address/0x6929706c42d637DF5Ebf7F0BcfF2aF47F84Ea69D) | | [tETH](https://etherscan.io/address/0x85968026294b8f8Fb86d6bF3Cda079f9376aD05A) | | [ETHx](https://etherscan.io/address/0xd7b163B671f8cE9379DF8Ff7F75fA72Ccec1841c) | | [LBTC](https://etherscan.io/address/0xf8c04B50499872A5B5137219DEc0F791f7f620D0) | | [eBTC](https://etherscan.io/address/0x03bB418e89B75407585f8198178f253DA3216218) | | [sUSDe](https://etherscan.io/address/0x42bc86f2f08419280a99d8fbEa4672e7c30a86ec) | | [syrupUSDT](https://etherscan.io/address/0x982aC260B5a4e5bCAb6A437e79168390cFbDe70D) | | [sDAI](https://etherscan.io/address/0xf83B85205241c3BCCA0a09D32FaE65c16e0CF236) | The CAPO Risk Agent update struct introduces a merged timelock for both `snapshotRatio` and `maxYearlyRatioGrowthPercent`. In other words, these parameters will be updated together, rather than using separate update paths per-parameter. Given this coupling, we aim to: - Align the `snapshotRatio` timelock to match the existing `maxYearlyRatioGrowthPercent` timelock of 3 days - Tighten `snapshotRatio`’s per-update bound by lowering maxRelativeChange to 3% (from 5%) to reflect the fact that updates are now coupled | **Parameter** | **Max Relative Change per Update** | **Timelock** | | --- | --- | --- | | `snapshotRatio` | 3% | 3 Days | | `maxYearlyRatioGrowthPercent` | 10% | 3 Days |