RFC: Introducing Governor Alexios 1.3

[river0x]

TL;DR

The Reserve core team would like to initiate a conversation with RToken governors about updating RToken governance procedures and refreshing the Community Guardian’s “veto” role. The development team suggests categorizing governance changes into two different types to reduce friction. It also suggests clarifying the voting period on the Community Guardian’s veto.

Introduction

Reserve is a free, permissionless platform on Ethereum mainnet to build, deploy and govern asset-backed currencies referred to as “RTokens.” RTokens are always 1:1 asset-backed, allowing for permissionless minting and redeeming on-chain by users without the need for any middlemen. Overcollateralization is provided by RSR governance token stakers. Each RToken can have an entirely different governance system and is governed separately by ecosystem stakers. The Reserve Protocol launched on Ethereum mainnet in Oct 2022 and completed its fifth audit in Feb 2023.

Three of the RTokens already live on the protocol are High Yield USD (hyUSD) is a secure high yield savings dollar with up to 8% APY expected to outpace the rate of inflation in over 100 countries around the world. ETHPlus (ETH+) is a safety-first diversified ETH staking index with up to 4.5% APY. Electronic Dollar (eUSD) is a resilient stablecoin built to endure black swan events, recently proving itself during the run on Silicon Valley Bank.

These efforts are bearing fruit:

• TLV is nearing ATH at $28M
• Reserve’s $20M investment into Curve governance has attracted significant coverage
• Reserve’s Community Education Rewards program is engaging the ecosystem

Nevertheless, careful evaluation is a constant as Reserve grows. As a relatively fresh protocol, Reserve’s original configuration was designed to be procedural. As more information was gathered, the protocol would be adapted in light of it.

This RFC begins this process of “informed adaptation” with the introduction of Governor Alexios version 1.3. Governor Alexios is the (suggested) default decision-making system for RToken governors, and is key to the health of the RToken being governed. It is a modified version of OpenZeppelin’s Governor.

The aim of this RFC is to get feedback from the Reserve ecosystem about their thoughts on this proposed update.

Generally speaking, RToken governors should strive to be competent, stable managers of their RTokens. In this vein, the Reserve team proposes an upgrade to the Governor Alexios to version 1.3.

This will be achieved by splitting existing potential governance changes into two categories: structural and routine. We also recommend clarifying the Community Guardian’s Veto role voting period.

RTokens are currently fully upgradeable via governance vote. When there is no Guardian, these changes can be enacted in fewer than 10 days. There is no separation between more significant changes to less significant ones. The current default RToken Guardian (which acts as a veto agent of last resort for already passed governance proposals) is a centralized position.

Problem

The current RToken configuration presents a potential risk to RToken holders who cannot follow the activities of governance closely.

The current solution is to use a preselected Guardian address that can veto any change. As a centralized solution, this is relatively effective. However, if RTokens are to meaningfully decentralize then this has to change.

In addition, there is also no differentiation from one change to another, despite different proposed modifications often being of varying significance. This makes governing more convoluted and adds friction to the governance process.

See the diagram for a visual representation of this process and its pitfalls.

Solution

We propose to split governance changes into two categories - structural and routine.

Structural changes would be of greater consequence to the RToken and less frequent:

• Updating the governance contracts

• Updating any of the Component Contracts ( e.g. Main, Asset Registry, Backing Manager etc.)

• Approving a new type of RToken collateral (e.g. aUSDT) or collateral plugin.

• Adjusting the Component Contract limits (e.g. Auction Length minimum = 10 minutes, Auction Length maximum = 60 minutes).

These examples are a non-exhaustive list.

These changes would be architectural, and thus necessitate more time for execution. We propose a 90 day window (1 block snapshot, 7 day voting period, 83 day execution period) to sufficiently compensate for the increased weight of these changes.

This would allow RToken holders dissatisfied with the structural change sufficient time to exit the RToken if desired.

Routine governance changes would be potentially more frequent:

• Changing RToken collateral if the collateral has already been pre-approved.
• Adjusting Component Contract Knobs (e.g. changing auction length from 10 minutes to 20 minutes when a predefined maximum already exists at 60 minutes).

Routine changes update parameters within governance-approved bounds. As such, we suggest a 10 day voting period (3 day voting, 7 day execution) for “routine” changes. These more routine changes are completed faster to allow for quicker response times.

See the above diagram for an example of how the new process would handle one structural and one routine change to RTokens handled via governors. Note the time difference and reduced scope of change for a routine change.

