Suggested governance flow for RTokens

Introduction

This forum post describes a best-practice governance flow for RTokens, based on the learnings from existing decentralized projects’ governance practices. The intention is to suggest a governance flow that can be used, or expanded on, by RToken DAOs in order to efficiently govern RTokens. While each RToken DAO can decide whether or not to apply a predefined governance flow for their RToken, doing so is likely beneficial for the DAO’s ability to reach consensus & approve proposals.

Step 1: Request For Comments (RFC)

The first step in the governance process is to allow for initial discussions of the proposal through an RFC. Each RFC should pass an initial testing of community sentiment through a forum poll (>25% “For” votes) before evolving into an Improvement Proposal (IP).

An RFC should only be eligible for evolving into an IP if:

  • It is accompanied by a poll to test community sentiment
  • It follows the RFC template format (see below)
  • The RFC is at least 3 days old

RFC template

Title Description
Summary Describe the outcome the proposed change intends to achieve. This should be non-technical and accessible to a casual community member.
Abstract A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what will be done if the proposed change is implemented, not why it should be done or how it will be done.
Problem statement This is the why of the RFC. It should clearly explain why the current state of the RToken is inadequate. It is critical that you explain why the change is needed - why the proposed change is superior to the existing situation. This is not the place to describe how the RFC will address the issue!
Rationale This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
Risks Describe what the risks behind your proposed change are. What could go wrong after this change has been implemented? What would need to happen for that situation to occur? What are the chances of that situation occurring?

Step 2: Improvement Proposal (IP)

Once an RFC is at least 3 days old and has achieved at least 25% “For” votes, the creator of the RFC creates an Improvement Proposal (IP) on the RToken’s governance page on Register.app.

An IP should only be eligible for execution if:

  • It follows the RFC template format
  • It includes a link to the RFC discussion

By using Governor Alexios with default settings, when an IP is created, it enters a 2 day review period, after which voting weights are recorded and voting begins. Voting lasts for 3 days; if a majority, and at least 15% quorum(*) votes are cast for the proposal, it is queued, and can be implemented 3 days later (this execution delay is in place so that the Guardian/Pauser can prevent malicious proposals from being executed). In total, any change to the protocol takes at least 8 days.

(*) The quorum is the minimum percentage of staked RSR of an RToken that needs to have voted YES or ABSTAIN on an improvement proposal. If the quorum is not reached at the end of the voting period, the proposal automatically gets defeated.

Visualization of the suggested governance flow

4 Likes

I am in favor of following this flow. I’m going to do my best to build social consensus around using this approach, and if you also agree with it, I encourage you to join me in doing so.

In order for governors to come to use this flow, they need to know that proposals which are made without posting in these two steps will be rejected by default by most voters. Hence, if you agree with using this flow, you must actively vote against proposals that are made without taking these steps first, even if you think you’d probably vote in favor if they did take these steps. This will force proposals made improperly to be re-made properly, and train proposers to post prior to executing the proposal onchain.

Thanks @Brody3 for writing it up!

3 Likes

This seems reasonable and in line with industry standard. I have no problem voting down proposals that do not follow this flow and encourage others to do so.

1 Like