Governance onboarding

Start Here - RToken Governance Flow
1

Introduction

This post serves as a comprehensive guide to onboarding new users into the governance process of RTokens in the Reserve Protocol. 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:

  1. Summary: Provide an accessible, non-technical explanation of the intended outcome of the proposed change.
  2. Abstract: A concise (~200 word) description of what will be done if the change is implemented.
  3. Problem Statement: Explain why the current state is inadequate and why the change is necessary.
  4. Rationale: Justify the proposed solution, including alternate designs considered and the decision-making process.
  5. Risks: Outline the potential risks and what could go wrong if the proposal is implemented.

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.

1123Ă—509 49.3 KB

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.

2 Likes
3

Hello team, I’m Sensay Community member!

We are building the digital agents that act as knowledge management systems. These agents allow you internally ping the personalized replica for information, while also offering the same capability to the community.

On the Sensay platform, you can create a personalized agent and train it on data of your choice. This agent then behaves like you or your project, representing you or your product and boosting customer awareness and engagement. The training process is fully automated. You simply need to insert files, links to your pages, YouTube links, or manually add information. These agents can communicate in over 100 languages and update their information from the source every 24 hours.

2 Likes
4

Thanks for bringing this to our attention @Vitalii. I think this would be better as a post in the Governance & Research category. Could you post it there?

2 Likes
5

@Jose_StableLab thank you for this attractive update. A few thoughts.

This new post above will supersede an older post from Ann Brody Suggested governance flow for RTokens and the latter should be deprecated?

The 25% RFC poll support to move to IP is a one-person-one-vote methodology and those persons may not be actual governors and could in fact be trolls.

Of course IP approvals are one-token-one-vote, a more credible system to address this later in the governance funnel. I don’t think RFCs should be blocked from going to onchain IP based on an offchain poll that can be gamed.

Thoughts?