[ARFC] GHO Steward: Agile Parameter Changes

[AaveLabs]

Title: [ARFC] GHO Steward: Agile Parameter Changes
Author: @AaveLabs
Date: 6th July 2023

Summary

This ARFC proposes implementing the dedicated GHO Steward as a dynamic parameter change mechanism to ensure efficient risk management and support the peg of Aave Protocol’s native multi-collateral stablecoin GHO during the initial stages.

Motivation

Introduction

As the Aave DAO prepares for the introduction of GHO, it is crucial for the community to consider implementing a mechanism that offers greater agility to adjust risk parameters in the initial stages of launch.

To support the maintenance of the peg, the proposed GHO Steward multisig acts as a dynamic parameter change mechanism. It enables swift adjustments to risk parameters in the form of scoped governance delegation where the full governance process could potentially be time-consuming and hinder timely response to evolving circumstances.

By employing this mechanism, the Aave Protocol ensures transparency and enables flexible parameter changes through decentralized governance. This approach reinforces commitment to preserving the peg and effectively addressing market challenges that may arise upon the launch of GHO.

Key Terms

The “bucket capacity” refers to the maximum amount of GHO that can be minted by a Facilitator. The ability to adapt the bucket capacity by adjusting supply supports stability by ensuring that available supply meets demand.

The “borrow rate” refers to the interest rate paid when borrowing GHO. The borrowing rate may also be used to support stability because of its impact on demand.

You can learn more about GHO in the docs here.

GHO Steward Permissions

Aave V3 provides a high level of granularity around permissions. Building on the concept of Risk Stewards, it is proposed that a dedicated GHO Steward multisig be introduced to support the initial GHO governance risk mechanism to enable to implementation of agile parameter changes in the form of scoped governance delegation.

The GHO Steward multisig would be 2/2 and would include the DAO’s risk providers Chaos Labs and Gauntlet.

The GHO Steward would be capable of adjusting predefined parameters including: increasing the bucket capacity (by up to 100%) and changing the borrow rate (by up to 50 basis points in either direction) in a single change. Parameter updates could only occur once every 5 days per the parameter.

It is proposed that the GHO Steward would be deactivated 60 days after the passing of this proposal. However, the DAO can vote to renew the GHO Steward for another 60 days if deemed necessary. The DAO can also vote to remove the GHO Steward at any time.

Governance Process

This proposal emphasizes the importance of decentralization and community involvement in the decision-making process, fostering a robust and inclusive ecosystem. The GHO Risk Steward would enable agile parameter changes for GHO; however, decisions shouldn’t be made in isolation and should go through a lean governance process.

The proposed lean process is as follows:

1. Proposal on the Governance Forum explaining the rationale of the proposed action.
2. Snapshot requirements:
   a. 24-hour duration starting from the posting of the proposal
   b. Quorum 250,000 AAVE
   c. A minimum of 70% of votes FOR the change
3. Change can be enacted as soon as the proposal passes Snapshot.

Conclusion

In conclusion, the GHO Steward serves as an initial agile parameter change mechanism driven by decentralized governance. It highlights the Aave Protocol’s commitment to maintaining GHO stability and addressing market challenges during the launch period.

While the proposal acknowledges the potential for a more dynamic rate-changing governance model in the future, the current framework allows the DAO to effectively manage GHO’s parameters in the short term.

Specification

Capabilities:

1. Capacity Increase: It can increase the bucket capacity by up to 100%. This is strictly an upward adjustment; the capacity cannot be decreased by the GHO Steward.
2. Borrow Rate Adjustment: It can adjust the borrow rate by up to 0.50%, either upwards or downwards.

Configuration:

1. Permissions: The GHO Steward is granted PoolAdmin in the Aave Protocol and BucketManager for the GHO token.
2. Risk Council: This Multisig is solely responsible for triggering actions through the GHO Steward contract. The address of this entity cannot be changed.
3. Execution Time Delay: Any parameter change made by the GHO Steward contract, such as increasing bucket capacity or adjusting the borrow rate, is limited to once within the time delay period. e.g.,GHO Steward can only change a parameter once 5 days have passed since the last parameter change for that specific parameter.
4. Lifespan: The GHO Steward contract will initially only have a lifespan of 60 days. The lifespan is designed to ensure regular review of the necessity of this approach.
5. Steward Lifespan Extension: The DAO can extend the lifespan of the GHO Steward for additional 60-day periods as many times as it wants.

Disclaimer

N/A

Links

• Codebase: GitHub
• Audit Report: GitHub

Next Steps

1. If consensus is reached on this ARFC, this proposal will go through a second Snapshot process
2. If the Snapshot outcome is YAE, this proposal will be escalated to AIP stage

Copyright

Copyright and related rights waived via CC0.

[MarcZeller]

The Aave Chan Initiative (ACI) generally supports the concept of this GHO Steward. However, we believe that certain aspects of the proposal could be adjusted to be less conservative and more agile.

@AaveLabs

It is proposed that the GHO Steward would be deactivated 60 days after the passing of this proposal. However, the DAO can vote to renew the GHO Steward for another 60 days if deemed necessary. The DAO can also vote to remove the GHO Steward at any time.

