[ARFC] Aave V3 Caps update Framework

[MarcZeller]

• —

Title: [ARFC] Aave V3 Caps update Framework

Author: @marczeller - Aave Chan Initiative
Date: 16-02-2023

• —

Summary:

This ARFC proposes a direct to AIP vote for cap changes or FreezeReserve() implementation if the following conditions are met:

• The proposal is provided by a risk service provider or has received feedback from at least one risk service provider team.
• The proposed cap change is not greater than a 100% increase of the current cap or the implementation of a cap.
• The cap is being decreased.
• The AIP is implementing a FreezeReserve().

For other situations, the normal governance process is applicable.

This framework is intended for All V3 liquidity pools. Relative to freezing reserves, this framework is intended for all Aave pools.

Motivation:

Supply and borrow caps are important safety features of Aave V3, and they are essential for maintaining the stability of the platform. However, these caps can also have a significant impact on the growth potential of the platform. If a cap ceiling is met and governance takes too much time to adapt, this can slow down the growth of the platform and limit its ability to meet the needs of its users.

Given the importance of supply and borrow caps, it is essential to have a governance process in place that can quickly and efficiently adapt to changing market conditions. A long-term viable solution would be a clear framework and the election via governance of a Risk Council having a degree of Risk management capability over the Aave protocol. However, while the definition and implementation of this is technically allowed by the Aave codebase, it is still immature.

As a temporary buffer, this ARFC proposes a direct to AIP vote for cap changes or FreezeReserve() implementation under certain conditions to increase the efficiency of the governance process. By streamlining the governance process in this way, we can ensure that the platform can quickly and efficiently adapt to changing market conditions and meet the needs of its users.

Specification:

As there’s no need for on-chain AIP or technical implementation for this ARFC, the outcome of a snapshot vote will be considered canon.

Disclaimer:

The author of this ARFC, Marc Zeller, is the founder of the Aave Chan Initiative and owns AAVE tokens. However, the ACI is not paid by the Aave Companies nor any other entity to submit this ARFC.

Copyright:

Copyright and related rights waived via CC0.

[MarcZeller]

following the snapshot vote the Caps update framework is now considered part of Aave governance guidelines and “direct-to-AIP” process can be mobilized if the proposal fits the conditions defined in the framework.

@Kene_StableLab would u consider adding this framework to your gov process thread for visibility?

[Kene_StableLab]

Yes I will definitely add it.

[bgdlabs]

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.

[MarcZeller]

The ACI is supportive of this proposal by @bgdlabs

the Q1 2023 was the most active ever for the Aave DAO in terms of governance.
While activity is a net positive, we also have to consider that an efficient governance should request the Aave community votes for impactful change to the aave protocol.

A decent part of current volume of AIPs done by risk teams, llama & ACI are simply “day to day mechanical” maintenance of the Aave protocol.

We agree that theses improvements could be operated by a multisig enforcer contract managed by the designated risk teams of the DAO.

If this new Risk Steward is implemented with the ACI, we will keep presenting caps management ARFC but instead of a “direct-to-aip” process, will suggest the Risk Steward to enforce the changes.

[dtalwar]

Thanks for this proposal @bgdlabs. Gauntlet is also supportive of this proposal – we are all for measures to decrease the governance overhead of our risk work and increase automation/speed.

[ChaosLabs]

Chaos Labs is also supportive of this proposal.

Enabling risk providers to implement updates without going through the full voting process will improve the speed of execution and allow for dynamically updating supply and borrow caps while preventing extended periods of fully-utilized caps, which can restrict the growth of the protocol.

We recommend keeping the same guidelines for updating caps as in the current framework:

• The proposed increase is limited to 2X the current cap
• Any decrease of the caps
  • It is important to note that in some cases, decreasing caps could effectively freeze the reserve . Although we support allowing this as a risk-mitigating option, we would like to flag this and hear the community’s thoughts.

[fig]

Glad to see the update on this topic.

There is strong private and public support for better equipping risk managers. Flipside continues to support these efforts - such as the one outlined by @bgdlabs above.

This leaner, more simple approach seems best - and is a principle Aave must remember when embracing Governance structures.

The next steps - given this pilot with caps is successful - is determining which controls Risk Stewards empowers teams like Chaos and Gauntlets.

Another consideration, is expanding this multi-sig to include folks like @MarcZeller @Alex_BertoG and even @Llamaxyz per the community’s discretion.

To reaffirm, we like this approach and are excited for future iterations.

We are committed in assisting to this process and working across multiple stakeholders.

[MarcZeller]

Hey @fig,

Thanks for your reply. The risk stewards proposal by bgdLabs is a pilot program, and if for some reason we witness a disagreement between the multisig signers, the ARFC will fall back to the “Direct-to-AIP” framework allowing the governance to express their opinion on the topic via a vote.

Our vision of the stewards is that it’s a “mechanical management” tool for the DAO, tailored for proposals that generate little to no “political” debate. If a debate arises with a proposal, it indicates that governance should express their opinion, and in our opinion, the steward may not be the appropriate tool for such proposals.

Adding “governance coordinators” could be a net value add, but we think it’s best to let the pilot mature before introducing more complexity & friction by adding other multisig signers. The introduction of these potential new signers should be done not for the purpose of debate, but as neutral entities that will act as checks and balances to verify the standard aspect of a proposal and determine if the risk steward is a compliant tool for a proposal according to governance guidelines.

We emphasize that the governance is sovereign for the Aave DAO, and token holders, either directly or through their delegates, are the only actors able to control the DAO.