RFC-000-017: Add Snapshot as a signaling mechanism for RIPs

Requests For Comment | RFC
1

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

Overview

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.

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, 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.

Details

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.

Remaining questions

  • 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?

Implementation

  1. Resolve the remaining questions
  2. Develop a Snapshot space
  3. Update the governance process
13 Likes
2

I like this idea.
“We additionally suggest that polling should take into account the duration of operation of each Darknode…” - very good concept
“the square root of the duration” - agreed

Quorum threshold - yes we should setting it up e.x. min. 1/2 of total Darknodes must vote to pass the poll.

Polling duration - should be different, depends on priority of the poll.

1 Like
3

I think there will be ren holders who dont want to participate, which doesnt mean the idea cant work, but just something to keep in mind that snapshot may or may not come out with the true sentiment and always listen to expressed opinions/statistics in addition to standardized polling; even if supposedly this captures whats attempting to be “true holder sentiment”. Is there no way to make an option on renVM? Id prefer almost like a non transferrable NFT 1:1 darknode:vote

1 Like
4

I am very much in favor of this, also have a few comments to add:

This is very important I think and critical point for wide spread community engagement.

I like the creative angle to this, nice idea!

I do not see any reason for this at this stage of the project. If people chose not to vote they simply chose to not participate in governance and it does not necessarily mean something is wrong.

Many may refrain from voting when they see a vote go in their favor simply out of laziness and I like the idea of keeping things as simple as possible for nodes.

One option would be to allow the person who submits a vote to chose whether a threshold should be met or not. Do we really need to decide fixed threshold rule for all polls? Or maybe we can have threshold for polls within a certain category (eg. treasury)?

I definitely think there should be a time limit to avoid aftermath discussions. I guess it depends on the poll but 1 epoch (28 days) feels like a natural start.

No time limit should be avoided imo as people can find angles to not implement something based on vote “not being final”.

However, if supermajority vote quickly for same option I see no reason to wait for the time duration to span out when we already know the only outcome. A poll can be decisive within days and can be annoying to wait full 28 days for implementation.

The snapshot voting is a VERY simple and easy process but I do agree with you that darknode operators should receive an alert or something similar. Just to avoid “but I didn’t know” type of arguments. Maybe they can get a notification in the dashboard that a new poll is available and give them a link to it? Like a pop-up or sth similar.

Question from my side @MaxRoszko, with snapshot, is it possible to program it so that every REN holder can vote but only darknode operators vote count?

Even if darknodes have the final say it would be interesting to see what the general sentiment is. Also a good way to see early on how many non darknode operators are interested in governance to begin with. This data could be useful for future discussions about allowing more than node operators to vote.

4 Likes
5

great idea. It’s easy to implement, the snapshot interface is easy to use, the voting is up and you can do it quickly. I would say don’t think about it too long, just do it.

3 Likes
6

Great idea. Formalizing some structures is a good way to get increased engagement and leverage the latent value of the community

I don’t think a quorum threshold is needed because its still simply a signaling mechanism.
I also think a reasonably defined polling period is a good idea, perhaps a week

3 Likes
7

This is an excellent idea Max.

I know nothing about these things so I googled for information. I came across an article and I quote

"## Myth 1: A Large Quorum Is Best Practice

Well-meaning members often advocate for a large quorum, hoping to prevent a group from taking action without a representative cohort of members. But a large quorum does more than prevent some action, it often prevents any action. Many a group has set a large quorum, only to become frustrated at the rare presence of enough members to get anything done. And nobody’s got time to burn. We meet to get things done.

So, your group’s quorum should be an accurate reflection of the number of people you can reasonably expect to attend a regular meeting. Don’t make quorum the number of people you wish would attend or you hope will attend. Make it the number of people that actually attend even when it’s hard to get to the meeting.

In general, most large organizations don’t need a quorum that’s any higher than 10 percent. Shockingly small, right? You’d be surprised. Many large groups struggle to meet a quorum that’s much higher than 10 percent. Smaller groups, including boards and committees, and perhaps certain types of organizations (such as a church) may want (and be able to tolerate) a higher threshold."

