[ARFC] BGD. Risk Steward Phase 2: RiskSteward

Development
1

Title: [ARFC] Risk Stewards Phase 2: RiskSteward

Authors: BGD Labs @bgdlabs

Date: 2024-01-15


Simple Summary

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.


Motivation

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.


Specification


The new RiskSteward

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:

  • LTV
  • 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.



Change caps

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.



Misc considerations

  • 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.

Disclaimer

The proposal belongs to the scope of BGD Labs as a service provider to the Aave DAO, described and approved by the DAO HERE.


Next steps

We encourage the community to provide feedback, especially the engaged risk providers (@ChaosLabs , @Gauntlet ), and after some days, we will create the ARFC Snapshot.

If the outcome is positive, we will proceed with an on-chain AIP to activate the system.


Copyright

Copyright and all related rights of this proposal belong to the Aave DAO, represented by the Aave Governance smart contracts.

7 Likes
2

Continous reviews like this make the DAO better and more efficient.
With two risk provider it makes sense to give them access to these features and increase response time, but also reduce AIP “spamming”. With limitations (like 2% reduction of LTV per week) the DAO is safe no “strong” changes will be made and user are safe.
Supportive of this ARFC.

4 Likes
3

The following is a joint recommendation from Chaos Labs and Gauntlet after both teams aligned on the recommended configuration and boundaries for the various risk parameters

Summary

We strongly support this proposal, which aims to minimize significant governance involvement, building on the successful implementation of the CapsPlusRiskSteward.

Since the Risk Steward’s introduction in late May 2023, Chaos and Gauntlet have proposed over 65 adjustments that would have otherwise required a full governance cycle. This approach has enhanced the DAO’s ability to dynamically and efficiently adjust caps during this period, reducing significant overhead from the DAO’s technical provider and delegates.

We recommend applying a similar method to other risk parameters, with the community determining the limits of these changes, ensuring oversight of the process.

A guiding principle in our recommendations below is balancing the efficiency of the parameter-setting process with community oversight and control. We aim to optimize the speed and efficiency of implementing “risk-off” updates while ensuring that decisions that are “risk-on” are determined by the community, following the standard governance process.

Proposed Configuration and Boundaries:

  • Supply and Borrow Caps:
    • Increase: Up to 100% of the current cap with a 5-day interval between updates, similar to the existing procedure.
    • Decrease: Up to 100% of the current cap, effectively allowing risk service providers the option to temporarily freeze a market. This is a key change which we invite the community to express their opinion on. Should the community support this recommendation, we propose removing the 5-day interval to ensure updates can be made promptly in any high-risk situation.
  • Debt Ceiling:
    • Both increase and decrease up to 100% of the current debt ceiling.
  • Interest Rate Parameters:
    • Base Variable Borrow Rate: +/- 2%
    • Slope 1: +/- 2%
    • Slope 2: +/- 20%
    • Optimal Point (Kink): +/- 10%
  • Collateral Risk Parameters:
    • When we think about the scenarios where LT/LTV/LB parameters need to be changed quickly, it’s typically in risk-off scenarios such as setting LTV to 0 and deprecating an asset (decrease LT to 0 gradually, where standard governance intervals are overly cost-intensive). Since decreasing LT can cause liquidations, the community may not want to include this capability, since this power can’t be isolated purely to deprecation processes. We do recommend posting a snapshot for using the Risk Steward to be able to decrease LTV, since this does not cause liquidations and is an important risk-off measure.
    • Minor increases to LT/LTV/LB are risk-on measures that provide minimal short-term capital efficiency and should require community notice and consensus.
    • Based on these considerations, our current recommendation is to authorize the Risk Steward to only make unrestricted LTV reductions without specified intervals as the only collateral risk parameter Risk Steward capability.
4 Likes
4
  • Decrease: Up to 100% of the current cap, effectively allowing risk service providers the option to temporarily freeze a market. This is a key change which we invite the community to express their opinion on. Should the community support this recommendation, we propose removing the 5-day interval to ensure updates can be made promptly in any high-risk situation.
  • Debt Ceiling: Both increase and decrease up to 100% of the current debt ceiling.

I think currently the guardian has capabilities to freeze a reserve and set ltv0 which are much more direct measures in a high risk situation.
Therefore I think limiting decreases to 50% would be a more conservative, but sufficient approach.
In essence it would allow the steward to revert a previous 100% increase.

Since decreasing LT can cause liquidations, the community may not want to include this capability, since this power can’t be isolated purely to deprecation processes.

I think from observing history, the steward having the capabilities to reduce LT within very tight bounds might be a big plus. In the past LT reductions often were quite brutal and in some cases drove healthy positions into liquidatability within a single governance proposal. By giving the steward the possibility to reduce lt by 1%(or even less) every x days, i imagine a much more gentle offboarding & derisking process could be possible in cases where fast offboarding doesn’t matter to much.

5 Likes
5

@sakulstra already said what i was about to say. Adjusting these 2 things would be great and still give the risk stewards enough power and capabilites to be fast and dynamic when the market is calling for it.
Especially the approach with LT like we have seen with CRV where risk provider lowered it 1% every week while monitoring was great. While also not liquidate too many people at the same time.

2 Likes
6

If the community is in favor of the risk stewards being able to update the LT, we recommend setting this limit at 1% and only allowing decreases. We agree this would allow for a more gentle offboarding and derisking process for certain assets.

The Guardian does have the capability to freeze an asset. That said, the Guardian would require many signatures to enact swift action. Currently, the Risk Steward does not have the capability to reduce supply and borrow caps to 0, or to set LTVs to 0.

An example of where these capabilities would be useful is in our recent Recommendation to freeze and set LTV to 0 on low-cap Aave v3 Polygon collateral assets. Gauntlet and Chaos would be able to delist low-cap assets by first freezing and setting LTVs to 0, and then gradually decrease LTs and update IR curves, all through the Risk Steward, after consensus from the community.

In the case where the community chooses not to add freezing capabilities to the Risk Steward, we still recommend being able to decrease an asset’s caps by 100%. Consider a situation where we increase the cap 100%, and then 3 days later the asset poses severe risk. We would only be able to revert the initial increase and would essentially be unable to freeze supplies or borrows to the market.

2 Likes