In addition to these two changes, we propose a clarification of the Community Guardian’s veto role (for passed but pending governance votes). We suggest implementing a 3 day voting period to clarify how the Community Guardian’s veto role operates.

In doing so, we will afford RToken governors substantially more flexibility in navigating an evolving and complicated ecosystem which may prove useful in the future. We perceive little downside except a small elevation in complexity for governors. From our perspective, the benefits of this change outweigh the associated cost.

Conclusion

The Reserve core team proposes this change to increase flexibility for governors. This change will split existing responsibilities into two roles and help reduce friction. It also clarifies the role of the Community Guardian’s Veto.

We propose this in a collaborative manner and are excited to hear your thoughts below.

[Larry]

Thank you for the detailed proposal @river0x. Proposing more nuance to the governance process is a testament to the protocol’s growing maturity.

The reclassification of changes as ‘structural’ and ‘routine’ make a lot of sense, where governance proposals of different classes should be dealt with differently. While it’s clear that a lot of thoughtfulness went into this proposal, with the ultimate goal of strengthening our protocol, I want to voice a number of concerns I have with the proposed implementation.

I go over 1) issues with the proposed lengths, 2) separation of concerns, and 3) other possible solutions.

1) 90 Days is too Long

Frankly, I think the 90-day window for structural changes is WAY too long. A delay this long completely hamstrings the protocol and RTokens from being able to respond swiftly to changes. Fast feedback loops are critical in our environment.

Hypothetical Harm

In the context eUSD’s short life, let’s consider the potential implications if the governance cycle were 90 days instead of the current 8:

• The Broker would not be upgraded right away. The original bug would have continued to make revenue auctions fragile, and user errors (or griefing) would lock up the contract, adding to governance/operational overhead
• 50% of the eUSD basket would have stayed naked USDT and not have been earning yield for 3 months - this comes at a cost of ~$75k in missed revenue for stakers

From an RToken deployer and voter’s perspective, I think such a long governance cycle would ultimately result in governance apathy. For example, the deployer of hyUSD @Tom_hyUSD, is considering re-allocating the MIM portion of the basket. A lot of these discussions center on which protocols’ opporunities are currently profitable. However, it’s nearly impossible to determine how a pool’s yield might look 3 months from now… so why bother? Similarly, a 3 month governance cycle would disenfranchise voters, who won’t feel any urgency to the changes and don’t know if they’ll even be around when it comes time to execute.

Routine Changes

The proposal claims to reduce friction for enacting routine changes. While this is the right spirit, the proposed changes as written are more cumbersome than the existing 8 day governance cycle:

As such, we suggest a 10 day voting period (3 day voting, 7 day execution) for “routine” changes.

2) Community Guardian Issues

I’m making an assumption here that the Community Guardian has the opportunity to cancel proposals with a 3 day vote any time during the 83 day delay (the proposal doesn’t spell this out, but suggests it). I’m also assuming that the Community Guardian are the same RSR governors of an RToken.

If the above is correct, the ability for RSR stakers to propose a veto vote during the 3-month delay seems somewhat puzzling. In principle, checks and balances require a clear separation of powers. The Guardian is a role that acts as a check against malicious governance actors. In the current case, there is a multisig wielding this power, separate from RSR stakers, so the Guardian validly acts as a check on governce.

With this proposal, the entity with veto power would be opting to exercise it against itself. The separation required to make it a valid check is not respected here. It may be argued that new RSR stakers would swoop in to save the day from an evil governor, but it would be unwise to assume that everyday RSR holers would want to have their funds embroiled in a battle against a motivated malcious actor.

Community Veto Resembles Centralized Power

The only possible case where the “community veto” plays out successfully against compromised RToken governance is where the Reserve team (or another large delegate) stakes its RSR stack for the purpose of vetoing a vote. This end result may appear as centralized as if Reserve held the traditional Guardian role.

3) The Way Forward

It’s apparent that the motivation behind this proposal is to improve the decentralization of the Reserve Protocol (especially that of the Guardian), which is a commendable objective.

However, the drawbacks of a three-month governance process discussed above necessitates exploring alternatives. There’s no precendence for governance delays of similar length for the simple fact that it doesn’t allow DeFi projects to keep up with the pace of innovation and competition. The risk of bricking governance is not worth the reward.

I think we could take a page from other protocols who have prioritized decentralization whilst retaining a nimble governance process. For instance, Aave has Aave Guardians with veto power, the Guardians being a multisig wallet comprising various DeFi leaders.

