BGD. Risk Steward Phase 1: CapsPlusRiskSteward

Risk Smart Contract
1

TL;DR

Following the initial concept on https://governance.aave.com/t/arfc-aave-v3-caps-update-framework/11937/4, propose to the community a path forward on the idea of Risk Stewards: smart contracts for risk providers to change parameters with strict on-chain validations defined in advance.


Risk Stewards: a progressive approach

Aave v3 enables the addition of new features concerning permissions granularity, due to its system of roles: RISK_ADMIN, POOL_ADMIN, EMERGENCY_ADMIN, etc.

A Risk Steward is a smart contract that receives one or more of the aforementioned roles from the Aave governance, and by acting as an extra layer of indirection/validation, allows to introduce extra logic to control strictly what the “owner” of the Steward can do.

Technically, it is relatively simple for the community to give granular control over the management of all different parameters to Risk Stewards, but the complexity comes in terms of decentralization and self-protection of the protocol, even from entities that should be trustable, like service providers.

Therefore, we propose to start with the simplest Risk Steward case, but that will already simplify community voting overhead and operations: increase of supply and borrow caps.


CapsPlusRiskSteward

The initial Risk Steward we propose will work the following way:

  • A CapsPlusRiskSteward smart contract will be created per each Aave v3 instance, ownable.
  • The owner will be a 2-of-2 multisig: 1 signer being a representative of Gauntlet (@Pauljlei), and another from @ChaosLabs.
  • The owner will be able to call functions with permissions to increase supply & borrow caps of all assets in Aave v3 pools.
  • The functions to increase caps will have the following limitations, enforced on-chain:
    • The cap to increase should be strictly higher than the current one.
    • For each asset, only 1 increase is allowed every 5 days.
    • The supply cap can never be increased above 50% of the current one.
    • The borrow cap can never be increased above 50% of the current one.
  • No timelock on changes, as this is focused on operational optimization, and an increase in caps should not hurt the protocol.


From a design perspective, the objective of this initial iteration is not to have a perfect system, but a workable pilot with no downside, on which the community can iterate depending on the needs.
The procedure around the usage of this Steward is something that we leave for the risk providers to decide, but we think it should be compatible with the current practices and transparency, like informing the community in advance before doing changes.

FAQ


2-of-2 multisig? What if one of the members loses access to the signer wallet?

  • Not a problem. The Aave governance is still the only entity that can grant and remove roles from other addresses. In that kind of situation, a new Steward controlled by a new 2-of-2 can be deployed, permissions removed from the previous, and granted to the new one.

How much trust will be given to a Steward and the entity in control of it?

  • This is a trust-minimized system. The actions the entity controlling it can execute on the Aave protocol are exclusively those allowed by the logic of the Steward smart contract itself.

What if the entity controlling the Steward decides to upgrade its logic?

  • This first Steward (and highly probably applicable to all future ones) will be IMMUTABLE, not possible to upgrade its logic.
    The entity controlling it can’t do anything apart from what is defined in the smart contract.

Why not include caps decrease too?

  • Caps decrease could represent in practice a freezing of a pool. It is something to consider in the following stages, but we consider it a way more complex decision compared with the increasing scenario.

Why not include more entities of the community?

  • In this model, trust minimization is managed in the implementation phase of the Steward and on the governance vote to give to it the required roles.
    The community has explicitly selected 2 risk providers, so adding extra parties in for example a 2-of-3 multisig would give quite important role to the extra actor in deciding the outcome of some changes.

But sometimes Gauntlet and Chaos Labs have disagreed on recommendations. Will the community get locked when that happens?

  • It is perfectly healthy for risk contributors to disagree, as they have different underlying models and tools. Whenever that happens (not so frequently with caps increases), the current mechanism of on-chain governance proposal can be applied, only sacrificing speed.

Next steps

As always, we would like to receive any feedback from the community, apart from what was commented in the initial post.
Afterward, targeting the end of this week, we will create a Snapshot vote, and if the outcome is positive, will be followed by the implementation of the smart contract and the on-chain proposal that will grant RISK_ADMIN to it, in all the networks.

16 Likes
2

As a voter, we are excited by this.

Looking at the recent activity within Aave Governance, ~80% of votes are risk related. This leads to burnout from voters and is more arduous for risk managers quickly and effectively manage the protocol.

Enabling “Risk Stewards,” seems to shift the responsibility away from the community, allowing teams such as ourselves to focus on more strategic and growth-focused initiatives.

We support this initiative - and applaud the work by BGD to ensure a lean, simple, yet secure approach to more effectively manage supply and borrow caps.

6 Likes
3

The ACI supports the implementation of Risk Stewards.

