[ARFC]. Aave Generalized Risk Stewards (AGRS) activation

Development
1

Simple summary

After different changes since the initial Risk Stewards HERE, we present to the community the final proposal for activating this system across all Aave v3 pools.


This version of Aave Generalized Risk Stewards (AGRS) include two instances:

  • The first is a continuation of the previous design, with the parameters recommendation risk provider (Chaos Labs), with constrained capacity to modify all type of risk parameters on Aave. As extra protection, during the initial period of updates (estimated 1-2 months), BGD Labs will join the Risk Council multi-sig in order to add an additional layer of security review. Chaos Labs will still be the only decision maker for recommendations as defined on their professional scope with the DAO, with us BGD just being a security contributor.
  • The second is a pilot version to automate interest rate updates of assets (starting with WETH on Aave v3 Lido Ethereum), based on the newly released risk infrastructure technology Edge, by Chaos Labs.

The repository can be found on https://github.com/aave-dao/aave-v3-risk-stewards.



Motivation

The base motivation of Aave Generalized Risk Stewards (AGRS) is still the same as the previously proposed version HERE. After a successful initial iteration for cap updates and different GHO parameters using the Stewards pattern, Aave is prepared to generalize the solution and improve its operational efficiency and reactivity to the market.

Regarding the pilot integration of AGRS with Chaos Labs new Edge infrastructure, it has the following rationale:

  1. Whenever aligned with other strategic and technical aspects, Aave should benefit from infrastructure built by service providers, in this case, Chaos Labs.
  2. This pilot will be very non-invasive and with only positive outcomes, as the AGRS layer will guarantee that only acceptable interest rate recommendations will reach the Aave protocol, while ideally having a way more dynamic rate.


Specification


1. AGRS + Risk provider

The main version of AGRS will follow the specifications described in the previous Risk Stewards post HERE, which can be summarised in the following:

  • The following risk params could be changed by the RiskStewards:
    • Supply Caps
    • Borrow Caps
    • LTV
    • Liquidation Threshold
    • Liquidation Bonus
    • Debt Ceiling
    • Base variable borrow rate
    • Slope 1
    • Slope 2
    • Optimal point
    • CAPO configurations
  • For each configuration type, there will be a minimum delay associated with how frequently the AGRS can be used, named minDelay. Ex. after increasing LTV by 5%, the operator of the AGRS (risk provider) must wait a minimum of minDelay before either doing any additional change.
  • Each configuration type will have an associated percentage-based constraint (in basis points), indicating how much the parameter can be changed via AGRS compared to the live value on Aave v3. These constraints (maxPercentChange) can be of 2 types:
    • Absolute. E.g. for LTV a 5_00 maxPercentChange means that is possible to change the LTV value by +/- 5_00 basis points, or 5%, compared to the current live value. So if the current LTV is 65%, it is possible to change up to 70% or down to 60%.
    • Relative. E.g. for Supply Cap a 50_00 maxPercentChange means that is possible to change the Supply Cap value by +/- 50_00 basis points, or 50%, proportional to the current live param. So if the current Supply Cap is 1’000’000 WETH, it is possible to change it up to 1’500’000 WETH, or down to 500’000 WETH.
  • The system allows to restrict assets for AGRS to not apply changes, to be used for example with GHO.
  • The only entity enabled to use the AGRS will be the assigned risk service provider, currently Chaos Labs. As a temporary security precaution, and to avoid introducing a timelock (given that the system should be resilient enough without it), BGD will review the params updates proposed for correctness, but without any influence on the recommendation itself.


To start with, this component of AGRS will have the following configurations (from recommendations of the risk provider of the community):

Parameter Percent change allowed minimumDelay
Supply and Borrow Caps 100% (relative change) 3 days
Debt Ceiling 20% (relative change) 3 days
CAPO dynamic cap 5% (relative change) 3 days
CAPO stable cap 0.5% (relative change) 3 days
Base Variable Borrow Rate 0.5% (absolute change) 3 days
Slope 1 0.5% (absolute change) 3 days
Slope 2 5% (absolute change) 3 days
Optimal Point (Kink) 3% (absolute change) 3 days
Loan to Value (LTV) 0.25% (absolute change) 3 days
Liquidation Threshold 0.25% (absolute change) 3 days
Liquidation Bonus 0.5% (absolute change) 3 days

