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.
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.
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.
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.
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.