Conclusion

I appreciate the spirit of openness & innovation that led to this proposal, and hope that we reach consensus on how to best achieve our shared objectives. I would urge us to consider more solutions which prioritize decentralization without sacrificing agility, which is my main concern and criticism with the current proposal.

[Sinatra]

Appreciate the very clear proposal, @river0x! Exploring ways to further decentralize RToken governance is a valuable endeavour, no matter the outcome of this particular proposal.

This RFC talks about “approving a new type of RToken collateral (plugin)” in the Structural changes section and “Changing RToken collateral if it has been pre-approved” in the Routine changes section. However, I believe there is currently no such collateral-approval system in place. I vaguely recall this being a suggestion from the core governance team, but it not being in production (yet). Could you please add some clarification on that? In case it’s not in production yet, a separate RFC introducing that new system might be a good idea.

Other than that I feel like @Larry hit the nail on the head in his reply. Some additional minor remarks from my end on his arguments:

• On the 90 day window for structural changes: @Larry emphasizes how this long of a delay would create technical friction (e.g. revenue auctions being fragile for 90 days instead of 8 days). I want to add that this window also hampers RTokens to benefit from first-mover advantage when adding new tokens to the basket. As an example, I recently saw Conic Finance’s crvUSD omnipool reach $10m in TVL in 2 days after being (one of) the first crvUSD yield aggregators. Their first-mover advantage continued, resulting in the omnipool now controlling +60% of crvUSD’s supply. RTokens that would use this new version of Governor Alexios would not be able to benefit from being early adding tokens due to the 90-day delay.

• On the 10 day governance period for routine changes: as @Larry stated, this proposal acknowledges that the current 8-day governance cycle adds avoidable friction for routine changes, but proposes a longer (10-day) governance cycle. Since the examples of routine changes given in this proposal seem to include so little risk, why not go for a far shorter governance cycle (e.g. 3 day vote, 2 day implementation delay)?

[prose11]

Hey folks was asked for my opinion but before I get too far in, my name is Payton and a used to be the Governance Facilitator at MakerDAO so a lot of my recommendations come from messing things up there and realizing it’s easier when you get it right the first time

@river0x

and refreshing the Community Guardian’s “veto” role

This is a healthy objective and one that’s important for the longterm viability of the organization. It’s also understandable the both the community and the Guardians might be a bit tense about where the next update lands. Having good talks on this thread is a great way to keep governance legitimacy, even if there are different opinions on how much power of the Guardians’s veto should change.

@river0x

Generally speaking, RToken governors should strive to be competent, stable managers of their RTokens. In this vein, the Reserve team proposes an upgrade to the Governor Alexios to version 1.3.

This will be achieved by splitting existing potential governance changes into two categories: structural and routine.

You will do yourself a huge favor if you’re able to define the difference between these categories explicitly, and have a procedure for exceptions/amendments to the classification when something invariably comes along that breaks some of your assumptions.

@river0x

The current RToken configuration presents a potential risk to RToken holders who cannot follow the activities of governance closely.

This is a problem of governance in general, and why we see so many delegation incentive programs popping up as people realize even delegates face this same issue. Splitting the votes is a good way to make sure people know when something is really important, but the problem we experienced at Maker when we tried to classify votes is the tendency to err toward the side of a vote being important. The people making this call will be heavily incentivized to do so (after all, something being marked as structural when it is routine has limited downside on its own, especially compared to a mistake in the other direction). But as you have more proposals building this bias eventually renders the distinction ineffective. Just think everything that is routine now, started off as a structural change.

@river0x

These changes would be architectural, and thus necessitate more time for execution. We propose a 90 day window (1 block snapshot, 7 day voting period, 83 day execution period) to sufficiently compensate for the increased weight of these changes.

It might be good to ask what you’re trying to achieve with the 90-day delay. I suspect that your goals could be achieved with a 60-day delay just as well, and that would allow a 1 month head start on something your token holders agreed was an important structural change that needs to take place.

@river0x

In addition to these two changes, we propose a clarification of the Community Guardian’s veto role (for passed but pending governance votes). We suggest implementing a 3 day voting period to clarify how the Community Guardian’s veto role operates.

Would love more details on this. I think figuring out a way for token holders to veto themselves will be crucial to your decentralization, and the measures you take in between now and then should represent meaningful steps toward that goal.

---

A lot of gov thoughts, so worth adding that I think this is a really great start to an overall system “leveling up” and I would be happy to find ways to contribute my expertise in more meaningful ways (all this stuff is surface level because I need to really get to know the community before recommending anything bespoke).