The principles for them in the initial phase are:

  • Still highly constraint in percentages and time, in order to not deposit too much trust to start with.
  • Similar as with caps updates, all usage of stewards will be previously disclosed on the Aave governance forum, by a framework to be defined by Chaos Labs, the risk provider in charge.

Additionally, the only blacklisted asset will be GHO on Ethereum, given that changes on it are usually done by the ALC (Aave Liquidity Committee) via the GHOSteward, or directly with governance proposals.



2. AGRS + Edge Infrastructure by Chaos Labs

Days ago, the Aave risk service provider Chaos Labs announced Edge, a new product innovating on the risk infrastructure ecosystem.

This new system directly addresses a challenge for risk recommendations on Aave: how to connect as seamlessly as possible the platform of parameters recommendation run by Chaos during the last years for Aave, with the Aave protocol.

With this activation of AGRS pending, after evaluating the solution, and due to the already long contribution history of Chaos Labs, we decided that is a good opportunity to test out the usage of Edge for a specific parameter: Aave rates configurations for WETH on v3 Lido Ethereum.

This model will use another instance of AGRS (exactly the same codebase as the other model), but with the following constraints:

  • The AGRS + Edge instance will only have configurable rate-related parameters: base variable borrow rate, Slope 1, and Slope 2.
  • Recommendations of these parameters will be submitted to a risk oracle smart contract, from the Edge off-chain infrastructure.
  • Between the risk oracle smart contract and the AGRS contract, there will be a very thin middleware AaveStewardsInjector , which will have the following logic:
    • Will take recommendations from the Edge Risk Oracle side and propagate them to the AGRS contract.
    • Enforce that only the WETH asset can be acted upon.
    • Given the protections (percentage constraints and time delay) on the AGRS side and that it is an assumption that risk recommendation will be the time correct on the Edge Risk Oracle, the propagation will be permissionless.

The following is a simple diagram on how the system works.

agrs-plus-edge

Regarding the configurations of the AGRS + Edge instance, will be the following (for only WETH on v3 Lido Ethereum to start with):

Parameter Percent change allowed minimumDelay
Base Variable Borrow Rate 0.5% (absolute change) 1 days
Slope 1 0.5% (absolute change) 1 days
Slope 2 5% (absolute change) 1 days
Optimal Point (Kink) 3% (absolute change) 1 days

Security

In addition to our internal review and testing procedures, the AGRS have been reviewed by Certora, and the report can be found HERE.


Next steps

  1. In parallel with this post, we will create an ARFC Snapshot for the pre-approval of AGRS activation.
  2. Once/if the ARFC Snapshot passes, we will proceed with an on-chain governance proposal for the activation of the system.
4 Likes
2

As the final step before the on-chain AIP, we have created the ARFC Snapshot vote to pre-approve the activation, here

https://snapshot.box/#/s:aave.eth/proposal/0x4809f179e517e5745ec13eba8f40d98dab73ca65f8a141bd2f18cc16dcd0cc16

The defined risk parameters could be submitted for changes before AIP, which will be disclosed in advance in this thread.

2 Likes
3

Dynamic WETH Borrowing Rates using AGRS and Edge on Lido Market

Summary

As AGRS + Edge activation goes to AIP, we propose a pilot to demonstrate the capabilities of the system. This proposal introduces an interest rate strategy oracle for WETH on the Aave Lido Market on Ethereum. Utilizing BGD Labs’ new risk steward contract, the risk oracle will adjust WETH borrowing rate parameters daily in response to changes in Lido’s staking rewards. The primary goal is to ensure that the WETH borrowing cost remains below Lido’s staking rewards, maintaining the profitability of the wstETH/WETH looping strategy for users.

The pilot program for this implementation will last for one month. At the end of this period, a historical analysis will be published, covering metrics such as WETH utilization and borrowing costs. Based on the outcomes, there will be plans to expand the solution to other assets if the pilot demonstrates positive results

Motivation