Although the “One-AIP-a-Day” concept is entertaining, we concur with @fig regarding the potential “voter fatigue” arising from the new Aave DAO governance rhythm. As one of the primary contributors and culprits of the high # of AIPs, we embrace this pilot program, recognizing the importance of prioritizing high “governance-value” AIPs over routine “mechanical upgrades” to the protocol management.

Nonetheless, we still remain committed to publishing a substantial number of high-governance-value AIPs!

No rest for the frens building the future of France! :stuck_out_tongue_winking_eye:

3 Likes
4

As pointed out by @fig, a significant proportion of proposals on Aave relate to parameter adjustments, and due to their frequency it can attract uninformed decisions or proposals failing to achieve quorum. To further enhance the governance structure of Aave, I strongly advocate for minimizing governance and a transition towards expertise-based governance, beginning with a small pilot testing.

Regarding the Risk Stewards program, I have a few questions:
Firstly, what is the anticipated duration of the pilot program?
Secondly, how should we reflect on the outcomes of the program after the testing period?

5 Likes
5

Thanks for putting forward this proposal @bgdlabs.

Chaos Labs fully supports the pilot, starting with a limited set of permissions to enable cap increases. Additionally, we recommend allowing up to a 100% increase rather than limiting increases to 50% of the current cap. We have witnessed several cases where the caps can fill up quickly due to high demand, and a 50% cap increase may restrict growth opportunities, especially given the 5-day window between increases, which we believe is a good measure. This can be especially important for newly listed assets, which are sometimes launched with lower caps.

4 Likes
6

I would assume “until amendments are needed or community doesn’t like the outcome”.

I guess success in this case would be:

  • a decrease in (meaningless) governance proposal
  • less situations in which caps are fully utilized & risk teams not being opposed a change. There should always be a clear reason on why a cap is utilized 100% that is not “aip is pending” or “aip is not yet created”.

With the same argument i guess you could argue against the 5 day delay? cbETH cap was filled in hours not days.
I think a 50% increase can be sufficient initial approach. While the fast-track allows up to 100% increase, realistically changes going through the aip process take rather 10 than 5 days due to various timing constraints.
Staying with the example of cbETH in the 10 days it took from arfc to onchain execution you could have in fact done 2 50% increases ending up with 30->45->67.5k (so even more than the current 60k 100% increase).

That said i’m not opposed 100% increase actually, just not sure if it’s needed as in most cases a 50% increase every 5 days should still be perfectly fine.

5 Likes
7

In addition to @sakulstra answers, an extra clarification.
We use the term “pilot” or “phase 1” to refer to what hopefully will be the first step of a scope that will be expanded in the future. So there is not any type of duration; the CapsPlusRiskSteward will be just another component of the Aave ecosystem that can be improved in the future, or removed if for some reason doesn’t make sense anymore.

2 Likes
8

Precisely these types of alternative options are what the community can weigh on this discussion and the upcoming Snapshot.
From our perspective, 100% is perfectly reasonable too, and can be included as an alternative.

Additionally, the limitations of increases are something that definitely can be done better in the future, for example by having a more complex approach based not only on the previous value of the cap, but on its magnitude.
For example, it is not the same increasing 100% of the supply cap if the previous value was 1B (USD reference), compared with if it was 100k. The smart contract could include this more dynamic validation, but it will slow down a bit more the release.

4 Likes
9

Following the community procedure, we have created an Snapshot vote to decide the path forward, with voting starting tomorrow and opened for 5 days https://snapshot.org/#/aave.eth/proposal/0xc882bf5f0f0f801591bfd5f0273388ea154654220f472aa4a06fd1fe6b94bb53

3 Likes
10

Following up on this project, after the approval of the community we have finished the implementation of the initial CapsPlusRiskSteward, available on https://github.com/bgd-labs/aave-helpers/blob/master/src/riskstewards/CapsPlusRiskSteward.sol. In addition to that, we have prepared some utilities to facilitate the interaction of the risk providers with said steward, via the 2-of-2 multisig controlling it.

The next steps will be:

  1. Once the 2-of-2 multisigs are setup on all networks, we will deploy one instance of the CapsPlusRiskSteward on each one of them.
  2. We will submit a governance proposal to grant RISK_ADMIN permission on all networks with Aave v3 instances.
5 Likes
11

After the deployment of a CapsPlusRiskSteward smart contract per network, controlled by 2-of-2 Safes with @Gauntlet and @ChaosLabs as signers, we have created governance proposal 234 to give RISK_ADMIN role to each one of the stewards, which factually will activate them.

All the details can be found in the proposal description and associated links. Voting will start in approximately 24h.

Participate :ghost: !

https://app.aave.com/governance/proposal/?proposalId=234

5 Likes