[ARFC] Supply and Borrow Cap Risk Oracle Activation

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:

  1. Manually identify a necessary cap assessment and potential alteration through internal alerting systems.
  2. 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.
  3. 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.
  4. Obtain the calldata and create a transaction for the cap change.
  5. 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:
      1. 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.
      2. 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.
  • 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

3 Likes

We thank @ChaosLabs for spearheading this initiative and proposing further integration of an automated Risk Oracle framework powered by Edge Infrastructure. This proposal represents a meaningful step toward enhancing the efficiency and responsiveness of supply and borrow cap updates within the Aave Protocol while removing some operational overhead.

We’re generally in favor of Edge integration within Aave and appreciate the phased approach and conservative boundaries (e.g., the 30% cap increase limit) outlined in the proposal.

Our team has been closely monitoring the changes implemented during the WETH borrowing rate pilot project on the Prime (formerly Lido) instance. To date, no significant issues have been observed. We would appreciate it if @ChaosLabs could share the lessons they learned during this trial.

While the automation of cap updates reduces operational overhead, it also increases reliance on centralized components, such as the Edge Infrastructure and the methodologies employed. This introduces centralization risks that must be carefully balanced. In a perfect world, every decision could be independently verified by users. As such, we will continue to serve as watchdogs, maintaining our own methodologies to assess and challenge decisions if needed.

1 Like

The current proposal has been escalated to ARFC Snapshot. Voting will commence in 24 hours, within the following timeframe:

Start
Feb 3, 2025 · 11:10 PM UTC

End
Feb 6, 2025 · 11:10 PM UTC

After Snapshot monitoring, the current ARFC Snapshot ended recently, reaching both Quorum and YAE as winning option, with 759.4K votes.

Therefore, [ARFC] Supply and Borrow Cap Risk Oracle Activation has PASSED.

Next step will be the publication of an AIP for final confirmation and enforcement of the proposal.

As Michigan Blockchain, we support the proposal to introduce to Aave 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. Currently, supply and borrow cap updates are manually triggered.

Since October 2024, there have been 178 manual cap updates and 49 detailed analyses across Aave markets. The current update process includes recurring tasks like manually running supply and borrow cap risk simulations, determining the optimal increase/decreases, creating forum posts, etc. This highlights the operational intensity of the current method; it is a resource intensive process in terms of human labor. Also, this time intensive process leads to delays in cap updates that leads to inefficiencies in Aave markets.

The new Risk Oracle promises to automate these updates by utilizing a simulation engine that has already been used for manual cap adjustments for years, so it has already been tested on this platform. This new automated Risk Oracle framework will trigger cap increase/decrease simulations when the cap utilization surpasses or falls below certain thresholds, and then determine the optimal new cap and publish it to the contract.

In short, it will eliminate most of the manual tasks that were done by risk analysts in determining the new caps. We support this proposal because we believe that this new process will be more resource efficient as it requires less human input, and also since it will lead to quicker supply/borrow cap changes as a result of automation. Also, the fact that the simulation engine has been previously tested for cap changes is another reason why we are optimistic about this proposal.

A concern to be had is the fact that there will be increased centralization as a result of relying on a centralized entity that is the Edge Infrastructure. However, we believe that the positives of this change overshadow the risk of centralization.

-Kerem Dillice and nsks