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.

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