Name: Add Snapshot as an off-chain signaling mechanism to show support for/against RIPs
Scope: To introduce a signaling mechanism in the governance process that fairly captures sentiment from RenVM stakeholders
The current governance process includes no formal way to measure sentiment from RenVM stakeholders. This can lead to issues when polling the level of support and opposition for RFCs, RIPs, and other parameters the community is discussing and deciding about.
We propose to create a Snapshot space where sentiment from Darknode operators can be polled, on topics relevant for RenVM governance, such as whether a parameter should have value X or Y, or whether an RIP should be implemented. Note that this proposal is separate from RFC-000-016, and that we do not suggest that the proposed Community Ecosystem Fund should use Snapshot as a method for distributing grants, as there are potentially more fitting mechanisms for that specifically.
Snapshot is an off-chain polling system, that requires no gas to vote, and that can be programmed to take into account addresses that have bonded REN, and not simply base the vote on REN token holdings.
The current governance process is lax when it comes to how one measures community support. For instance, the governance process currently instructs that an RFC should transition into a RIP when it has ‘received enough support from the community’:
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.
It does not instruct how one learns whether an RFC has received enough support. In smaller communities, it is fairly straight-forward to get to know this through speaking with everyone. But as a community grows, that becomes harder and harder until it is practically impossible to coordinate without specific tools.
Similarly could be said about how one learns whether a RIP has received enough support, and for any general detail a proposal is about that governance need to agree upon.
Why not on-chain voting?
Given that RenVM is not a set of smart-contracts on Ethereum, but a completely separate network that talks to other blockchains, there is no way to enforce on-chain votes through a platform like Ethereum, and as such there is no need to strive for on-chain governance at this stage as some other protocols like Compound and Aave do. Even if RenVM acquires general smart-contract capability, it would be difficult to have general on-chain voting for every protocol change, as things like deploying Gateways on a new blockchain we are integrating, and whether to update the Darknodes to a new version, cannot be physically controlled by the outcome of an on-chain vote even if we wanted to.
Given that Darknode operators are the RenVM network, we suggest that polling support and opposition for RenVM protocol and governance changes, should only take into account Darknode operators. This fits nicely with Snapshot, which easily can be programmed to take into account whether an address has bonded REN into the Darknode Registry Contract, and for how long.
We additionally suggest that polling should take into account the duration of operation of each Darknode. We propose that the voting weight should be according to the square root of the duration. For example, this would mean that the voting weight of a new Darknode is sqrt(1) = 1, while the voting weight of a Darknode that has been online for 9 epochs has voting weight sqrt(9) = 3. The square root function respects that Darknode operators who have been part in operating RenVM for a longer time deserve more weight given their continued support of RenVM, but it also allows new Darknode operators to eventually ‘catch up’ to long-time operators for the most part, as someone who has operated for 100 epochs (sqrt(100) = 10) would almost have the same weight as someone who has operated for 121 epochs (sqrt(121) = 11).
We also suggest that anyone, even those who do not run a Darknode, should be able to submit a Snapshot poll, in the same way that anyone is able to submit an RFC/RIP. Whether you have a good idea or proposal to share should not be hindered by the fact that you might not be running a Darknode.
- Quorum threshold - should we require a certain percentage of the vote weight to have voiced in the proposal for it to be considered a valid poll? Note that the results of the votes cannot be forced to be implemented, given that it is an off-chain signaling tool, so there is no immediate danger of abuse
- Polling duration - should we require each poll to be open for voting for a certain duration, for the results of the poll to be considered valid?
- Resolve the remaining questions
- Develop a Snapshot space
- Update the governance process