We believe that a 60-day period is quite short. Even though it can be renewed, to avoid governance bloat, we would be more comfortable with 90-day periods. Quarterly intervals seem more appropriate. Given that the DAO can terminate the GHO Steward at any point via an AIP under GovernanceV2, there is no pressing need for such a conservative lifespan.

@AaveLabs

The proposed lean process is as follows:

1. Proposal on the Governance Forum explaining the rationale of the proposed action.
2. Snapshot requirements:
   a. 24-hour duration starting from the posting of the proposal
   b. Quorum 250,000 AAVE
   c. A minimum of 70% of votes FOR the change
3. Change can be enacted as soon as the proposal passes Snapshot.

This approach somewhat defeats the purpose of agility. The GHO Steward, with its limited capabilities and management by DAO-appointed risk service providers, should be able to act more swiftly. We propose that the Steward should be able to act at any point following a forum post publication, in line with the ‘direct-to-AIP’ framework standard.

In a scenario where one of the two signers disagrees with a change, thereby blocking its execution, we propose that governance should revert to a snapshot vote with general framework parameters. If the outcome of this vote is YAE, it should mandate the GHO Steward to execute the change. In case of non-compliance, the AIP process can be used to bypass the GHO Steward completely via the short_executor contract.

@AaveLabs

Borrow Rate Adjustment: It can adjust the borrow rate by up to 0.50%, either upwards or downwards.

We believe this is overly conservative. While these parameters may be suitable for current market conditions, the crypto market is known for its volatility. For instance, during the early days of DAI, the stability fees due to market conditions fluctuated from 0.5% to 20% within a few weeks.

We recommend a less conservative adjustment frame of 1% upward and downward.

[AaveLabs]

Thank you for your comments @MarcZeller.

In reference to your suggestion of the Borrow Rate Adjustment (0.5% → 1%) and GHO Steward Lifespan (60days → 90days); we have taken this feedback on board, and pending further input from the community will consider revising for the ARFC Snapshot vote.

Regarding the Governance Process, we believe that obtaining a community signal of approval before enacting changes on these parameters is important. We find the 24-hour process to be sufficiently agile and suitable for the role of GHO Steward in the initial governance process, but would welcome more views on this from the community.

[EzR3aL]

Hello,

i support the concept of the GHO steward. Especially in the beginning i am in favour of a “guardian” that is watching GHO’s start very close. We have already seen multiple stablecoins failing and i think many of them have because nobody was really taking care of them in the beginning. This is also why, although i like decentralization, think its important to be a little bit more centralized in the beginning or lets call it semi-decentralized.

As @MarcZeller Marc already proposed i think the 60 days should be extended to 90. And 20 days before those 90 days end another proposal/ARFC should be created to extend the Steward or not.
This would mean in one year we would only maybe need to vote three times for another extension.
It’s cleaner, do not bloat the whole process too much.

Also regarding the agility and ability to make changes fast…
The Steward should be able to react immediately, not within 24h. He is limited and will exist only for one reason. To adapt to failures, changing market conditions and so on. Give him the ability to do so. So im also supporting @MarcZeller and the ACI here. Maybe after a few months we will see that the Steward isn’t that much needed and then we could proceed to a more passive approach, but especially in the beginning its crucial to act fast. Don’t let the Steward work like the german government. (If you don’t know what i mean, here is an example: If you want to have a meeting because of tax relevant stuff you could end up with a meeting after the deadline, where you need to answer them, although you would like to answer them the meeting…)

Propose parameter changes, inform people, execute it, nothing else.

[AaveLabs]

Thank you for your comment @EzR3aL

Based on community feedback we have updated the Borrow Rate Adjustment (0.5% → 1%) and the GHO Steward Lifespan (60 days → 90 days)

We remain convinced that a rapid Snapshot governance process will allow for a sufficiently agile response to market conditions without sacrificing community control and decentralization and have now taken this ARFC to Snapshot Vote, found here.

[MarcZeller]

@AaveLabs

We remain convinced that a rapid Snapshot governance process will allow for a sufficiently agile response to market conditions without sacrificing community control and decentralization and have now taken this ARFC to Snapshot Vote, found here .

Having strong opinions is welcomed, but when the community gives feedback, a DAO contributor is encouraged to listen to it or at the least allow that feedback to find resonance with the governance during the proposal snapshot polling stage.

A recommended snapshot option in this case of divergent opinions on a topic is simply to publish a vote with “YAE (Snapshot Option)”, YAE (Direct-to-Payload), NAY, and ABSTAIN allowing governance to express their opinion with recognized granularity.

The ACI invites the @AaveLabs to republish a 4-option snapshot, with this potential new snapshot we intend to vote ‘YAE (Direct-to-Payload)’ and we will cast a NAY vote to the currently published 3-option one.

[AaveLabs]

Thank you, @MarcZeller for your thoughtful comments.

Agility is a known limitation of decentralized governance; however, we feel that decentralized community involvement is paramount for the long term success of GHO and has functioned well for many years for the Aave Protocol governance.

At the TEMP CHECK, we received positive sentiment from a number of contributors to the DAO, and we have implemented the majority of these suggestions in this ARFC.

We are comfortable with any outcome of the Snapshot vote and welcome alternative governance solutions that the community may propose.