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.