Should Rocket Pool adopt snapshot voting as described in RPIP-4?
Support
Oppose
0voters
I propose we establish snapshot voting as a way to gauge community support for proposals and enable legitimate action for those which have that support. To this end, I’ve created the above RPIP-4 (draft) document to describe this process.
Outstanding Questions
How is a vote date for a proposal set?
How much support is necessary (majority, 2/3, 3/4, etc)?
Great questions! My opinion: I don’t think we should require RPL to be staked to vote, at least at first. Perhaps we can devise a more perfect and custom voting mechanism in the future.
I like it. Quadratic voting seems like a clever way to keep things more fair. Node-locked RPL should make it more sybil resistant too, since making many nodes is more effort than sending RPL to many addresses. We should still allow non-staked RPL to vote though.
I’ve been wavering back and forth on how much we should allow rETH holders to impact pDAO governance. Theoretically, long term RPL holders should be incentivized to vote in the best interests of the protocol as a whole, including the rETH side, since they’ll make money if the protocol grows over time. However, it’s probably reasonable for rETH holders to have some representation, just so they can hold the DAO accountable for any excessive proposals from node operators.
I think our community of RPL holders is aligned enough to block crazy stuff like, “Increase the commission rate to 50%”, but I could see DAO representation as a nice confidence boost to distrusting potential rETH investors.
There might be a way to use the withdrawal address to vote with staked RPL so users do not have to export private keys (very bad) or sign something from the node itself.
I’ve updated RPIP-4 with more specific implementation details. The current implementation requires NOs to vote from their withdrawal address; NOs will need to set all of their nodes to one withdrawal address they wish to vote from. Of course, the only way to prevent this would be to revert to a different voting mechanism that doesn’t depend on sibyl-resistance like 1-to-1 token votes.
Is the idea that quadratic voting would give larger weighting to smaller RPL holders – a form of whale resistance? I’m imagining the voting power might be something like the square root of your wallet’s RPL.
If so, a couple of points.
As a larger holder, I’ll abstain from having a strong opinion because it would clearly be acting in self-interest. Ultimately I want what’s best for RP.
Just for reference, there are valid reasons to break up large RPL positions into multiple wallets/nodes, including separating the withdrawal addresses. This includes technical and economic reasons. 0xb8ed+0xca31 is an example (myself also). As a result, this would probably mean you’re not as sybil resistant as you might think.
Perhaps obvious, but structuring the voting power in this way would encourage the separation of RPL into different nodes+withdrawal addresses for those who want to optimize for voting power. It may have the net effect of underweighting “honest” whale voting and overweighting “dishonest” whale voting.
Yes, my suggestion of quadratic voting is to get us closer to a true “1 person, 1 vote” model while acknowledging that this isn’t truly possible in reality. Even under quadratic voting, you or other whales could create a new wallet for each of the individual RPL tokens you hold and then vote at full power with each of them, but that is quite a lot of work and gas expense.
structuring the voting power in this way would encourage the separation of RPL into different nodes+withdrawal addresses for those who want to optimize for voting power
This is true. Quadratic voting isn’t perfect, and this is a downside. I do, however, think it’s better than a small group of whales controlling a majority of the vote, which is possible under a 1-to-1 voting mechanism.
EDIT: Threshold voting is another mechanism to consider, though QV is probably better at preventing incentives to create a ton of small RPL wallets for voting.
1st people that has staked rpl is obviously interested in the best performance of the platform because they are clearly invested and will vote in RPL protocol best interest.
2nd tvl is the second best approach imo, buy inferior to staked rpl.
3rd a voting wallet should be chosen from the node. like the rewards wallet.
Would there ever arise a circumstance in which we would want to convey governance and voting rights to rETH holders? Could we do a snapshot vote from both sides of the protocol. A vote by NOs via RPL and a vote from regular stakers via rETH.
A snapshot vote for rETH is pretty easy from a technical perspective. RPL requires a custom strategy to account for staked RPL, but rETH is straightforward.
My opinion is that we should start with RPL voting first and later debate the merits of including rETH voters, weighting staked RPL, or any of the other more complex ideas floating around.
The team have been thinking about this a lot and @nickdoherty has already started looking at what Snapshot can do for us.
Much of our discussion is the same as above, this is where we ended up:
rETH stakers - use a quadratic token vote - this is built into Snapshot
Node operators - use [age of oldest minipool] combined with [quadratic token vote on effective stake] - this we would have to build, you can build plugins/strategies. Using the oldest minipool adds a time element, the longer they have been staking the more invested they are in Rocket Pool. Voting would be done through the smart node CLI.
RPL holders - this is somewhat controversial… but nothing , unless we can reliably determine they are LP’ing or Lending. The thought here is that we want to encourage people to put their RPL to work.
Thanks for sharing the team’s thoughts on this, @langers! If the team thinks we can prioritize a more complex Snapshot strategy and a Smart Node voting feature, that’s great news
As for RPL holders, I like the idea of preventing unaligned vote-buying here by requiring it to be staked – this also helps increase sybil resistance naturally via gas fees for nodes. I also like the idea of including node age in the calculations, since that helps prevent vote buying post-withdrawals, too. I’ll work on adding this to RPIP-4.
@nickdoherty if you come up with an implementation that you like, please let me know so I can make sure the spec matches up.
EDIT: I’ve updated RPIP-4 to include requirements for staking and age weighting for RPL.
Given the additional sybil attack and vote buying protection for RPL votes, I believe they should be weighted higher vs rETH, which is more game-able.
Another question which came up for me during this: what about multiple-choice votes? Is this valuable? It complicates the results algorithm somewhat, but Snapshot supports it by default.
Hey all, just checking in to see if Pieter’s idea of a quorum has been discussed. Could there be votes where rETH vote one way and RPL vote another? Do we need a minimum participation of NO to consider a vote valid?
Excellent question. Thank you for bringing this up. RPIP-4 currently doesn’t contain any provisions for a quorum, but I agree that this is important.
Another idea I’d like to jam on is a minor penalty to staked RPL for not voting, with the proceeds going to the pDAO. This adds a tiny bit of sybil resistance and would likely increase node participation, but it could lead to other issues. I’m curious to hear everyone’s thoughts on this.
The quorum topic is a difficult one. There are three groups of people that can be represented, “rETH holders”, “RPL holding non-Operators”, and “RPL holding Node Operators”. Of the three, I think the only GROUP we can reasonably expect to have a minimum vote threshold is the “RPL holding Node Operators”. I think this is also the only group we can know about and thereby penalize.
I think it is an interesting idea to penalize non-voters. Just as a note, it means we’ll always need 3 options for voting: Yes, No & Abstain.
After giving this more thought, I’m starting to come to the conclusion personally that it’s best to assign exclusive voting rights to staked RPL and not use rETH voting. This may be controversial, so here is my reasoning:
rETH voting is inherently gameable (see discussion linked above), so the only available strategy is 1-to-1 token voting, which means vote buying must be expected. Not only is this inherently unfair, but this could create more havoc with the rETH market, which is already “off peg” due to the NO bottleneck. It’s a bad experience for rETH holders if value fluctuates heavily, and this weakness could turn off potential integrations.
We can drive value to RPL by giving it exclusive voting rights. I believe we should consider a DAO goal of “sustainably and safely increasing the value of RPL”, as the token ultimately represents the value of the RP project as a whole. This is best discussed elsewhere, however, since it’s a bigger topic.
The kinds of votes which are, at first glance, only applicable to rETH holders are also applicable to RPL holders due to the intertwined nature of the protocol. @nickdoherty suggested rETH integration requests might be irrelevant to NOs, but I believe NOs will always have a vested interest in increasing rETH adoption. I can’t think of any proposal which affects only rETH, though the opposite might be true.
Quorum calculations are difficult for rETH as @connerjason pointed out above.
)
, unless we can reliably determine they are LP’ing or Lending. The thought here is that we want to encourage people to put their RPL to work.