RIP-000-004: Add Snapshot as a signaling mechanism for RIPs

Ren Improvement Proposals | RIP
1

Name: Add Snapshot as an off-chain signaling mechanism to show support for/against RIPs
Category: Governance
Status: Final - Accepted - Implemented
Scope: To introduce a signaling mechanism in the governance process that fairly captures sentiment from RenVM stakeholders

Overview

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

Background

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.

Details

Voting power

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.

Implementation

  1. Implement the Snapshot [done]
  2. Community provide their support or opposition for the proposal [todo]
  3. If accepted, update the governance process [todo]
Do you support this RIP?
  • Yes
  • No
  • Abstain
0 voters
1 Like
2

Awesome - this is in line with the thinking that was discussed in Discussions for the future of governance - #11 by loong

As someone who’s been managing governance elsewhere, I’d say 3-5 days is a bit more on point to maintain some level of flexibility / agility. 7 days can be a bit long and likely only small marginal additional participation.

(Edit: Abstaining for now. If reduced vote period, I’ll switch to support)

2 Likes
3

I can’t vote in the poll, but I support this approach.

4

I think 5 days should be more than enough.

2 Likes
5

7 days is too long for me.
3-5 days will be great.
1 day for semi critical accidents

6

I increased your trust level so you can vote now :slight_smile:

7

Totally in favor of this proposal. I do agree that 7 days seems a bit long, for the expected additional votes that it will bring. 4 or 5 days seems enough.

As the vote will be off-chain; will it be integrated with the Darknode Command Center, or will it be available somewhere else ?

Great initiative towards clean governance !

8

Here: Snapshot

9

This is the way - Full support

10

Full support from the community!

To not delay accepting this RIP now, we will also directly accept the comments from the community, as they all agree that a Snapshot vote needing to be 7 days is too long. Since we still want proposals to exist for at least 7 days overall from the time of inception to getting accepted or rejected (a precaution against governance attacks), a simple compromise is to require that anytime a RIP is proposed, it should at least bake for 3 days on the forum through discussion with community members, and modified if need be, before the Snapshot poll is put up.

The Snapshot poll should then have the voting duration of 96 hours (4 days) instead.

To summarise: 3 days (or more if needed) of discussion on the forum, and 4 days for the Snapshot poll.

And as always, these parameters can always be changed by the community through a proposal, which is easier now with the Snapshot tool!

And for any new proposal now, to make it simpler when deciding on whether a RIP should be accepted while it could have a parameter set at different values (e.g. how long a Snapshot vote should be), a Snapshot poll can include multiple ‘yes’ alternatives with the different parameter values, e.g:

  • yes - 7 days
  • yes - 6 days
  • yes - 5 days
    …
  • no

Where all the different ‘yes’ votes in aggregate count as ‘yes’ (unless specified differently by the proposal).

I will now edit the Ren Governance Process document so that one always can find the current governance process there, and the community is now free to set up Snapshot votes when you create an RFC/RIP or for any other governance-related matter.

4 Likes
11

this is cool, so if understood correctly now we wait for community fund vote to come up? after that we can fire up discussions about what the funds should be used for in this thread?

12

Yes :eyes: RIP-000-005: Launch a Community Ecosystem Fund

Discussions should be fired up in separate threads though to more easily keep track of things (and maybe Excel sheets will be needed haha)

1 Like