Name: Add Snapshot as an off-chain signaling mechanism to show support for/against RIPs
Status: Final - Accepted - Implemented
Scope: To introduce a signaling mechanism in the governance process that fairly captures sentiment from RenVM stakeholders
The proposal builds on the discussions held here: https://forum.renproject.io/t/rfc-000-017-add-snapshot-as-a-signaling-mechanism-for-rips/617
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 have implemented 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. The implementation assigns voting power only to Darknode operators, and adjust it based on how long they have had their Darknodes registered.
Snapshot is an off-chain polling system, requiring no gas to vote.
The Snapshot space for the Ren community can be found here: https://snapshot.org/#/ren-project.eth
Additionally, here is a test vote anyone can play around with, which will be deleted in a few days:
Test vote - try here
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 this can be achieved by speaking to everyone. But for large global communities, tools tailored to aggregate community sentiment is necessary.
Similarly could be said about how one learns whether a RIP has received enough support. Really, for any detail that the community wants to decide on, there is currently a lack of a coordination tool.
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.
We’ve implemented a voting mechanism that only assigns voting power to addresses maintaining a registered Darknode. This is because Darknode operators are the core stakeholders of the Ren ecosystem, which explains why a clear majority of the community prefers this alternative and thus why we implemented it.
Additionally, a time-component was added to the voting strategy, that assigns more weight to longer registered Darknodes, according to the square root of the duration. This gives more voting power to Darknode operators who have shown long-time commitment in powering RenVM, while at the same time limiting the formation of a cabal of long-registered node operators, as new Darknode operators are able to catch up to the voting power of longer-time Darknode operators over time.
The actual function that assigns voting power to an address is the square root of how long a Darknode has been registered in months. If an address controls more than one Darknode it sums the total value after using the square root function for each individual Darknode’s registration duration in months.
If you have 1 Darknode registered for 9 months, it’s voting power is sqrt(9) = 3
If you have 2 Darknodes registered for 9 months each, the voting power is sqrt(9) + sqrt(9) = 6
If you have 3 Darknodes, one being registered for 81 months, the other for 49 months, and the last one for 1 month, the voting power is sqrt(81) + sqrt(49) + sqrt(1) = 17
Voting duration and quorum
We suggest to initially set the voting duration to be 168 hours (7 days), which can be adjusted at any time through governance. If it is abundantly clear that consensus has been reached about a proposal before the 7 days, implementing (or ignoring) the proposal can begin before that time, especially in emergency situations. (Also keep in mind that the RenVM gateway contracts on Ethereum are on a 7-day time-lock, meaning any change to those contracts would still take a minimum of 7 days to complete.)
We suggest to not have a quorum level initially, but to observe the average participation over a few proposals, and then introducing a quorum level based on that data.
- Implement the Snapshot [done]
- Community provide their support or opposition for the proposal [todo]
- If accepted, update the governance process [todo]