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.