So I propose that we have a quorum of 10% of existing Darknode operators, considering the level of participation in this forum. I suggest a time limit 1 epoch for the vote.
My reasoning for this is that we don’t want an important vote that nobody knows about, to happen quickly.

1 Like
8

This is a great idea and I fully support some form of polling mechanism that takes into account time as well as holdings. Another option or as a companion to this we can look into Collab.Land for wallet authenticated discord or telegram channels. Their bot allows members to join if they meet certain criteria and then automatically kicks them if them once they no longer do. What is Collab.Land? - Collab.Land

1 Like
9

Full Support on this RFC! Thank you @MaxRoszko and team for putting this together!

1 Like
10

I like this proposal. Love that what we’ve talked about in telegram a year or so ago is coming to fruition (voting weight implementation)!

As for quorum, I don’t think it’s needed at this time (but it should be added later on).

Polling duration shouldn’t be too long. We, as a community of DN operators, should follow Ren development closely and be able to operate quickly. I think a voting period of 4 days is good in a way that it doesn’t make polling unnecessarily long and allows people to allocate time to think and decide in basically every life situation.

1 Like
11

Thanks for all your feedback guys!

I agree quorum levels aren’t that important right now as many have pointed out, we could begin setting a soft target of 10% and see what levels of engagement we typically get, and later adjust if needed, because it is hard to know if we have a bunch of Darknode operators who simply run their nodes passively and don’t mind whatever is going on (which it sort of seems like, given that we have 1700 Darknodes but perhaps 20-40 active members in the forum). If it turns out a vote got 9.5% of the vote weight, but it seems like everyone is in agreement anyway, we don’t need to fret about it not being above 10% and could still consider it valid. My guess is that the folks who don’t bother voting are basically agreeing to whatever the outcome looks to turn into, and only if they are against something will they vote.

I agree with this that we should not force votes to be too long, or we will never get anything done in time. 28 days (1 epoch) is way too much and completely arbitrary, and epochs will be daily later this year so no need for it to look elegant having it tied to epochs. 4 days is probably something I would target as well, perhaps stretch that to 5-7 days max.

7 Likes
12

Fully in favour of this proposal. Which will be great opportunity for community members to be involved more democratically in the approval process and hopefully increase engagement across the board. Love the idea of the duration of darknode operators voting weight, I think this is a fair solution and gives the newer operators the opportunity to catch up and have their fair say as well.

1 Like
13

sounds good to me Max

1 Like
14

This is an excellent idea Max, I very much support for voting via Snapshot.

2 Likes
15

Great proposal.

Only thing I can add to what has already been said is that I think the duration of the proposal can be decided on a case by case basis, but with a required minimum. Personally I was thinking a minimum of 7 days, but if the proposal is announced some time beforehand I can also get behind the 4 days that has been proposed.

2 Likes
16

That sounds good to me, we could fast-track simple proposals (e.g. 4 days, which is the duration Aave has for their on-chain proposals) and recommend a little more time on the more serious stuff (5-7 days).

2 Likes
17

Love the idea. Sounds fun! Would like to see a couple “experiment polls” as a proof of concept and to gather community feedback, before making this formal.

18

Yes we could make things a little meta and use Snapshot as a tool to evaluate this proposal about using Snapshot :nerd_face:

Will still be a little while until it is up and running but we’ve begun working on it and I hope it won’t be more than 1-2 weeks before it’s ready.

3 Likes
19

Hey everyone, just want to update about that we do have a Snapshot space up now! But we are waiting for the darknode strategy to be merged by the Snapshot team, so we can’t test out proposals just yet, but soon hopefully!

https://snapshot.org/#/ren-project.eth

8 Likes
20

Hi RenFam,

I fully support this RFC!

Regarding the remaining questions

Quorum treshold: I think we should have a quorum of 40% like other protocols in the market. This ensures there is high participation from darknodes.

Polling Duration: Yes. Polls should be 48-72 hours. This would also ensure that darknode operators participate.