Obv we are in a bit of a downtrend, but i’m wondering if making RPL ineffective for voting if <10% borrowed ETH makes sense for the protocol. This metric is a function mostly of 1) market conditions and 2) the specific snapshot block that is chosen; neither of these are controlled by the NO. A NO could be franchised yesterday, disenfranchised today, and franchised again tomorrow without touching their stake or node, or having any idea it happened.
Does this make sense from either:
security (minimal sybil protection protection as it can’t really be gamed), user experience (it is confusing for a user who was eligible to vote two weeks ago but not now for the redo vote), fairness (the NO may be doing what it seems rocket pool is asking- keeping RPL above 10% each reward period), price (raise your hand if you are buying RPL for its governance properties; I doubt it will matter much for price), or just community engagement (we want to encourage more small low collateral NOs to vote). Really it is not clear to me how the protocol benefits at all from restricting these voters.
On the more extreme side, it opens up a vector where if we trend towards NOs at minimum stake (which is a common theory of maturity), an attacker may be able to knock out a large portion of the electorate with a well placed sale into low liquidity.
Maybe some ways to combat this:
1). The easiest (which doesn’t require any changes) would be to use the upcoming rewards snapshot as the voting snapshot by default, unless there is a need for extreme speed and can use the prior reward snapshot. People are most likely to tune in around reward time, and to access their node, so it’s probably a good time to have votes.
2). Forgo the minimum RPL for voting altogether for voting
3). Allow voting for folks >10% either at voting snapshot or last reward snapshot (if possible)
But wanted to see if there were good arguments in favor of precluding NOs temporarily below 10% from voting.
Folks below 10% are, in some way shape or form, not in “good standing” - this is why we don’t give them rewards, and the vote can follow the same idea
Folks much below 10% start losing alignment. (That said they’d also have less vote power, so maybe that’s not a huge deal)
I’m actually comfortable with: “vote allowed from 0%”, “vote allowed from 5%” (or other desired threshold to avoid people falling out on accident), current state.
I don’t think I like the variants that include reward snapshot timing - just an extra thing to juggle and explain to folks.
9/4 edit: While I still believe what it “should” be can be argued both ways, I think what it was when RPIP-4 was finalized is unambiguous. It was from 0-150%.
To be eligible for vote participation, the RPL must be effectively staked in the Rocket Pool protocol as reported by getNodeEffectiveRPLStake().
At the time of the vote on RPIP-4 getNodeEffectiveRPLStake() reported RPL below 10% as effective and only cut off above 150%. The Atlas upgrade changed what getNodeEffectiveRPLStake() does. I think you could argue that RPIP-4 never intended to only count above 10%.
I also looked through the original discussion thread and could find nothing on this aspect of effective stake.
Based on this quote, I understand not counting RPL above 150% (to avoid the situation of someone with a single validator and a huge amout of RPL to buy/sway a vote). Not counting people below 10% seems like a possibly unintended double penalty to people already suffering from unfortunate buy-timing.
Ok. So it seems like everyone that spends enough time is coming to essentially the same conclusion (came up again in RPL staking discussion thread):
When RPIP-4 was finalized, this gave weight to RPL from 0-150%.
At a later time, the smart contract was changed, so the function being used gave weight to RPL from 10-150%. This change may have been desirable for other purposes but was NOT a purposeful pDAO directed change to voting power.
RPIP-1 allows changes to a Final RPIP to correct errata and add non-normative clarifications. This seems like a good candidate.
The change would be from
To be eligible for vote participation, the RPL must be effectively staked in the Rocket Pool protocol as reported by getNodeEffectiveRPLStake() .
to
To be eligible for vote participation, RPL staked in the Rocket Pool protocol is counted, up to a maximum of 150% of the value of the bonded ETH on the node.
Call to action
Please vote on the poll and write a comment if disagreeing
Agree; RPIP-4 unambiguously allows 0-150% to vote
Mostly agree; it’s mostly clear that 0-150% should be able to vote
Disagree; it’s not clear who should be able to vote per RPIP-4
Disagree; it’s mostly clear that 10-150% should be able to vote
Disagree; RPIP-4 unambiguously allows 10-150% to vote
While I think 0-150% should be able to vote, I do not think this it’s clear at all that this is what RPIP-4 intended.
RPIP-4 mentions ‘effectively staked RPL’, and this has never included the 0-10% range. I don’t know why getNodeEffectiveRPLStake() reported below 10% as effective at that point in time. But since there was no discussion on this aspect, that seems like an implementation peculiarity rather than a conscious governance decision.
To me it seems that the implications on voting of having a significant share of NOs below the 10% cutoff were simply not foreseen at the time. Thus, retroactively assigning such intent to RPIP-4 feels like a convenient shortcut to me.
As annoying as it may be, I think the proper course of action is a governance vote to clarify. I recognize that this is less than ideal as well, as the people who would benefit would be excluded from voting themselves. It does bring another opportunity for the pDAO to show they follow due process even when inconvenient, and that they are willing to vote beyond direct personal interest.
The RPIP specificially says “as reported by getNodeEffectiveRPLStake()” which did include the 0-10% range. We did allow people below 10% to vote in past votes and nobody raised it as an issue. The way snapshot voting works was changed without any governance vote to support that change and in my opinion to proper course of action is to roll back that change. I think it’s ridiculous if we have to vote to undo actions taken without any authorization.
The fact that no one raised an issue is not an argument either way. If anything, you could say that the current implementation is in line with RPIP-4 intent and the original one was not. And if one says ‘whatever this method implementation does is leading’, then it has always been in line. (For the record, I think having RPIPs refer to specific method implementations is a bad idea.)
I did not personally examine whether getNodeEffectiveRPLStake() did in fact report 10%-150% as effective, as was the common understanding of effective stake. Perhaps @Wander , being the original author of RPIP-4, would be willing to clarify.
Even so, I don’t think my understanding is an uncommon one; few community members would examine a smart contract to see if a function in fact does what it’s name implies.
As I see it, we need the pDAO to make an explicit, conscious choice on this.
My main point is: A change to how it works should come after the pDAO makes an explicit choice, not before. But a change was already made now, before the pDAO made that choice. This should not have happened and I think accepting the new state as status quo unless pDAO makes an explicit choice is a very bad look.
Okay, that is a convincing argument. Only if you subscribe to the ‘code is law’ interpretation of RPIP-4 would there have been ‘no change’ to status quo even if functionality changed. But I don’t think there’s proof that that was the common understanding at the time either.
Still, the poll is about RPIP-4 wording and intent. We still need to resolve that, but I think you make a good case for rolling back to the original functionality and only then having a clarifying vote.
If we’re talking about “common understanding”, the reality is probably very few people read it, let alone chased down details.
Still, the poll is about RPIP-4 wording and intent
I disagree with this. It’s about what it says, not about intent. We can’t have the internal state of some people’s minds overrule spec as written. Imo, when a spec says “x as reported by y” it is unambiguosly defining x to be the output of y.
You are right that the RPIP spec would’ve been better served avoiding functions etc (a thing I also need to fix up in an upcoming rpip). The spec should be SC independent, the reference implementation can talk about those bits.
I wouldn’t be so quick to dismiss intent entirely. This seems to me a letter of the law vs spirit of the law question. Letter of the law here would be “x as reported by y”. But even there you have ambiguity: “as reported by y at this specific point in time” vs. as “reported by y at any point in time”. The latter being the strict code-is-law interpretation. (which I don’t subscribe to, but we’re talking spec as written now.)
Another ambiguity is that there is a conflict between what ‘effectively staked RPL’ means in all other definitions, and what it appears to mean in this specific instance. Following the letter of the law for ‘x as reported by y at this specific point in time’, you find something that no one understood as ‘effectively staked RPL’ in any other context (that is, 0-10% being effective too).
Spirit of the law would be trying to find lawmaker’s (pDAO) intent in order to resolve this ambiguity. But it doesn’t seem we’ll get a satisfactory answer there.
So, pragmatically, reverting to old status quo and then proceeding to clarify via vote seems best to me. IMO, amending the RPIP to state 0-10% was intended is as much a judgment on original intent as saying it was not.
Reposting this thought here so it doesn’t get lost in #trading history-
The surefire way to remedy this without setting a precedent is to vote twice, once with a strategy for 0-150% and once with a strategy for 10-150%, and link the outcomes.
Making a decision based on a discourse poll sets a precedent, as does voting with one strategy but not the other.
Personally I feel like this route is overkill but if there is contention about the path forward I think it’s a good option of last resort.
If <10% is allowed to vote, does it mean that a node with 0 minipools and a dust RPL can vote?
If so, there’s possibly an attack vector here, given a quadratic voting power.
There are several levels at which this episode is concerning for governance and hopefully has some lessons that we can carry forward. To me, it is evident that the pDAO should allow node operators with <10% to vote and that the intent of RPIP-4 was most likely to allow node operators under <10% to vote. I think there could be reasonable people who disagree with my opinions, as there is some ambiguity particularly with the common use of ‘effective RPL’. If there is a community member who is willing to stick his/her neck out to say that the intent of RPIP-4 was to only allow NOs > 10% to vote AND that the protocol should continue to only allow NOs > 10% to vote, then I think we settle through governance before proceeding to other votes, realizing this may delay other business by several weeks.
It was intended that voting be based on Effective RPL Stake, which is 10% -150%. This term has been clear to the community for a long time, because it is not only used in voting but also RPL rewards.
The intention was clear but there was a bug in the function. Initially, we worked around that bug in the smart node and then later fixed it. Unfortunately, because RPIP-4 referred to the code it made the statement a contradiction. We never changed the concept, we just corrected the contradiction.
100%
I strongly disagree. The spec is a leaky abstraction for intent but it is the intent that matters. That said, we both agree that it should not refer to implementation.
It is pretty obvious that we are having this conversation because of the market condition. Whether <10% stake should vote is up to the pDAO but the term effective stake has been clear throughout. If we want to change it, the pDAO (as it is today) should vote to either change the term effective stake (which has some repercussions) or define it in some other way. I know that @Valdorff has some thoughts on how.
