I really like this idea, but what would the rETH threshold be to veto?
Due to some confusion, we have decided to make this a poll in a seperate thread.
https://dao2.rocketpool.net/t/snapshot-voting-poll/761/3
Please cast your votes.
There have been significant edits to RPIP-4 since I made this thread originally. At this point, I recommend everyone review the current text and provide feedback asap.
Iâm leaving it in a draft state for now, but it will be finalized shortly before a vote for it takes place. Weâll likely try to get this going right after this next round of votes on RPIP-10, RPIP-11, and the IMC initial members. This translates to a vote on RPIP-4 sometime between Aug 26 and Sept 2, so I highly recommend that everyone in the community take this chance to review and provide their feedback, especially on some of the specific numbers included.
Despite its purely procedural role, this is a significant formalization of governance for Rocket Pool, as it creates restrictions on how we create and vote on proposals moving forward. I know it may be hard to develop an opinion on something without an immediate practical effect on the protocol, but this will affect every proposal going forward, so we need to get this right.
The first veto consists of those with the power to bring forward a vote (see Implementation above) refusing to bring such a vote forward for consideration. Although potential changes can be technically implemented by the implementer (oDAO or pDAO guardian depending on the proposal) regardless of vote, the implementer MUST NOT do so and any such action is considered illegitimate.
I take issue with this. There should never be a reason to not vote on something.
For a vote to even come to be, the following must be met:
All Rocket Pool governance proposals MUST have an associated post on the governance forums at dao.rocketpool.net. Promising community sentiment and a corresponding RPIP document are REQUIRED for snapshot voting to be scheduled.
So if the community seems to want this, not letting us vote on that is a very bad thing to do.
If all prerequisites are fulfilled, a vote MUST be initiated so the community can clearly state their oppinion.
If the voting result really isnât good for the protocol, this vote can still be vetoed! But at least then we had a vote which cast more light on the issue and people will be more interested in the outcome.
Not having a vote is like sweeping it under the rug and hope it will be forgotten.
2 Likes
Reasonable take. My personal preference is also to get rid of that first veto at some point.
That said, this section was written with realism in mind - we thought it was critical to capture reality as it exists. We are literally UNABLE to force langers (or anyone) to act and put up a snapshot vote. There is an owner to the snapshot page. Therefore, this soft veto power exists. What we can do is set up expectations around it, which is done in the last 2 paragraphs of the section. Hopefully these paragraphs are taken very seriously by the folks capable of exercising a veto. I believe they have been good stewards so far and hope they will continue to be good stewards.
In the long run, I think on-chain governance provides better protections (though it has its own challenges).
Well but that same paragraph also states that the implementer could act without a vote which is illegitimate.
So by the same logic we should write:
Although those with the power to bring forward a vote (see Implementation above) could refuse to bring such a vote forward for consideration, the responsible entity for setting up the voting MUST NOT do so and any such action is considered illegitimate.
With such wording it is clear that the risk is present but doing so is not an accepted action. Thus, we would have captured both the reality and the desired behavior.
1 Like
I see. The only case that got MUST NOT in there was purposefully implementing something that failed a vote.
The other 2 cases (snapshot not created; implementer doesnât implement) were treated as âSHALL NOT be used lightlyâ etc. Youâre arguing for snapshot creation to be worded more like the first case. Reasonable.
I get where youâre coming from, though I think itâs nuanced. If someone from CompetitorX openly brigaded a bunch of CompetitorX folks to our forum and showed clear âsupportâ on a poll, MUST the vote be created, or would we rather there be an explicit no-vote-created with a report on why this was done? Yes, we could turn it down, or even veto at the implementer step, but in a clear case like that⌠why waste the time?
I think this is a strong start (which is why I voted Yes), but itâs not an end state. This is a worthwhile detail to discuss and iterate on if the community sees fit.
If someone from CompetitorX openly brigaded a bunch of CompetitorX folks to our forum and showed clear âsupportâ on a poll, MUST the vote be created, or would we rather there be an explicit no-vote-created with a report on why this was done?
IMO, that is exactly why a vote is needed. Posting in the forum can be done by anyone. But for voting, you need staked RPL!
So in your case either the vote would fail proofing that the forum brigade were empty words and showing to the outside world that we let the people vote on all different stuff.
Or, if the competitor would actually invest so much RPL to be able to overthrow ânormalâ RPL votes, then it is important to see that, so that we are aware of this. Then we can act accordingly and maybe exclude a malicious address from voting or whatever.
If we simply donât vote on it, the competitor will still have a majority of RPL and will simply use it in the next votes to try to harm the protocol without us noticing. And the news will report that the Rocket Pool DAO is not decentralized because people canât vote on stuff and that Rocket Pool is a dictatorship!
So all in all I would say, that this further shows that voting is always good and MUST be initiated if the prerequisites are met. 
In my eyes, it would maybe have been better to make this RPIP about what voting should be and not mix it with current state.
Now we have the same problem with normal votes in my country (Switzerland): They mix two things together into one vote and if you are against one you have no option of only voting yes for the thing you like.
So I either vote yes because I like the overall proposal. Or I vote no because I donât think anybody should have the right to not even let us vote. And I appreciate that the plan is to somewhen later maybe specify this more and vote to not allow this behavior anymore. But right now I would vote in favor of somebody not letting us vote with no guarantee that this will be changed because that change-vote itself might even be vetoed!
P.S: I totally donât think anybody from this awesome team would do that. Itâs more the principal on voting in favor of stuff that is basically not final yet anyway and has some flaws in it.
not mix it with current state
Current state was incomplete, and we need to be able to work from something. I was quite uncomfortable running the last few votes without a foundation (we mostly used a draft RPIP-4). Thatâs why I want the initial step.
They mix two things together into one vote and if you are against one you have no option of only voting yes for the thing you like.
Even if itâs just future-looking, we always have this issue: thereâs many sub-bullets and the vote is on the monolith.
FYI, thereâs been some great engagement in the discord #governance channel. This is a good place to start.
Why do the governance proposals have to be limited to two options, yes or no? What if there is some third option, like âdelay for more discussionâ that some people would like to have?
I can foresee some proposals that I agree with in part but not in full.
In an ideal world, the âmore discussionâ phase is taking place in Discord and here on the forums prior to something being moved to an official vote.
3 Likes
As @calurduran says, we hopefully get engagement before the vote, so most things get represented, even if we donât have exact weightings.
If you are unwilling to accept the package as presented, thatâs a âNoâ. An alternative package can always be proposed later (after further discussion).
If you want tweaks, but are willing to live with the package as presented, Iâd suggest thatâs a âYesâ in most cases (unless something truly has no time sensitivity). Tweaks can always be proposed later (after further discussion).
I think you should expect to vote on things where you partly agree quite routinely. Very few votes will be so simple that all parties will wholly agree/disagree.
1 Like
As for early engagement, I definitely agree thatâs ideal.
For this particular vote, the discussion was started half a year ago and people like lost track of its status / engagement at some point (personally guilty. 
) The bootstrapping problem of voting on how to voteâŚ
By the time it was readied to be brought up for voting, I was under the impression there was a pretty broad consensus, until the against votes started rolling in. That was a good wake-up call which opened up some interesting follow-up discussions. Which gave us more insight into the topics people disagree on, potentially guiding a new iteration or follow-up RPIPs depending on whether the vote passes.
In my understanding:
- involvement of rETH and unstaked RPL in governance
- linear vs quadratic voting (the latter being more vision aligned, but somewhat ineffective/gameable for lack of sybil resistance)
- who can raise a vote / vetoes
Agree with Valdorff even with broad engagement beforehand itâs still unlikely to have full consensus on non-trivial issues. And this is not a bad thing as otherwise the vote itself would just be rubber stamping.
1 Like
Excellent summary, thank you @Pieter. It looks like RPIP-4 will pass, but our work here is not done by any means.
This is now playing out. Marko is voting with RPL owned by Patricio. At the same time people that hold RPL have no say.
Itâs worth noting that while the vote from marko/patricio was executed by a wallet controlled by marko, we donât know the details of their agreement, and itâs possible that they came to consensus on how to execute it.
Yeah, we donât know this. The point still stands though. With splitter / SaaS contracts, by default the Node Operator role holds the ability to control voting power over all RPL entrusted to them, by setting the voting delegate to a wallet under their control.
Have the SaaS designs considered this? Some way in which the RPL providers remain able to exercise voting rights would be good to avoid being a centralizing force on governance. But itâd probably have to be quite a complex designâŚ