Governance Process Fixes

The recent vote has been, in my opinion, an unmitigated disaster of governance which will leave the pDAO scarred forever. No matter which options wins, the community has lost a lot. Although I predicted and warned against this outcome, the vote was held and destruction was the result. It is disturbing to me that a tokenomics decision is being made in such a contentious manner.


Making Governance More Resilient

With that as the backdrop, it’s become clear to me that there are some major flaws with RPIP-4 as it is currently written. As its author, I feel it’s important for to take some responsibility for analyzing the issues and presenting my suggestions for improvement. Ultimately, the goal of these suggestions is to clarify and fortify the process so that debate can focus on the issues instead of the process.

1. Specify “promising community sentiment”

One of the requirements listed for a snapshot vote is unfortunately vague: promising community sentiment has been interpreted very broadly and needs clarification. I noticed this a while ago but couldn’t rally a fix in time to avoid community members accusing each other of vote-blocking. I want to be clear: these accusations are bad-faith engagement and must not be tolerated in this community.

To help refocus the debate, I suggest more specific language such as affirmative support from at least 33% of voters in a forum poll with at least 30 votes. Numbers may be adjusted, but the general idea of more specificity will help avoid meta-level disagreements.

When discussing this, please keep in mind that forum votes are easy to manipulate and cannot be reliably used as an indicator of community sentiment. Therefore, I believe this clause is still best used as protection against the simplest governance failures like poorly considered proposals and not as a gatekeeping mechanism for snapshot votes.

2. Higher Threshold for Vote Success

Most other protocols use a higher threshold for vote success. I suggest 66% minimum support for simple approval polls and 15% minimum margin of victory for mutually-exclusive, multi-choice votes. In the case that these requirements are not met, no proposed changes would go into effect.

The purpose of this suggestion is to prevent community fracture, which I believe to be far more destructive than inaction.

As Ethereum, Linux, and other successful FOSS projects have shown, loose and disorganized decentralization sometimes means progress is very slow. This has historically been the right path for Rocket Pool, as well, and the current situation has reaffirmed this approach as correct to me. Consensus is difficult and should remain difficult. A thin margin vote means the community has not achieved sufficient consensus.

3. Lengthier Debate Times

Currently, the requirements state: All Rocket Pool governance proposals MUST have an associated post on the governance forums at ... Topics SHOULD approximate community sentiment by including a poll with the following format which MUST be live for at least 7 days:

With this wording, I was trying to allow a shorter discussion time for simpler proposals, with the assumption made that divisive topics would not be brought to a snapshot vote until sufficient discussion time. This assumption was wrong. I assumed community willpower for unity and compromise would overpower the desire for action, but this isn’t true.

It’s clear that, even at the cost of slowing governance actions, RP should significantly lengthen the required discussion time. At worst, a topic with clear consensus is delayed slightly, which is a small price to pay for avoiding contention.

I suggest changing this requirement to: All Rocket Pool governance proposals MUST have an associated post on the governance forums at **which is live for at least 21 days of discussion**.

4. Required Research and RPIP-1 changes

Votes are a forcing function for the community, and we should only get to that point once enough information is available for everyone to make decisions. We especially should only make tokenomics decisions after examining an abundance of hard research.

The current vote does not sufficiently meet this bar. There is not an RPIP for each of the choices, only a single RPIP which was finalized by its own author(!) while an entire section was marked “TBD”, and the only justification given for the choices presented were references to forum conversations for two of the three options presented in the poll. Language inside of an RPIP such as “This [value] will be resolved by Snapshot vote” is explicitly dodging the responsibility of the proposer to a) create a sufficiently specific proposal and b) do the full research needed to describe the implications of that proposal. I recognize that many excuses will be brought out to defend this specific situation. “We were time-limited, we needed to ratify RPIP-8, etc” This is incidental. RP can and must do better with the governance process, and these excuses are unacceptable in light of the damage that has already been done.

Currently, votes must be based on thorough research in the form of an RPIP which describes expected effects on the protocol according to the standards laid out in RPIP-1. It seems clear to me that RPIP-1 is not specific enough in its direction to editors and authors. I suggest that we specify further the exact standards which RPIPs must follow, such as: clarifying the exact function and outcomes of editor review, language which prevents authors from reviewing their own RPIPs, requiring a certain depth of research in regards to implications for the protocol, and most importantly, extreme specificity in an individual RPIP.

As an example of why this is an issue, I’ve noticed a trend recently with newer RPIPs written as if they were laws. These proposals are creating their own systems for updates and therefore bypass the agreed governance process. RPIPs are being marked as Finalized in an unfinished state with controversial terms filled in later through non-standard processes. I consider this a governance exploit which should be patched. RPIP-1 should be amended with language that limits the flexibility of future RPIPs to amend themselves through non-standard processes.

