How rToken governance works. Definitions and Requirements

Introduction

This is a comprehensive guide to onboarding new users into the governance process of RTokens.

It combines best practices from previous decentralized governance models (1, 2) and introduces a standard formatting structure to streamline the process for both forum discussions and on-chain proposals. The goal is to enable RToken DAOs to govern efficiently while enhancing community participation, making the governance process transparent and accessible to all users.

Step 1: Request for Comments (RFC)

The first stage in the governance flow is the Request for Comments (RFC), which allows the community to engage in initial discussions about a proposal. During this phase, the proposal creator outlines their idea and gauges community sentiment through a forum poll. The RFC has specific format standards to ensure clarity and uniformity across discussions.

RFC Standards:

  • Title indicates the RFC status starting with “[RFC]”.
  • Structure follows the RFC template*.
  • Accompanied by a poll to measure sentiment.
  • Minimum of 3 days in the forum before transitioning to an Improvement Proposal (IP).

Link to an example of a well-formatted RFC.

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: Transition to Improvement Proposal (IP)

After the RFC has been live for at least 3 days and has gathered sufficient feedback and support from the community, it is ready to transition to an Improvement Proposal (IP), an onchain proposal that can be submitted and voted by RSR stakers. Each RToken has an individual Poposal Threshold which determines a minimum staked RSR limit in order to submit an onchain IP, more information about RSR here. Transition to an onchain IP has certain standards that provide effective signaling and communication with governance participants.

IP Standards:

  • Forum Poll results must show at least 25% in favor of the RFC to proceed.
  • The original forum post’s title “[RFC]” is updated with the prefix “[IP]”.
  • The proposal is taken on-chain to the Reserve app.
  • Title and describe the proposal identically to the forum discussion, accounting for any potential feedback that has been agreed upon.
  • Include a link to the original RFC discussion.

Onchain voting and Execution Process:

  • A 2-day review period during which technical members of the community can review the implemented code to ensure that it reflects the purpose of the proposal.
  • 3-day voting period. A simple majority of RSR staker votes is necessary to pass the proposal. The recommended quorum, or minimum participation needed, is 15% of staked RSR.
  • If a favorable majority is reached and quorum is met, the proposal is manually queued for execution after a 3-day delay. This delay ensures that the Guardian or Pauser can prevent malicious proposals from being implemented.

In total, any change takes at least eight days from the creation of the IP to its implementation.

Scheduling for Optimal Participation:

To ensure sufficient participation, it is recommended to submit proposals at the beginning of the week, preferably on Mondays. This avoids weekends when community engagement may be lower.

Once the IP is created, it is crucial to ensure active participation to meet the required quorum.

Proposers are encouraged to proactively reach out to known RSR stakers to help proposals meet quorum via any means available. Tweets, Discord and Telegram messages. Any method works.

Graphical flow of Reserve’s governance process.

Conclusion

By following this standardized governance flow, starting from RFCs, transitioning into IPs, and finalizing with on-chain execution; RToken DAOs can streamline the governance process and make it easier for both new and existing community members to participate. This uniform structure helps to reduce barriers to entry, fosters clear communication, and increases the likelihood of meeting quorum and achieving consensus within the community.

6 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!

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

2 Likes

For clarity and simplification, we pasted the revised governance flow over the OP, since this is the category defining post and can not be deleted.

Author now is is @Jose_StableLab. Thanks to @Brody3 for the initial push and inspiration.

1 Like