[0xTomSawyer]

Great proposal @river0x here are my thoughts.

It is unclear what system you have in place for “approving a new type of rtoken collateral plugin” vs “changing rtoken collateral if the collateral has already been pre-approved”. What does the approval process look like? And does all collateral go through a pre-approval process?

As an rtoken deployer I do not want to wait 90 days in order to change collateral. Yields can change quickly and so can assets within the collateral. It is important to be able to iterate over these changes in a relatively short time frame. 3 day vote and 7 day implementation period is perfect. Anything that can potentially negatively impact income towards rtoken holders or rsr stakers should be classified as a routine change.

Structural vs routine changes, in your RFC you cite a few examples in a non-exhaustive list. However, I think it might be beneficial to create an exhaustive list for any and all possible changes that are structural vs routine. This might be beneficial to determining what might need a 90 day window vs 10 day window.

I am unclear about the community guardian veto role. From my understanding, the Reserve team holds the power to veto any and all governance. From my understanding this is in place to prevent malicious attacks. Is the community guardian veto role there to decentralize this decision making?

[Matt]

@river0x thanks for drafting this insightful RFC! It’s great to see Reserve’s commitment to looking for ways to improve governance processes. Below are some of my thought.

Structural Change Timeline

I believe the 90-day timeline for structural changes is far too long. Three months is an eternity in DeFI and many of these changes could be no longer beneficial to the DAO by the time implementation occurs. It can also cause significant voter apathy if DAO members don’t see proposals they support being implemented in a timely fashion.

If the concern is giving investors appropriate time to respond to passed proposals before they are executed, 3 months is more than enough time. Those that feel the need to adjust the positions based on a proposal should have plenty of time to do so in a 20-day period.

If the concern is these big changes need extended time to verify they are in the best interest of the DAO then this could be solved with a required discussion period on the forum. Currently, it appears there is no rule for how long a proposal must stay in the RFC phase. By requiring new proposals to stay in a discussion phase for 7 days you ensure concerns regarding the proposal are properly addressed and technical details are ironed out before a proposal ever reaches an On-Chain vote. An additional step could be requiring RFCs to pass a temp check by receiving a set number of approvals via the community poll feature on discourse.

The past 3 eUSD proposals are moving to vote in an average of 3.67 days with little to no preliminary discussion

Proposal	Days on Forum Before Vote	Comments on Forum Before Vote	Voters
Upgrade eUSD contracts to use version 2.1.0 of the Reserve Protocol	7	1	4
Max Trade Slippage Reduction to .5%	2	1	5
[Correct] Trading Delay Reduction to 2 Hours	2	2	11

This indicates that proposals are not currently given enough thought before going to vote and therefore need longer execution time to ensure their validity. This is especially true since many proposals are decided by fewer than 10 voters and therefore could be easily manipulated. Requiring RFC to stay on the forums longer increases the opportunity for people to point out flaws in proposals decreasing the need for such a long execution delay. This extended RFC discussion period would also give investors extra time to begin to move funds if they see there is growing support for a proposal and also replace the need for a snapshot delay as it would give voters time to accumulate votes if they feel particularly strongly regarding a proposal.

I think a more reasonable timeline for Structural Changes would be something like:

This would bring the timeline to about a month which is more reasonable for larger changes as it still allows for quick actions but ensures the proposals are benefiting the DAO and investors have adequate time to make adjustments before the change takes place.

Routine Change Timeline

As others point out this proposal would make routine changes take 2 days longer than they currently do. This is not necessarily a bad thing if you feel it adds significant safety or utility to users. However for proposals deemed to be “routine,” I think 8 days is sufficient. With the implementation of a required RFC discussion period, you again can remove the 2-day snapshot delay. For routine changes, a 3-day voting window makes sense as it’s not as crucial everyone is able to vote. This then allows a 5-day execution delay to allow plenty of time for users to make preparations for small changes. This keeps the total time at 8 days, still allows voters time to acquire more votes due to the discussion period, provides the same amount of time for voting, and increases execution delay.

Process for Selecting Structural vs Routine

Even with a more comprehensive list of structural vs routine changes, the DAO will still find itself in situations where members are unsure how to categorize a proposal. This can lead to people trying to rush important proposals through the routine timeline or put routine proposals through the structural timeline to make them seem more important.

