This living document outlines the governance process for advancing Ren improvements, particularly:
- How to proceed when you have an idea that is relevant for the Ren community to consider
- Posting a Request For Comment (RFC) and making sure it gets a fair consideration by the community
- How an RFC may transition into an Ren Improvement Proposal (RIP)
- How support or opposition is evaluated for a RIP
- How a supported RIP is enacted
The Ren project is young and will be developing and changing over time, so any details outlined in this document are subject to change. Right now, we have just implemented signaling for Darknode operators on Snapshot, which has formalized and parts of the Ren governance process which were less formal before, and made it more decentralized. On the other hand the core team is still monitoring and making sure that governance is carried out appropriately, and that ideas or proposals get fair treatment. The community will gradually handle more and more of Ren governance over time.
Why do we need governance?
The Ren project aims to be the leading decentralized universal interoperability protocol in the crypto ecosystem. To fulfill this goal we need to constantly anticipate market demands and technological shifts, to support the platforms users and developers want, and to provide the best user experience when interacting with RenVM in general. We also need to balance making the network as secure as possible while we remain true to decentralization and permissionless-ness. For this we will need an active decentralized organisation governing the development of the Ren project, which for instance includes managing what the transaction fees in RenVM should be, and which new platforms that should be integrated into RenVM. This means that the Ren community, the core developers, and external projects interacting or intending to interact with RenVM, need to work together to shape the development of the Ren project.
We encourage everyone interested to take active part in governance, shaping the future of Universal Interoperability.
Step 1: You have an idea, proposal, or want to raise a discussion that is relevant to the Ren project
Proposals that aim to change something about the Ren project, either the protocol itself or the governance of the protocol, typically go from being discussed in a Request For Comment (RFC) thread, to a Ren Improvement Proposal (RIP). In the RFC, the idea/proposal is worked out or rejected, and if the community agrees that the finalized proposal is worthy to be formally voted on, it transitions into a RIP. But before you want to post your idea/proposal as an RFC (or in some cases directly as a RIP), it makes sense to chat with community members informally or posting in the “General” category on the forum, to sanity check whether it is worth to take precious attentional resources from the community and core team. This is because every RFC/RIP will be considered seriously and deeply as we care about the development of the Ren project, and new ideas are a necessary part of that.
If you feel confident that your idea is worthy attention, feel free to post it in the RFC category on the forum (or in some cases as a RIP directly), carefully following the details laid out articles describing how to post an RFC.
Step 2: Posting an RFC
What is an RFC:
An RFC is the first step when proposing changes to RenVM. It can be a full, or partial, proposal that is expected to evolve over time as a result of discussion. Although it is expected that an RFC will change over its life, it is still required to be clear and concise with respect to the change that it is proposing.
When you feel confident to post an RFC, do so and moderators on the forum will review it in a timely fashion to make sure it follows the laid out format.
Step 3: Making sure an RFC gets a fair consideration from the community
To make sure an RFC gets a fair consideration from the community, stay active in the thread and engage with the people that comment and ask questions about the idea. Also feel free to post a link to the RFC in the main Telegram channels for Ren so that people who don’t visit the forum every day might see it quicker. Also, give the community time to consider the proposal, as some ideas require more thought and or require more research, before having a good enough grasp on it to be able to comment on it. Having an RFC up for at least a week, before pushing it into a RIP, or dropping it, is recommended. You can also deploy a Snapshot vote if you feel the need to poll what the community thinks and whether the parameter of some value should be X or Y.
Step 4: Summarizing the findings in the discussions in an RFC thread and deciding whether to rework the proposal or push it through as a RIP
As the original poster of an RFC, it is prudent to summarize the discussions when it is appropriate to do so, to make it easier for the community to follow the discussions that have been had about the proposal (someone else involved in the discussion is also free to summarize). Creating a summary is a good way to reflect on whether the RFC is mature enough, and accepted by the community, to formally push it as a RIP that would be voted on. If it is found in the summary that there are many details still unclear about the proposal, or that a large part of the community reject the idea fundamentally, keep the community engaged in discussions if you think it can be worked out, otherwise you can leave it be.
What is required for an RFC to transition into a RIP:
RFCs can be accepted or rejected. An accepted RFC is one that has received enough support from the community that an appropriate RIP can be opened. This usually means the RFC has been discussed in enough depth that all ambiguities and concerns have been addressed. When an RFC is accepted, this does not mean that the respective changes will be implemented. It means that an appropriate RIP can be opened.
Step 5: Posting a RIP
What is a RIP:
A RIP is the second step when proposing changes to RenVM. It must be a complete proposal that is clear, concise, and unambiguous. All parameters must have clearly stated initial values, and clearly state methods for change through governance. RIPs cannot change once they have been proposed.
A RIP does not always have to have been developed as an RFC earlier:
An RFC does not always need to be opened before a RIP. This depends on whether or not community norms have already been established for the change (e.g. changing the % of minting/burning fees is simple and non-ambiguous enough that a RIP can be opened without an RFC). However, changes that do not have established norms must have an accepted RFC before an associated RIP can be opened. RIPs are expected to link to their supporting RFC when relevant.
When you feel confident to post a RIP (following the considerations in Step 4), do so and moderators on the forum will review it in a timely fashion to make sure it follows the laid out format. A RIP does not have to be posted by the original poster of the typically preceding RFC, it can be posted by someone else involved in the discussion, or by someone from the core Ren team.
For the time being the Ren team will have a veto ability to prevent a RIP being posted, which will be used if the Ren team thinks the proposal could hurt the Ren project financially, reputationally, security-wise, or in other ways.
Step 6: Posting a Snapshot vote for the RIP
A RIP has to be up for at least 3 days on the forum, before an official signaling poll can be posted, to give time to the community to discuss a proposal before it is time for voting. When posting the Snapshot vote, make sure to set the duration to 4 days, giving the community time to submit their vote. Attach the link for the Snapshot on the forum, and post it on other social media channels as well. The poll needs to include a ‘yes’ option, a ‘no’ option (or ‘No change’), and in some cases multiple different ‘yes’-options if the vote includes setting a parameter that can hold different values. Only Darknode operators are able to vote on the Snapshot vote.
Step 7: If the RIP is accepted by a majority
A RIP that has passed will be handled by the Ren team in a timely fashion depending on the size of the change given in the RIP.