Hi everyone,
I didn’t intend to be mysterious with my vote; just a combination of really, really bad timing and some… interesting… IRL drama meant I couldn’t really put my thoughts together until today.
So! This is another one of those head-to-head votes. We haven’t seen one of these since the whole max effective stake for LEB8s debacle. Commmunity sentiment was really bad back then; luckily it seems to be much more civil this time around (at least, with respect to this vote itself), which I truly appreciate. I don’t think the results will be as earth-shattering as they were last time and people probably recognize that. That being said, it’s important to me that I do what I said on the “delegate to me” label and run through my due diligence of the options so that’s what I did today.
This is gonna be a long one because I’ve tried to be as thorough as possible in my exploration of the options, their ramifications, and who’s voted for what. Thoughts below, and TLDR at the bottom for people who, you know, CBA.
Preamble
Before getting started with the analysis, I have a few quick things I want to mention.
The Market
It’s certainly left a sour taste in the mouth of our node operators that their ability to voice their opinion in the protocol’s governance has been taken not because they misbehaved, but instead by speculators playing around with RPL or other node operators that decided to exit their minipools. It should be apparent to everyone that we’re in a bear market right now. Things will invariably be different in a bull market, as evidenced by the fact that they were different in the previous bull. Thus, the impact of whatever we decide here is somewhat reduced by the fact that eventually these people will be above 10% again, should they continue to be node operators in the interim. Whether or not a new governance system supplants this one entirely by then remains to be seen (as discussed at the end of this post), but for now, know that Rocket Pool itself is still going to be here tomorrow.
The Bug
The reason we’re even having this discussion in the first place is because Redstone had a bug. I’m still kind of shocked that nobody caught it, and that in and of itself is kind of telling, but nonetheless it was a bug. The intent was always for RPL’s voting power in governance to be tied to it’s rewards. No rewards, no voting. That simple. Nodes under 10% collateral would be eligible for both or ineligible for either. That was the intent.
When Redstone was first released, my Smartnode implementation relied on the very same contract function that ended up causing all of this ambiguity and chaos in the first place. I brought it up with Kane and we had to patch the Smartnode itself with the correct behavior shortly after Redstone was released. The result is that the Smartnode deviated from the contract implementation, but it matched the intent of the system, at least with respect to RPL rewards distribution. This caused the disconnect; the Smartnode did one thing, which the contracts were supposed to do but didn’t, and Snapshot did another thing, which is what the contracts told it to do. It didn’t know they were misbehaving.
This a pretty good example of the “code as law” argument. My opinion is pretty simple: code is written by humans, humans make mistakes, and we do our best to correct them. The fact that any proposals in Redstone allowed node operators under 10% collateral at all was a bug. But, as a few people here have stated, that ship has sailed. The behavior has been around long enough that we can’t simply patch it up, call it a day, and expect people to understand. They had something before and now they don’t, through no fault of their own, and that’s why we’re here today.
My Goals
Alright, onto the discussion! To be clear up-front, I have always tried to vote with the best interests of the node operators, and thus, the protocol in mind. 99% of the time those are the same thing and the decision isn’t very problematic. Today, however, it’s quite possible that they are different. So in that respect, here’s my clarified stance:
My primary concern is the ability of the Rocket Pool protocol to grant node operators the ability to validate the Beacon Chain. I will vote on things that strengthen this principle, and I will vote against things that threaten this principle. In situations where a vote does not do either, I will likely defer to others.
With that in mind, I’ve tried my damndest to evaluate which of those camps the two voting strategies we have in front of us fall into. Below is my evaluation.
Strategy as a Function of Quorum and Legitimacy
So when looking at the protocol’s health, there are a few things to take into account. The first is the safety of the governance process; without this, future votes on changes to Rocket Pool are at best uncertain and at worst completely meaningless. To explore this, I looked through previous Snapshot proposals and the state of the two current voter eligibility proposals. Results below.
How contentious are Rocket Pool governance proposals?
First and foremost, Rocket Pool proposals have hit quorum 100% of the time. Quorum is only set to 15% of the total possible voting power, which is low to me but I am told this is actually considered to be an impressive statistic among Ethereum projects. Proposals typically have ~150 to 300 voters out of 3200 total node operators; the delta between participation and voters is accounted for by both large node operators with many minipools and the delegation system.
Looking back at Snapshot’s history, we have had 20 “simple” proposals (with a choice of 3 options). I’m intentionally not including proposals around GMC and IMC makeup because those are harder to analyze from a contention perspective. Anyway, of these simple proposals, 18 have been almost unanimously decided. Only 2 of these proposals were contentious (where there was an obvious divide in community sentiment):
In both situations, the only propoposals to generate such contention have revolved around the amount of RPL required for node operators to participate in the network. The previous vote was decided with the argument that the community would rather have people with large amounts of RPL sell it to create minipools rather than sit on it, thus (presumably) increasing Rocket Pool’s market share at the cost of RPL’s value. This vote is based around whether or not node operators themselves should have a say in the protocol’s governance as a basic right of owning a validator, or if they should be required to buy and stake RPL in order to reacquire said right should they fall below 10% collateral due to market forces.
Arguments about the merits of the options aside, the only time the community seems to come to contention is when RPL’s utility with respect to node operators and protocol activity is involved. I can confidently say that this trend hasn’t gone unnoticed, and as long as the protocol’s tokenomics remain as they are today, I predict this divisiveness will continue.
Are the votes representative of actual voting participation?
As a quick check, I looked at who voted in the previous proposal (RocketSplit appeal) on August 27th and who also voted in the “All nodes enabled” proposal but not the “10% only” proposal, which combined with the above implies that they couldn’t due to being under 10% (cropped the results because of the character limit, sorry). There were 10 such nodes in total with a combined voting power of 118.96. That is a fairly small fraction of the total voting body (151 total voters for the RocketSplit proposal) and a rather small amount of voting power.
Next I compared it with the number of nodes that voted in the “All nodes enabled” proposal but not the “10% only” proposal. There are 50 such nodes (cropped the results because of the character limit, sorry). The “All nodes enabled” proposal has 209 voters at the time of this writing and 50 of them, with a combined voting power of 977.91, would no longer be able to participate when using the “>10% only” regime. This accounts for roughly 13% of the total quorum required under this strategy (7.4k).
That being said, this also implies that many of them may simply not vote unless their voice is threatened. We see 858.95 voting power that was not used in the previous vote. This is obviously not enough to threaten the protocol as the proposal’s quorum was hit handily, but it is nevertheless disappointing. It could be that they see overwhelming consensus and simply don’t see the point, but that’s equally discouraging. Voting is free and my opinion is that everyone should exercise their right to it when they have it but this data shows that nearly 25% of our unique voting body does not.
Note: you could certainly argue that I should look at more proposals than just the RocketSplit append one, I just don’t have the bandwidth for it right now so I’m extrapolating with what I have. Anecdotally, you can clearly see that the LEB8 max state proposal had a considerably higher turnout than non-contentious proposals on the Snapshot website, and these two are certainly going in that direction as well.
So in conclusion, yes - these votes are (mostly) representative of voting participation but contentious voting like this draws a significant number of people that did not vote in non-contentious proposal.
Are the votes legitimate?
In other words, has anyone made sure they’re all voting the same in both polls so we can get an accurate count?
I’ve looked at this, and all of the votes have parity between the two proposals with three exceptions:
0xC0C92c49f2e516550DA3EE5fecA2b2725bA32c7A voted for “>10% can vote” in the “All nodes enabled” proposal, and voted for “All nodes can vote” in the “>10% only” proposal. This is likely not a valid result and should be discarded, but they only have 17 voting power so they aren’t adversely impacting the results in a meaningful capacity.1entendre.eth (0x790c9E211aD5F71e6dAADFCB3d58df8a9cC749bA) and nocturnum.eth (0xF253f56F5b8118E9D28CC8dDA7316761f4a85fc4) both voted in the “>10% only” proposal but did not vote in the “All nodes enabled” proposal for some reason. Combined they have 36 voting power, which is not enough to adversely impact the results in a meaningful capacity.
Therefore, I can say that these results are legitimate and should be treated as such; i.e., there isn’t enough mismatching of votes to muddy the waters.
Are you accounting for the delegate override system?
Rocket Pool governance allows users to delegate their node’s voting power to a different address. Should the delegate vote in a way that you don’t like, you can “override” their vote by voting directly with your node wallet. This will direct your voting power to whatever you vote for, and remove your node’s voting power from your delegate’s own choice.
To account for this, which could certainly throw off the data above, I looked into the status of each delegate with more than 1 constituent. We currently have 414 nodes that have delegated to someone else using the rules above. Of those, there are only 6 total overrides out of the entire system:
JCRTP (0x689C6853f3deBac91b72f32BafA83200eeC9613C):
61 people delegate to this voter (18 under 10%, 43 over 10%)
Choice: Abstain
Voting Power:
976.099037 (All Nodes Enabled strategy)
823.978031 (>10% only strategy)
1 nodes with >10% power overwrote with a different vote (voting power: 40.126193)
0 nodes with <10% power overwrote with a different vote (voting power: 0)
rpvote.valdorff.eth (0xBb2b1CA23afCB616837F2966eb26C4C50ec8D080):
49 people delegate to this voter (16 under 10%, 33 over 10%)
Choice: Abstain
Voting Power:
827.793713 (All Nodes Enabled strategy)
494.648385 (>10% only strategy)
4 nodes with >10% power overwrote with a different vote (voting power: 235.730186)
0 nodes with <10% power overwrote with a different vote (voting power: 0)
waqwaqattack.eth (0x2600846F4401aE10CA760604036A891bb896649E):
21 people delegate to this voter (4 under 10%, 17 over 10%)
Choice: ≥10% borrowed ETH eligible
Voting Power:
861.117357 (All Nodes Enabled strategy)
829.149714 (>10% only strategy)
1 nodes with >10% power overwrote with a different vote (voting power: 32.883767)
**NOTE: override only occurred in the All Nodes Enabled proposal**
0 nodes with <10% power overwrote with a different vote (voting power: 0)
In short, almost nobody uses the override system. There could be a lot of reasons for this, but they are out of scope for this discussion. Suffice it to say, overrides are not significantly interfering with the data processing.
Data Conclusions
The above data suggests the following key points:
- Regardless of strategy, we have a healthy enough voting population to maintain quorum so the protocol itself doesn’t benefit from one strategy or another
- ~25% of eligible voters with ~10% of the total voting power may not vote in “trivial” proposals, but do vote when their voice is threatened
- These votes are legitimate and represent real choices, there isn’t a significant amount of invalid / intentionally “trolling” votes
- The delegate override system is not being used much, with the exception of Valdorff - in which case his “abstain” has been overwritten to the “>10% only” strategy
Thus, from a quorum perspective, I conclude that the protocol does not have a strong preference for either strategy. It slightly favors the “All Nodes Enabled” strategy in the sense that it enables an additional 10% of voting power, but quorum lately has been well over 110% (even with the current strategy of “>10% only”) so governance survives in both situations.
Strategy as a Function of Protocol Utility
The next argument is one related to how well the protocol can grow, and by extension (which will be discussed shortly), the ETH:RPL ratio. To recap, there are two camps:
- Undercollateralized nodes must buy and stake additional RPL in order to be eligible to vote
- Nodes that maintain at least one minipool should have a voice in the protocol, regardless of RPL’s value
The arguments for the former are almost non-existant here and it’s frankly quite disappointing to see that. This strategy is currently winning from a voting perspective but its propoents are grossly underrepresented in terms of voicing their opinion here. Either these people do not participate in the forum to express their opinion, which is bad, or they are intentionally choosing to remain silent… which is worse, as it leaves us to speculate - often presuming maliciousness in an unfortunate “us vs. them” tribalistic mentality. I have to play devil’s advocate and assume their choice of voting is because “>10% means number doesn’t go down”, as will be explored below, but would love for more people to come and correct me.
(Or option C, they’re voicing their opinion elsewhere and I just haven’t seen it, which is certainly possible but this is the thread linked to in the official Snapshot proposal pages so doing that seems like a mistake.)
The arguments for the latter case take a rather node-operator-centric view. I’ve seen quite a few of these opinions, both here and in the Snapshot voting comments themselves, from disenfranchised node operators and people voicing their support for disenfranchised node operators. The stance here is that node operators invested in minipools, are actively participating in the Beacon Chain duties of the protocol, and thus should have a say in the future of how the protocol operates regardless of market action. Anything less than that would be “silencing the voices of the little guys”, and as many state, this is antithetical to Ethereum’s ethos (and by extension, Rocket Pool’s).
To remove the sentimental aspect from this argument, which is not particularly compelling in an anonymous environment where Sybil lurks around every corner, let’s look at it in terms of math. Assuming the worst case scenario, at its peak the ETH:RPL ratio was 0.03581 (it is currently 0.012942, a 64% drop) which means users would have had to collateralize 6.64 ETH worth of RPL at the time for an LEB8 (83% of its cost in ETH) in order to still be above water today. I agree with @Patches that this is an unreasonable amount to expect node operators to stake when there’s such a narrative of “only 2.4 ETH worth of RPL” present, and realistically these people will not purchase additional RPL just to regain their voting power at current cost levels; ironically ETH itself has likely priced them out of this option. (I don’t think many people are actually in this camp; I think they’re substantially less underwater than that, but we’re playing devil’s advocate after all.)
That being said, I should note that people who wanted to stake on Ethereum and treated RPL as a “necessary evil” with little regard for it other than an up-front cost are not as directly aligned with the protocol as they may claim to be. In fact, none of the arguments here account for the impact on the voting strategy decision to the protocol as a whole, and this is what I was really hoping to read here but so far have not seen. Patches touched on the notion of Rocket Pool’s overall market share in terms of Beacon Chain validators, which is entirely valid, but not what I was looking for. So with little to go on, I’ll do some definitive exploration.
RPL’s Usage
Rocket Pool, as originally designed, has the RPL token deeply ingrained into its core. It manifests in six areas:
- Rewards for node operators for network participation
- Payment for Oracle DAO members
- Collateral in case of massive Beacon Chain slashing events
- Treasuries for the GMC, IMC, and general Protocol DAO to pay for improvements to the protocol
- Collateral in case of MEV theft (planned but not yet implemented)
- As a means to determine voting power in governance
Of these six:
- The first is relevant in the sense that node operators enjoy access to staking with lower ETH required and supplemental commission on that ETH. It gives them liquid capital for their efforts, should they have invested enough in the protocol to be eligible. Node operators who are currently undercollateralized are incentivized to “top up” to regain these rewards, but in reality many of them do not when the market swings too hard (which, I would certainly argue, it has).
- The second, while good in theory, doesn’t seem to make a difference in practice. Some Oracle DAO members claim and sell their earnings immediately, while others have literally not claimed a single time since Redstone launched. Either way, there was a vote to reduce Oracle DAO rewards to a small fraction of their current allocation, and every single Oracle DAO member agreed to it. None of the members raised an objection to the proposal. In other words, it’s clear that the value of RPL is not a make-or-break condition for performing Oracle DAO duties. I’m sure there’s some value where it would become a problem, but this level doesn’t seem to be it.
- The third provides peace-of-mind for rETH holders, and thus makes rETH itself more attractive. In theory a reduction of RPL’s value would reduce this peace-of-mind, but in practice the demand for rETH has been so overwhelming that this seems to be almost completely ignored. In other words, this is not actually a factor.
- The fourth does actually matter. As a member of the GMC, I’m responsible for voting on funding proposals to improve Rocket Pool from both outside parties and community members. My ability to do this is constrained by how much capital the GMC has available, and lower RPL value reduces this capital.
- The fifth will matter in a future release (maybe Houston, probably Saturn), but doesn’t matter right now. As we’re voting on the ability to make decisions about future iterations of the protocol, however, it is still relevant.
- The sixth is obviously relevant, otherwise we wouldn’t be here today.
So from the protocol’s perspective, RPL’s value is important: it manifests in areas 4, 5, and 6. From the single node operator’s perspective, it is supposed to be as it manifests in areas 1 and 6, but the arguments here tend to make that less certain.
Does a Strategy Imply RPL Price Performance?
Funnily enough, I’ve seen commentary (both directly in here and in Discord DMs) that voting for either strategy will cause people on the opposing side to exit their positions, sell everything, and walk away. That kind of behavior makes neither strategy particularly compelling from the perspective of protecting the protocol. I’m going to opt to ignore those threats and try to look at the options from the benefits they bring to the protocol instead.
Again, playing devil’s advocate, it appears that “>10% only” voters may believe that voting “>10% only” will cause RPL’s price to rise, or at the very least not fall; whereas voting for “All nodes eligible” will cause RPL’s price to fall, because it removes one of the reasons for people to purchase additional RPL in the first place: participation in governance. Note they had to have it to begin with; they can’t simply vote with 0 RPL, but it removes the requirement of topping off which is one of the things >10%ers attribute as value. As such, they’re voting “>10% only” either as a means for protecting the protocol… or as a means for protecting their bags I suppose.
I suspect this is not a correct argument. It relies on the belief that node operators will purchase additional RPL to bring themselves back up to collateral, and perhaps some have, but the vocal minority here indicates they have no intention of doing so. In fact, several have clearly stated the opposite. Regardless, voting for this strategy in the hopes of “number going up” doesn’t appear to hold merit unless the silent majority are doing so. I haven’t looked at the data on that yet, and my opinion may change once I do. It will take time to gather that however which I just don’t have and you could argue is required for my analysis here to actually be worth anything, so take it with a grain of salt.
On the other hand, “All nodes eligible” voters clearly believe some node operators been disenfranchised by market movement through no fault of their own. Those node operators may assume their RPL stake is a lost cause and refuse to bring their collateral back to 10% out of principal, or they may literally not have enough capital to do so.
The arguments I’ve seen for this feel a little incomplete too. If their stance is that “I care about myself more than the protocol”, it wouldn’t make sense for them to be lobbying for governance. They’d do what Patches’s evidence of 0xfd0166b400EAD071590F949c6760d1cCc1AfC967 demonstrates: they’d simply exit. I’d like to believe people vote for this option so that they can continue contributing to a protocol they do care about, and want to retain participation in, but cannot afford (literally or figuratively) the cost of doing so under the current rules. But if that’s the situation, I want to see more rationale about what kind of things they’d vote on and the impact their decision will have on the GMC and IMC’s abilities to help Rocket Pool grow.
Based on the stated positions of several people in both camps, either publically or privately, I’m not convinced that either scenario will have an impact on the ETH:RPL ratio outside of people threatening to exit if their option isn’t chosen. Whatever the case, though, one thing is likely: in both strategies, people may believe they are voting in the protocol’s best interests and yet they are doing so in mutually exclusive manners. That’s a problem, and it’s one we need to solve.
(Unless, of course, either party really is just voting to protect their own assets, in which case there’s nothing we can do to change their minds or explicitly state as much, is there?)
Conclusion
From the voting data in the first section:
- We know about 900 voting power will be lost in the “>10% only” strategy, which is not enough to threaten quorum. Governance will survive using either strategy, but more is always better.
- We know 20-25% of total voters don’t participate in governance unless there’s contention.
From the analysis in the second section:
- We know that RPL has utility for both node operators and the protocol itself.
- We know that the protocol benefits from RPL’s value in terms of GMC and IMC productivity, and the ability to use as MEV-theft collateral (in the future).
- We know that node operators benefit from RPL’s value by gaining access to staking with lower ETH required and getting commission on it, and participating in protocol governance.
- We suspect that one party is trying to protect the protocol’s benefits, one party is trying to protect the node operator’s benefits, and the fact that there’s a disconnect between them is a real problem.
The fact that there’s this contention in the first place is a sign that something needs to change. It hasn’t gone unnoticed and I’m sure it will be a very prominent topic for discussion in the near future; especially with Houston on the horizon. Whatever we decide here is likely to have a rather short-lived outcome; longer term, I wouldn’t be surprised to see some protocol upgrades that better align these two parties.
In the mean time, here is my call to arms for voters which may or may not gain traction but here goes:
- If you voted “>10% only” and you did so because you believe it is the best choice for protecting the protocol, please state your reasoning here. I’m guessing and I could be wrong so that’s not super helpful.
- If you voted “All nodes eligible” and you did so because you believe it is the best choice for protecting the protocol, please share what kind of changes you’d use your voting power to support.
TLDR; My Personal Stance
So coming full circle, where do I stand? To reierate, here is my position:
My primary concern is the ability of the Rocket Pool protocol to grant node operators the ability to validate the Beacon Chain. I will vote on things that strengthen this principle, and I will vote against things that threaten this principle. In situations where a vote does not do either, I will likely defer to others.
In that light, I don’t feel particularly strongly about either option right now because I want to hear more from the voters of both camps. I don’t see sufficient evidence to demonstrate that the “>10% only” option is a threat to the protocol outside of people exiting in protest, and I don’t see sufficient evidence to show that the “All nodes eligible” option will have a meaningful impact on protocol growth outside of people exiting in protest. What does threaten the protocol is a difference in outcome between the two proposals, because in that event, we will do this whole song and dance again which nobody wants to do.
As such, I will remain in the Abstain camp so my vote can be used to break a tie, should the situation arise. Because votes can change, I’m not convinced switching to one camp or another right now will resolve anything. I will use my power to make sure we only go through this once. Either way the protocol will be fine, we can all keep on keeping on, and I can go back to focusing on the Houston protocol upgrade.
Thanks for taking the time to read all of this, and we have 9 days to go. There’s still plenty of discussion to be had I’m sure, and I’ll keep tabs on how things play out in here.