The simplest way to avoid this conflict is to clearly lay out what kinds of votes can be classified as routine proposals and have everything not mentioned as routine go through the structural timeline. Then have one approved routine change be a process for adding items to the approved routine change list. This way when new types of proposals come up that the DAO hadn’t previously thought of, they can easily be changed to the routine timeline for the next time they come up. This ensures proposals that are known to be quick always follow the routine timeline and anything the DAO is unsure of errs on the side of caution and has the extended structural timeline so the proposal is properly evaluated.

Conclusion:

These are important discussions to have. As the DAO is still in its infancy there will be lots of trial and error but it is important to establish these base frameworks so that governance adjustments can be made quickly when issues or disagreements occur. I have extensive experience researching and establishing these strong governance processes that allow governance to make tough decisions effectively and efficiently. I’m excited about the future of Reserve’s governance and look forward to helping it expand and mature.

[river0x]

@0xTomSawyer

I am unclear about the community guardian veto role. From my understanding, the Reserve team holds the power to veto any and all governance. From my understanding this is in place to prevent malicious attacks. Is the community guardian veto role there to decentralize this decision making?

To clarify: the creators of RTokens can decide which address should hold the guardian role. As it stands, all RToken deployers have elected Reserve addresses as their respective guardians. This can easily be overturned by a vote by RSR stakers who can elect any address. As such, I’d disagree with your understanding - Reserve only holds this power because they have been selected for it and it can at any point be overturned.

More generally, it appears the most frequent feedback this post is getting is that the time delay on this RFC is simply far too long. I’m inclined to agree, as @prose11 correctly indicates there’s probably no users that wouldn’t see such a change after 60 days but would after 90 - so this makes a good lower bound. Are any users in favour of going lower than this figure? The DAO might also want to consider removing the time delay for the snapshot vote as @Larry indicated might be an improvement.

Nonetheless this has been an excellent discussion and I am invigorated by these responses. Thank you!

[zduck]

I think 60 is certainly much better than 90. Excellent contributions in these forums. Glad to see that Reserve is in such qualified hands.

[pmckelvy]

I’d like to provide some context on Structural and Routine actions.

It seems some of the discussion here is assuming that the definitions of “structural” and “routine” actions are being lifted to the social level of governance. However, the intention here is define these in code, so that when someone proposes a vote on Structural action, it necessarily takes the Structural amount of time (60 days?). In plain english, here are the definitions I am currently working with:

Routine Actions

Routine actions CANNOT have immediate existential consequences for an RToken. They are simple parameter changes.

Here is the current list of functions that fall under the scope of “Routine” (this is by no means the final list. i think it is actually worth discussing the rationale for including each of these in the list, and I’ll work on another post with detailed justifications.):

• BackingManager.setMaxTradeSlippage()
• BackingManager.setMinTradeVolume()
• BackingManager.setTradingDelay()
• BackingManager.setBackingBuffer()
• BasketHandler.setPrimeBasket()
• BasketHandler.setBackupConfig()
• BasketHandler.refreshBasket()
• BasketHandler.setWarmupPeriod()
• Broker.setGnosis()
• Broker.setBatchAuctionLength()
• Broker.setDutchAuctionLength()
• Broker.setDisabled()
• Distributor.setDistribution()
• Furnace.setRatio()
• Main.setShortFreeze()
• Main.setLongFreeze()
• RevenueTrader.setMaxTradeSlippage()
• RevenueTrader.setMinTradeVolume()
• RToken.setIssuanceThrottleParams()
• RToken.setRedemptionThrottleParams()
• StRSR.setUnstakingDelay()
• StRSR.setRewardRatio()
• StRSR.setWithdrawalLeak()

Structural Actions

Structural actions CAN can have immediate existential consequences for an RToken (if they are malicious, misguided, or performed incorrectly), or enable a Routine action to have immediate existential consequences for said RToken.

There are 4 main types of structural changes:

• Updating governance parameters
  • proposal threshold
  • quorum threshold
  • voting delay
  • voting period
  • execution delay
  • timelock executor
  • routine action whitelist
• AssetRegistry interactions (adding/removing/swapping plugins)
  • AssetRegistry.register()
  • AssetRegistry.swapRegistered()
  • AssetRegistry.unregister()
• Granting & revoking of roles
  • pauser role
  • freezer roles
  • admin roles
• All contract upgrades (governance & component)
  • implementation logic updates
  • routine paramater range changes (immutable variables)
  • setting trade implementation addresses

FWIW, I think 30 days is likely long enough for a structural governance cycle.