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.
