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 dao.rocketpool.net. ... 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 dao.rocketpool.net **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.
and
RPIPs MUST NOT specify a governance process which allows the proposal to be changed after Finalization
and
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.