[ARFC] Aave V3 Caps update Framework

Governance
4

Risk Stewards

For the last months, the volume of on-chain proposals (including mandates for Avalanche) modifying supply and/or borrow caps of assets have skyrocketed.

Given the granularity of permissions on Aave v3, constant updates on caps were expected as quite an important risk-control mechanism.

First with the Fast-Track framework on https://governance.aave.com/t/arc-v3-supply-borrow-cap-management-fast-track-process/8045, and then with direct-to-AIP discussed on this thread, the procedure of updates has been optimized in terms of speed, but still, from our perspective, the community should go one step forward.


During the last ~2 months, for the broad majority of proposals regarding caps updates, the support of the community has been almost unanimous, with 1 or 2 exceptions. The rationale of this is pretty clear: caps updates usually simply depend on the “green light” from the risk providers (Gauntlet @Pauljlei , Chaos Labs @ChaosLabs ). As both providers have historically been in agreement with the updates proposed, the community has just followed that recommendation by supporting on-chain.

Therefore, it seems that the community has important voting overhead in this scenario, which could be almost completely automated and simplified. It is quite common to have a proposal with unanimous support on day 1 of voting but given all other time considerations, execution is 5 days after.


Our proposal is the following:

  • BGD will create a set of smart contracts, limiting the power of even the roles of Aave v3 able to call functions on the PoolConfigurator of the protocol. To start with, we will create a smart contract only able to increase/decrease supply and borrowing caps, potentially with time limitations on how frequently this can be done, the percentage of increase/decrease, and maybe some extra sanity checks. We will refer to them as Risk Stewards from now on.

  • The Aave governance still keeps full control of permissions management: at any point, it is possible to remove all permissions from a Risk Steward.

  • It is possible to set some kind of time-lock in the Risk Stewards, but this would depend on a case-by-case basis, as with the proper sanity checks, potentially it simply doesn’t make sense for updates like supply/borrow caps, given their non-damaging effects.

  • The Risk Steward contracts are focused on automation and speed for changes that mainly depend on the expertise of our providers. To be aligned with that, we suggest the control of the RiskSteward smart contract to be on a 2-of-2 multi-sig, composed by Gauntlet and Chaos Labs. Usually, it is the case that both providers agree on caps updates, or settle on the more conservative recommendation, so this would allow to pass the big majority of updates without governance overhead, and fast. If there is disagreement, the proposal can go on-chain, as currently.
    To be clear, the smart contract will have non-upgradeable logic with all the limitations decided by the community, the 2-of-2 multi-sig will just be the entity able to call the Steward.

    As this is an important decision, we think other options can be considered, but the simplicity of this looks like the optimal path.

  • After a pilot with caps, (maybe even in parallel) expand the Risk Stewards to extra functions of the Configurator, like it could be the freezing mentioned in this post, setting LTV to 0 or others.


We firmly think this will simplify a lot of operational/governance overhead, and given the track record of Gauntlet and Chaos Labs with the community, we think it is the perfect moment to start with it.

10 Likes