Foreword
“However, I personally don’t feel like the governance structures at Rocket Pool are yet strong enough to support on-chain governance. i think we have some rather low hanging fruit to try and optimize first as a DAO.”
This was the conclusion of the post I had drafted when the team asked for input on on-chain voting. I never finished the post, and Houston was already heading towards audits, so it’s been sitting in my drafts for a long time. But I think the major points still stand.
The Problem
The security of pDAO on-chain governance (therefor the protocol) is linearly related to the number and sublinearly related to size of initialized honest voters. However, our actual turnout stays near 20% even accounting for a large level of delegated RPL stake. Due to the exponentially rising cost of attack as honest voter strength rises (due to both shallow liquidity and direct operative costs), we can increase our security by 2x or 4x by just improving voter turnout.
While it has been argued that Rocket Pool already has high turnout relative to most, or even all, other protocols, we are uniquely situated in several ways that lead me to believe we can target a higher participation rate:
- Each NO has a minimum of 20k USD (and rising!!) invested in the success of the protocol, and at risk in the event of malicious governance. There is no permissionless protocol that I know of (several elite NFT governance structures non-withstanding) that has such a high barrier, and thus such a strong financial incentive for stakeholders to be involved in governance.
- Due to the square root vote power structure, each NO has a much higher relative vote strength than any other protocol, which defeats the “my vote doesn’t matter” argument. For instance, 100 NOs with 100 RPL match the vote of a whale with 1M RPL. In LDO, 10,000 NOs would be needed to match that whale.
- The results of RP on-chain governance are much more meaningful for voting that other protocols; parameters are to be directly changed without interpretation or initiation by the Team. While the security council has the ability to interrupt some things, ultimately a malicious pDAO can thwart an honest security council.
- The community is much more engaged than other protocols irrespective of points 1-3.
Possible solutions:
So how can we increase voting behavior and thus security of on-chain governance? Here are what I think are some reasonably low hanging fruits. I believe all of them are possible and helpful, but it’s not necessary or even reasonable to enact them all.
I’d like the community’s thoughts on high value and straightforward solutions to improving NO voting behavior, either a few of those listed here or fresh ideas.
1) Increase the number of NOs voting:
a) longer voting periods for non-urgent votes Almost none of our snapshot votes benefited from having a voting timeframe of less than a month, yet we usually choose the minimum length; this will be somewhat exacerbated by the two-step voting of on-chain voting, further cutting into the time that a voter can vote. Preferentially make voting a month, unless there is a overwhelming public benefit in a shorter timeframe.
b) regularize and synchronize voting: for instance, we specify voting always ENDS on the same day, like the day after reward period when NOs are most tuned in. Even the most tuned in have probably come close to missing votes (like when there are two concurrently and a third overlapping vote gets added). For folks not on discord daily, I think it can be confusing.
c) allow NOs <10% to vote: ENACTED.
d) Allow NOs >150% bonded ETH to vote The exact same arguments hold as with the <10% contingent: these are the same voters that we allowed to vote before the price rose, and the ability to vote should not be based on price. Additionally (and this is a huge additionally) you can likely drastically simplify the delegation system for on-chain voting if you don’t need the RPL price oracle.
e) Pay voters Voting (or delegating to a high fidelity voter) is critical for the security of the protocol (almost as much as oDAO duties with on-chain voting), but it is time consuming and effectively provides zero benefit to the individual who does it. With on-chain voting, it will cost real money. It is essentially an act of charity, and anywhere else in crypto this would be seen as a bad incentive structure. At the very very least reimburse gas costs to voters so it doesn’t take both time AND money for no personal benefit. When we start charging to vote, it will definitely skew voting towards those who think they can personally financially benefit by affecting the outcome of voting.
2) Increase the amount and quality of delegation:
a) Payment of delegates, even small payments- increase competition and more engagement with the electorate, as it becomes a “job” to provide and receive good feedback and ultimately help others’ votes count.
b) prevention of the “super-delegate” problem: where a few delegates continue to accumulate vote power until they constitute a majority of vote power. This seems to be correcting itself generally (although problems are apparent with vote splitting in MC elections), but always could be improved.
Options to limit this include:
i: somewhat reverse popularity order for listing of delegates to default to less popular choices
ii: a mechanism that refers NOs to the delegates that voted with the greatest similarity to the NO (ie, asks NOs how they would rule on past votes and links delegates with similar records)
iii: some quadratic approach to delegated votes (eg, above 2% of total vote, the effective vote share falls off slowly, encouraging NOs to seek other delegates)
iv: a public delegate pool [eg, if i delegate to valdorff, 90% goes to him, the remaining 10% gets distributed evenly amongst all delegates, either linearly or according to vote power]
v: have a scoreboard for delegates (for example, including frequency of votes, and how early in the delegation period they vote)
c) Have hierarchy delegation choices (eg, i delegate to my own hot wallet; if i don’t vote dazerdog is my delegate; If he/she doesn’t vote, valdorff is my delegate; if he gets hit by a bus, joe is my delegate and so on). This will be a problem with the current implementation plan- but perhaps a better system would be (delegate1 + delegate2) instead of (node + delegate1) so people can use a more accessible wallet to countermand their delegate. [NB, this was before all the particulars were rolled out, so I’m not sure how this would work currently]
d) make delegation required in smartnode upon node initiation/megapool switch, etc This would make governance a duty expected of NOs
e) require NOs to periodically evaluate their delegation: For example, a hard stop upon certain smartnode upgrades that says something like “you are delegating to haloooloolo.eth, who has 7% of voting power; do you want keep this delegation y/n?”.
3) Improve RPIP mechanisms:
a) Improve the mechanism of draft RPIPs- there need to be more people involved early in the de facto decision making to indicate any true decentralization; by the time a draft is created most of the critical decisions have already been made. This is a big topic, and probably not one amenable to a quick fix.
b) Make RPIPs shorter and simpler; much of the fluff/explanations can be left out or linked for context- those are usually based on current conditions and may not make sense in 6 months or 6 years. Shorter, simpler RPIPs are easier to edit and more simple to addend. In MOST cases, make RPIP text in simple English, because specific implementations may change until the protocol ossifies; putting complex technical specs in the RPIP drastically increases the trust that MOST voters need to put in just a handful of technical interpreters.
c) Increased number of editors, and use of auditors to ensure contract upgrades are not affecting past RPIPs
d) Try to make NOs votes somewhat less public: The secret ballot is so so so important to meatspace democracy. While I think a true secret ballot will be overly complex in this regard, there can be some ground rules for our community about respecting the votes of others. To me, this means not publicizing the votes of individual doxxed members, not pinging NOs to ask them to vote different. Snapshot is terrible in this regard, as it forces you to see which vote is winning before voting, and also shows a preview of the top wallets, so early large vote signalers are often the first and last thing a NO will see, giving undue influence. In meatspace, its rare to get >90% of people to agree on anything, but the Web3 most common vote in web3 is ~99% to ~1% partially because of this influencer problem IN THE VOTING BOOTH.
e) Parliamentarian management committee: Consider a new elected committee that is tasked to deal impartially with interpretation and process for RPIPs. Currently, interpretation and process choices are decided by the people writing the RPIPs, which both introduces conscious/unconscious bias and puts a huge burden on the writers of the RPIP to try to be fair.
e) Increase the number of actual decisions made by the pDAO voting structure, rather than decided by a few people. This includes minimizing omnibus votes (votes with many parts that are yes/no together). By the time they get to a vote, RPIPs are largely a yes/no and most votes carry overwhelming majorities, often having many distinct and relatively unconnected aspects rolled together. People will be more invested when you are polling them on actual substantive questions (see nETH/pETH debate) and when their vote matters.
4) Increase security of the governance process:
a) specific research/project/grant regarding detecting and neutralizing sybil actions: we’ve spilled a lot of ink about it; it probably makes sense to have some formalized deep dive.
b) different vote threshold requirements for different levels of risk as the protocol ossifies: For instance, certain parameter changes or removal of security council members (those intended to be rarely used but pose a risk of attack) could require a higher quorum; major protocol changes could have an even higher necessary threshold than routine signaling by the DAO; very low risk (signaling or MC elections) could be done on snapshot or other L2 trusted option. We are still using snapshot, but haven’t well defined which signaling votes rise to the level of on-chain voting. This requires RPIP-4 to be re-approached.
c) Detect and respond to soft Layer 0 attacks: competitors just need some intelligence and persistence to subtly shift policy through a weak governance system or fomenting discord within the pDAO. This is probably the least expensive and potentially most effective attack vector (ie paying someone 60k USD a year to troll Discord or introduce subtly self-destructive protocol changes).
d) Penalize the vote power of penalized node operators: If you stole MEV, you shouldn’t be voting.
e) Introduce some simple anti-sybil actions: For example, increase in vote power based on longevity of node or number of previous votes; or choose some anti-sybil processes [gitcoin passport etc] to weight votes). Megapools will help to discourage sybil processes, but this remains the most likely route of malicious governance attack.
f) consider ditching the quorum idea all together, and instead enact a minimum winning vote level A quorum means that the optimal choice for voters whose preferred outcome is clearly losing is to boycott and hope the poll does not meet quorum. This both perverts democracy (voting for your choice makes it more likely that the choice you dislike gets enacted), and skews the results to appear more lopside than they are.
