Title: [ARFC] Risk Stewards Phase 2: RiskSteward
Authors: BGD Labs @bgdlabs
Expand the scope of Risk Stewards from CapsPlusRiskSteward to a generalised and upgradable
RiskSteward, allowing hardly constrained parameter updates by risk service providers and reducing governance overhead.
Aave is a fully decentralized system controlled by AAVE token holders via governance. This governance is arguably the most active in the space, with more than 400 proposals created due to having a really rich system and several external contributors and/or service providers.
One of the roles of a technical service provider like BGD is to proactively understand technical and operational inefficiencies and propose solutions for the community to optimize them. These inefficiencies, even if initially necessary to have a real decentralized system, create important operational overhead and cost in the community.
For example, every governance proposal involves:
- Pre-AIP governance procedures, like posts and discussion on this governance forum, or Snapshot.
- Creation of the so-called proposal payloads directly by each contributor or via a mechanism like the Skywards program from the ACI service provider.
- Pre-AIP review by BGD.
- AIP creation by proposer (or anybody on its behalf).
- Voting itself, with direct cost (gas) and indirect (attention of voters and understanding).
- On-chain review, currently by BGD, but really soon with Certora.
The optimality of some of those steps like AIP creation has improved significantly with the tooling we created during the last year and a half, and the role of teams like @ACI . However, improvement should be continuous, and we believe the number of proposals related with risk can be reduced for the following reasons:
- We have 2 expert risk teams engaged with the DAO (@ChaosLabs , @Gauntlet ), completely independent from each other.
- On certain risk proposals, there is historically always voting unanimity, given that those proposals are not really polemic, but incremental, small in scope and sometimes (not always) coming from agreement between the 2 risk providers.
- It is technically possible to heavily constraint any update, by using Aave v3 roles, and ad-hoc validations.
After an initial and successful experiment with
CapsPlusRiskStewards, allowing for risk provider to increase caps of asset in constrained manner defined via governance, we think this approach has been proven functional enough to expand it in scope.
In addition, as Aave expands to new networks, the number of governance proposal should be minimised whenever possible, in order to not create big voting overhead/fatigue.
The new RiskSteward we propose follows the same design as the CapsPlusRiskSteward: an smart contract to which the Aave Governance gives
POOL_ADMIN role over all v3 instances, controlled by a 2-of-2 multisig of the risk providers, and heavily constrained on what can do and how by its own logic.
In addition to assume the responsibilities of the current CapsPlusSteward, the new RiskSteward we propose will have the following functionality:
Change collateral risk configurations
The following parameters can be changed:
- Liquidation threshold
- Liquidation bonus
These changes will be constrained by assets and by time (e.g. a maximum of 2% reduction of LTV can be done per week, progressively).
Initially, eMode adjustments will stay outside the scope of RiskSteward, as they are more complex/sensitive. However, we will discuss with the risk providers of the community for if heavily constraint updates could make sense.
Different from the CapsPlusSteward, both up and down changes are allowed, with these changes limited by time per asset (only one cap change every X days) and within a safety range defined by technical service providers.
Additionally, the debt ceiling can be modified, technically being a cap of the system.
Change interest rate strategies
The RiskSteward will be able to do small and progressive adjustments on the reference points of the interest rate strategies, these being:
- Base variable borrow rate.
- Slope 1.
- Slope 2.
- Optimal point (known also as kink).
The constraints will be in the same style as all other types: by asset and time. So the slope 1 could be increased by 1% maximum during 1 week.
It is important that these changes are not oriented to be applied on off-boarding when the increases of IR rates are big.
- Similar to with the first iteration, no time-lock will be applied on updates. The rationale for this is the following:
- Updates already require 2-of-2 consensus between 2 independent parties. It is an assumption that the update is both rigorously tested and independently review to avoid mistakes.
- The goal of an additional time-lock would be to have an additional external party (not the 2 risk providers) to check the changes. One of the objectives of this proposal is to precisely avoid this overhead on governance proposals, so it doesn’t seem logical to keep this.
- Changes will be highly constraint on smart contracts, via validation ranges. Especially as e-mode is not introduced at the current moment, it is an assumption that the risk parameters are resilient enough.
The proposal belongs to the scope of BGD Labs as a service provider to the Aave DAO, described and approved by the DAO HERE.
If the outcome is positive, we will proceed with an on-chain AIP to activate the system.
Copyright and all related rights of this proposal belong to the Aave DAO, represented by the Aave Governance smart contracts.