The Aave Lido Market was established to support leveraged staking strategies, enabling users to supply wstETH as collateral and borrow WETH to loop their positions. This strategy has proven beneficial for both the Aave and Lido ecosystems, boosting liquidity and user engagement. However, the profitability of this looping strategy depends on a key factor: the borrowing cost of WETH must stay below Lido’s staking rewards.

Lido’s staking rewards, which rebase daily, fluctuate and directly impact the incentive for users to participate in the looping strategy. When staking rewards decrease, the appeal of looping diminishes, potentially leading to underutilization of the WETH pool. Although underutilization may cause borrowing rates to drop, the strategy may still fall short of profitability without further adjustments, limiting user interest. Conversely, when staking rewards increase, more users are drawn to the looping strategy, driving up WETH pool utilization.

Utilization Rate and Interest Rate Model

As utilization approaches the Optimal Utilization point and shifts into Slope2 of the interest rate model, even slight increases in utilization can sharply spike borrowing costs due to the steeper slope. This heightened volatility in borrowing rates can make the looping strategy unpredictable and deter user participation. Therefore, to sustain the strategy’s appeal and viability, a mechanism is needed to adjust WETH borrowing rates in sync with Lido’s staking rewards and pool utilization. This alignment helps to keep borrowing costs in line with staking rewards while mitigating rate volatility.

Influence of Liquid E-Mode Configurations

The enhanced Liquid E-Mode configurations in the Lido Instance create additional demand for wstETH borrowing, encouraging users to pursue looping strategies for wstETH interest accrual. This growing demand impacts ETH interest rates, leading to upward rate pressure that increases what users are willing to pay. To stabilize rates in this environment, the risk oracle should consider the wstETH supply rate, helping to moderate potential volatility and sustain consistent lending conditions.

1. Edge - Risk Oracle

  • The risk oracle will retrieve the current Lido staking rewards rate once a day, aligning with the stETH rebasing schedule.
  • The new Slope1 will be set to Lido’s staking rewards minus a predefined buffer (initially 0.5%) to account for market volatility and incentives.
  • The initial buffer of 0.5% provides a safety margin to accommodate minor fluctuations in staking rewards and market conditions.
  • The buffer may be adjusted based on the level of incentives and market feedback to optimize profitability and risk management.
  • Update Frequency:
    • Adjustments will occur once daily to align with stETH rebasing.
  • Parameter Adjustments:
    • While the risk oracle has the technical capability to adjust the entire interest rate strategy (base rate, optimal utilization, slope 1, slope 2) under the constraints of the risk stewards, the most updated parameter will be slop 1.
  • Monitoring and Transparency:
    • All adjustments and calculations will be transparent and auditable, with data available for community review.

2. AGRS

  • The risk steward contract will enforce the constraints:
Parameter Percent change allowed minimumDelay
Base Variable Borrow Rate 0.5% (absolute change) 3 days
Slope 1 0.5% (absolute change) 3 days
Slope 2 5% (absolute change) 3 days
Optimal Point (Kink) 3% (absolute change) 3 days
5 Likes
4

It will be interesting to see how this system works and I would love to see an analysis after a few days/weeks.

1 Like
5

Following the positive Snapshot outcome, we have created the first on-chain governance proposal to activate the manual AGRS system (AGRS + Risk provider), while the AGRS + Edge proposal is being finalized.

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=197

1 Like
6

As an update to the community, proposal 197 has been approved by governance and executed, enabling the manual AGRS (AGRS + Risk provider) system for all Aave instances.



Additionally, proposal 200 to enable the automated AGRS (Edge by @ChaosLabs + AGRS) has been created, with voting starting in approximately 21 hours.

Participate :ghost:
https://vote.onaave.com/proposal/?proposalId=200

3 Likes
7

As an update to the community, proposal 200 has been approved by governance and executed, enabling the automated Edge + AGRS for WETH interest rate updates on v3 Lido Ethereum.

As expected, the first slope1 update was successfully executed yesterday on the following transaction https://etherscan.io/tx/0x02835f31ba02b400e6c791f2a7d67992c7f55ca7ad3dd9d9d37e74cc529233c5. During the following days, we will closely observe the updates in the production system.

1 Like