For example:
RPIPs MUST be fully complete to be marked as Finalized, with no missing terms or sections.
RPIPs MUST NOT specify a governance process which allows the proposal to be changed after Finalization
RPIPs MAY be overridden ONLY through the ratification of a newer RPIP which follows the same standards set forth for all RPIPs.

The goal is to allow incidental and regular governance decisions (e.g. committee elections) to be specified without leaving room for authors to take the attitude of “we’ll decide the details later”.

Future Research

The above suggestions are the most relevant changes which can be made to improve the process immediately. There remain other research initiatives which should also be considered, such as increased sibyl-resistence and accountability for governance participation. I encourage more engagement on these topics elsewhere.


So first, on a high level, I disagree. Regardless of result, I’ve been impressed about how debate has gone for the most part. Yes, there’s been an enormous amount of repetition. Yes, there has been a small minority of unpleasantness (ad hominem attacks, antiwhale nonsense, putting words in other people’s mouths, etc). Overall, however, people have been reasonably good. People have listened and been moved or not.

1- Strong agree. Until this vote I thought the ambiguity was a strength in that it gave the tie to a champion that pushed hard, which I consider good. Clearly, it also caused dissent, so I agree we should specify.

2 - you have 2 bits here and I’ll address separately.

2a - 66% forum poll approval. I think this is dramatically off base. Going to a vote should be much easier than passing a vote. If going to a vote is harder, then there is no point to having a vote. Imo, the whole point is to get rid of spam by doing a rough cut to identify items that don’t stand a chance in a full vote.

2b - must win by 15%.

The first issue is this isn’t always fully defined. Like in this latest vote, would that mean no LEB8s for now since no option is clearing this bar (as of now)? If so, I think it’s clear that’s nobody’s preference, so I’m not sure why we’d want our process to force that outcome.

My main sticking point is I’m unsure what justifies a supermajority for normal decisions. What’s the justification for requiring “the overwhelming will of the dao” and not just following “the will of the dao”?

3 - the result here would’ve been no LEB8s in Atlas, flat out. That result would’ve been worse than any available option. Per votes, the vast majority of dao members explicitly disapprove of that delay (99% voting power in the current vote). Why would we want to make a situation that would explicitly displease 99% of the vote?


First the stuff targeted explicitly at me and my RPIP… Not sure why an rpip would be needed per choice? A vote needs an associated rpip, yes, but I don’t think there’s an expected mapping here (let alone specifically one vote selection to one rprip).

You’re right that finalizing should be done by a non-author. There are 3 rpip editors. I’m one. You were on vacation. I checked in with Ken multiple times in the process. I asked for review from folks in the conversation in discord over and over and over, including on the final version. I got some feedback that got incorporated. I did the best I could while minimizing risk to inclusion in Atlas. Again, 99% of the dao is explicitly against that, so I feel like that wasn’t a crazy priority.

Insofar as the idea that an rpip can’t allow multiple choices that will be voted on… Why not? Our governance process explicitly allows multiple choices rather than just yes/no votes. I don’t at all see it as problematic for a proposal to allow the dao agency.

“Research” gets routinely trotted out as a panacea. What research? Here the disagreements that remained are about different guesses at future human behavior in various situations. This is subjective. We will not find a hard answer no matter how many hours go into it. If the world had verifiable correct answers, it would be a lot simpler. As a startup, we operate in regions of extreme uncertainty - but we must decide nonetheless.

We need to keep our processes from being so heavy they crush us. I would have loved to have a different author and editor, eg, but there wasn’t another person taking the wheel. Is the result 99% of the dao is against better? I strongly think not.

(in keeping with my slapdash work, apologies for missing bits here - I’m sneaking time away from family vacation for even a rough response)


So Wander i agree with most of your points (clarifying promising sentiment, higher passage threshold for contentious issues than 51%, longer debates, and definitely some hard maths) but not the conclusion. Sure, this vote was messy; mistakes were made; temperatures rose and words were said; feelings were hurt; and at the end of the day, the results of the vote are only meaningful insomuch as the developer team agrees with them, and like all tokenomics they may change again well before most people are affected by noETH or pETH.
But to me… this is good for rocket pool. There was an incredible amount of engagement, and most of it was positive. Many people who never thought seriously about tokenomics tuned in, and many people who never never thought they could influence a financial system cast a vote. And their vote mattered. This was not a RPIP that was spoon-fed for an 99% approval vote. I suspect in six months we will talk about this as a cautionary tale, but i seriously doubt any lasting damage is done, much less destruction, and definitely the time to judge that is long after the vote has concluded. We will learn from this about better ways to run our governance structure and harness the passion that is flowing out of the community. Better communication, and hopefully a better was of interacting with each other. We will make changes to protocols that will make future votes better. We can do better, and we will. But we are only one year old, and we still have a lot of growing to do.