Summary
Building on the recent integration of Aave Generalized Risk Stewards (AGRS), this proposal introduces an automated Risk Oracle framework, powered by Edge Infrastructure, to streamline and enhance the efficiency of Supply and Borrow cap updates within the Aave Protocol.
The framework is built around two core components: (1) algorithmic, simulation-based assessments continuously conducted to evaluate cap exposure across all markets, and (2) defined cap utilization thresholds that trigger risk simulations to determine whether cap adjustments are necessary. Operating under stricter constraints than those currently permitted at the Risk Steward contract level, this system introduces no additional permissions while significantly improving the observability and responsiveness of risk management. The initial deployment is planned for Arbitrum to start, to be expanded to other chains in the future.
Motivation
Current Cap Update Process
The current implementation of the Risk Steward contract allows for the manual, periodic updating of Supply and Borrow caps, generally performed in response to market demand. Such an implementation allows for the risk/reward of respective asset exposure to be quantified and assessed in a much quicker fashion as opposed to the traditional governance mechanisms in place. This creates the ability to perform cap increases every three days by up to a 100% relative change, alongside functionality to react to adverse events or liquidity crunches through cap exposure decreases to any nominal value.
While the implementation of the Risk Steward contract allows such risk configurations to be optimally managed in a more efficient manner, this manual integration creates significant operational overhead to maintain the state of relative demand across all Aave markets. This is currently performed through the following process:
- Manually identify a necessary cap assessment and potential alteration through internal alerting systems.
- Run internal supply and borrow cap risk simulations for the asset, determining the optimal increase or decrease with respect to the defined constraints at the Risk Steward level.
- Create a forum post outlining the imminent cap change(s) and the associated rationale for such increases through a risk report that references the state of the asset’s Aave market.
- Obtain the calldata and create a transaction for the cap change.
- Execute the cap change after a final security verification by BGD (2/2 Safe)
The high volume of updates, combined with the manual triggering of supply and borrow cap simulations, written analyses, and coordination across multiple service providers, often leads to delays in implementing cap increases. These delays can hinder potential growth opportunities for underlying assets that might otherwise contribute significantly. Additionally, the reliance on manual monitoring to address liquidity crunches for specific assets and chains adds further inefficiency. For context, since October 1, 2024, a total of 178 manual cap updates and 49 written analyses have been conducted across all instances.
Edge - Risk Oracle
The Supply and Borrow Cap Risk Oracle automates the generation and application of cap recommendations for Aave, leveraging a proven simulation engine that has successfully supported manual cap adjustments through the Risk Steward for years. Depending on whether the cap utilization surpasses or falls below specific thresholds, either the cap increase or cap decrease simulation is triggered, in addition to the frequent time-based triggering of simulations for all respective markets. The simulation then determines the optimal new cap value based on a range of risk metrics. Once calculated, the updated cap is automatically published to the contract, where it is directly applied to the market, updating the cap value in real-time.
The following section provides a more detailed technical overview.
- Cap Increases
- The risk oracle is triggered when the median cap utilization exceeds the defined utilization threshold for a full day.
- The simulation stress-tests larger supply and borrow caps, taking into account the current state of the protocol, user positions, and external factors such as liquidity availability on the chain and the general circulating supply.
- Parameter Adjustments:
- Supply Cap: Recommend a new supply cap, if the risk allows.
- Borrow Cap: Recommend a new borrow cap, constrained by its ratio to the current supply cap. If the current supply cap does not support an increase, a new supply cap will be recommended (if the risk allows) to support the new borrow cap.
- Cap Decreases
- Decreasing cap exposure through the risk oracle is triggered with two different components of the model:
- Dynamic decreases resulting from asset liquidity depreciation and/or an unhealthy set of positions within the market. The simulation stress-tests the current supply and borrow caps for all assets on a weekly cadence, taking into account the current state of the protocol, user positions, and external factors such as liquidity availability on the chain and the general circulating supply. If the current nominal cap value is deemed too risky, the simulation will determine the optimal decrease value as a function of the aforementioned components.
- Deterministic decreases as a result of low cap utilization within a respective market when the monthly utilization falls below a specified threshold. To ensure a conservative approach, utilization must stay below these thresholds for at least 90% of the time. In such cases, the cap will be halved, leading to a maximum updated utilization of 50% for Supply Caps and 30% for Borrow Caps. The cap can only be reduced down to a fixed minimum value.
- Parameter Adjustments:
- Supply Cap: Recommend a new supply cap, depending on the associated risk defined in (1), and ensuring it can still support the current borrow cap in (2)
- Borrow Cap: Recommend a new borrow cap.
- Decreasing cap exposure through the risk oracle is triggered with two different components of the model:
- Update Frequency:
- Adjustments are made when utilization or the general market state requires it, with a minimum of 3 days between updates.
- Monitoring and Transparency:
- All adjustments will be transparent and auditable, with data available for community review.
Risk Oracle Permissions
The risk steward contract currently enforces the following constraints:
Parameter | Percent change allowed | minimumDelay |
---|---|---|
Supply Cap | +100% (increase) | 3 days |
Borrow Cap | +100% (increase) | 3 days |
The proposed modification to the current flow of cap updates automates the process of leveraging our currently manually utilized risk simulations to increase such caps. As such, in the proposed specification, the associated percent change allowed will be set at a more conservative +30%, with an equivalent minimum delay adhered to at the Risk Oracle level. All supply and borrow cap update events emitted can be observed in our Risk Oracle dashboard here. As this system will minimize the amount of manual overhead for each cap increase performed, we aim to provide periodic performance reports for the DAO.
Through the integration on Arbitrum, the following 15 markets fall under the specification:
Chaos Labs Arbitrum Risk Dashboard
Growth/Speculative Assets
While the Risk Oracle is designed to establish a generalized system for automated cap increases within the proposed constraints, certain speculative, growth-oriented assets—such as ezETH on Arbitrum—cannot be standardized in this manner. These assets inherit external ad-hoc inputs, preferential considerations, and limiting risk configurations at the protocol level. As a result, the Risk Oracle will not be used to recommend cap increases for such assets. Instead, they will continue to be manually assessed using the existing method employed through the Risk Steward contract. Additionally, manual stewards will remain as a fallback mechanism when deemed necessary, ensuring continuity with the current implementation.
Disclaimer
Chaos Labs has not been compensated by any third party for publishing this ARFC.
Copyright
Copyright and related rights waived via CC0