This doesn’t make sense. Is your claim that there was a bug known to the dev team and then the dev team purposely made snapshot implement vote power wrong (based on their understanding of RPIP-4)?
I don’t think this is acceptable. Allowing intent, as remembered from 1.5 years ago, to be a basis of governance can’t be how we run things. It means that the folks allowed to remember intention have all the power and new folks aren’t even allowed to know the rules. Your assertions of (a) what was intended and (b) what the current pDAO are a strong example of this. I can tell you I was surprised when folks stopped being able to vote.
Unfortunately the snapshot strategy was written with the same assumption that the Effective Stake was calculated correctly but it wasn’t. We should have worked around it but not sure why we didn’t, might have been a timing thing or just that the assumption was made without a question.
The Dev Team are fallible and I wear that, but to revert to a bug when the intent is clear makes no sense imo.
It has nothing to do with remembering. The concept is clear to the community - it is the same concept as RPL reward eligibility, they are very aware of it, then and now. New folks go through the same learning process, they learn about Effective RPL Stake because it touches so much.
22 community members wished to show an opinion.
You are dismissing the 68% of them who read it as saying 0-150% in favor of the 23% that read it similarly to how you read it.
Honestly – it feels like you’re dismissing community opinion in favor of your personal interpretation.
If it’s based on current interpretations, the poll demonstrably disagrees – this is why I thought it must be based on your recollection about when RPIP-4 was either drafted or ratified.
This is a small sample size for such a fundamental change. I will help to bring it to a wider audience by posting a protocol announcement. I am happy to work with you on the draft to ensure it is balanced.
As someone who helped to define Effective RPL Staked and proposed the voting system, I don’t think my interpretation is completely irrelevant (this goes for the entire team). That said, I am not dismissing anyone. I am concerned about making a fundamental change without wide community approval.
I agree the sample is small. But your posts above were not about getting a bigger sample. They asserted what was correct and that your preferred definition should be what votes for the next definition.
I hear where you’re coming from, but I don’t believe that system is stable. A number of the people in this forum thread and survey were also in the RPIP-4 thread. In this thread, I didn’t start out with a strong stance and was able to use a detailed reading of RPIP-4 to get to a clearer understanding of what I think is correct as agreed upon by the pDAO. I think it’s really important that people be able to read the rules and treat them as the source of truth. Essentially what I said earlier:
Apologies for the delay in responding. The original intent was for effective stake (10%-150%) to be counted, and I consider it a bug in the original function that this wasn’t how it was originally reported.
Personally, I think it’s a bit ridiculous that this conversation is even happening and that anyone is comfortable stripping utility from RPL, but at this point, nothing the DAO does would surprise me anymore.
If this truly needs governance action to resolve, an explicit vote is probably the best bet.
Is this helpful or productive? Absolutely have your opinion, but it’s unnecessary to call holding, or even discussing, a different belief ridiculous. Also unnecessary to take a swing at the DAO in a governance discussion.
We have reasonable people who think contradictory positions are indisputably correct. So definitely time to look prospectively to a vote. I for one am interested to hear the argument that the protocol is made stronger by forbidding voting by certain NOs when RPL ratio decreases (hence my reason for starting this topic).
Also, when we clarify RPIP-4, can we also change that pesky sqrt/2?
Also, please publish the time/date we are doing snapshot ahead of time, so I can top up beforehand this time.
Hey Guys. For context Rocket Pool launched with effective stake at min 10%, max 150%, this applied to both rewards and voting once it came in.
Our Redstone upgrade launched with effective stake at min 10%, max 150% with RPIP04 clearly written to have this to remain the same, but through a bug, it allowed voting below 10% on the smart contract side. We released a smart node update to not allow this through the node since it was clearly not intended. There was no drama around this at the time since it was clearly identified as a bug.
Our Atlas upgrade fixed this bug and did not allow voting below 10% through the smart contract. The fix was now applied to the smart contract side, as well as the smart node side which was fixed previously during Redstone.
Voting below 10% was a bug for the release of Redstone.
With our next Houston upgrade we intend to introduce a new RPIP quite soon for onchain pDAO voting (hooray) to follow the min 10%, max 150% effective stake as it does now and has always intended so since RP launched. This will require a formal pDAO governance vote to pass as @Wander has said.
Despite the wording, these are opinions not facts.
That is not my reading of the RPIP as best as I can read it. Fwiw, there are exactly 3 uses of effective or effectively in the RPIP:
2 uses in implementation section:
To be eligible for vote participation, the RPL must be effectively staked in the Rocket Pool protocol as reported by getNodeEffectiveRPLStake() .
I read this as explicitly specifying that getNodeEffectiveRPLStake() is the source of truth.
1 use in rationale section:
RPL is required to be effectively staked for voting to prevent vote-buying by participants unaffiliated with the protocol’s operations.
The rationale section isn’t a spec. Further, 0-150% and 10-150% achieve this goal just as effectively since you need 10% to enter.
Fwiw, since we’re throwing around “I was there so my opinion has weight” (which I again assert should not be part of governance at all), the commit comment where all 3 of those uses were added is Include Valdorff feedback. I am not seeing a realistic resolution other than voting both ways at this point.
With the initial mainnet launch, getEffectiveRPLStake returned any RPL staked value under 150%. RocketClaimNode.getClaimPossible prevented you from claiming if you were below 10%. you were able to top up your RPL stake and call claim as long as you were over 10%. this was because we weren’t snapshotting stake, things were calculated at the block the transaction happened instead.
With the initial mainnet launch, getEffectiveRPLStake returned any RPL staked value under 150%. RocketClaimNode.getClaimPossible prevented you from claiming if you were below 10%. you were able to top up your RPL stake and call claim as long as you were over 10%. this was because we weren’t snapshotting stake, things were calculated at the block the transaction happened instead.
In Redstone, we introduced the merkle tree distribution of rewards to fix a lot of the issues associated with the above design. getEffectiveRPLStake was not updated to exclude under 10%. initial implementations of the merkle tree reward generator assumed it did and incorrectly assigned rewards to people below 10%. this almost happened on mainnet but the team sent the 3 people below 10% a small amount of RPL to push them over so that when we fixed the spec, we didn’t have to include an exclusion for interval 1.
The merkle tree reward generator was updated to exclude anyone below 10% as it should have been but the contracts still report the incorrect value.
In Atlas, the contracts were updated to correctly exclude anyone below 10%.
There’s no need to get personal mate, I was just stating the way it was at launch. I helped write the original code for it (bug was probably my fault).
As one of the NOs who tries to keep collateral close to the minimum and who just happened to be below 10% due to market conditions at the time of the latest snapshot, I feel a bit confused by this development.
I started with opinion that 0-150% should be able to vote, although admittedly this wasn’t a topic I had given much thought to during my normal operation as a NO. However, the more I read the clearer it becomes that the intent was indeed to use the 10-150% range for voting power calculation, i.e. the effective stake. And being able to vote below 10% was a bug. As such, I can accept that logic being fixed/changed without a vote, although I would still like the RPIP wording to be more clear and not reference the SC function.
I still fail to fully understand the rationale behind that original intent though.
My understanding is that the primary goal is to grant governance power to NOs (as opposed to all token holders). And I’m struggling to see how my current inability to vote aligns with the protocol’s goals. Unless there are factors at play that I am not fully aware of, such as concerns about potential attack vectors or aforementioned RPL utility. The vote-buying prevention rationale is not totally clear to me either (e.g. how barring 0-10% from voting helps with that).
As such, I would greatly appreciate some additional clarification on why the 0-10% range should not be allowed to participate in governance. Especially if this goes to a vote, with community sentiment seemingly leaning towards 0-150%, as I would want to make an informed decision on this.
Here’s an additional point I’d like to make. As opposed to RPL rewards snapshots which are predictable, the governance snapshots are not - and NOs cannot retroactively top up to participate.
Therefore, for NOs who try to minimize RPL collateral/exposure and keep it at minimum 10% but still participate in governance, it essentially boils down to luck if they will be above or below the threshold at the snapshot block and be able vote. To maximize their chances it would require topping up as soon as the ratio goes below or even near 10% - which is not always realistically possible - and even then is not a guarantee (e.g. due to flash crashes, prohibitive gas costs, physically not being available to top up etc etc).
Ok, that matches my understanding. So at the time when RPIP-4 was passed, below 10% was allowed for voting purposes. So I believe this should have been raised with the pDAO before making changes.
It’s the same as with rewards eligibility, I guess. Why is the protocol stronger with 10% threshold? Because RPL is a part of the protocol and this threshold aligns RPL holders with its growth. This is important especially given the recent motion to Allow minipool deposits while under “min” RPL. Some folks might stop caring about the protocol as a whole (specifically its RPL part and its future) at some point and still suck profit out of it. Not going to say that this RPL minority can accumulate into a big voting power, but if all other pDAO is divided one day on some topic, this force can play a significant role.
I agree that it’s inconvenient that voting snapshot is made ad-hoc, so voting power is more prone to market volatility than it is with rewards. I like your suggestion to meld vote and rewards snapshots.
As for RPIP-4 contradiction, I think that since pDAO voted to depend on smart contract function, that is controlled by oDAO solely, than it’s NOT necessary to have a special vote (regarding voting power below 10%), which have to include all excluded by Atlas upgrade. I agree, however, that this is wrong for pDAO to depend on oDAO and hence the wording in RPIP must be fixed.
Just going to simply state my understanding as a NO, that effective stake of 10-150% has always been the boundaries for rewards and governance. I would classify myself as a typical low level NO.
This thread is getting a bit off-topic. We’re not debating whether people under 10% should be able to vote. We’re trying to establish what RPIP-4 says about the matter.
It’s pretty obvious to me that we’re not going to come to consensus here and we will have to cure RPIP-4 in a pDAO vote. My suggestion above would let us do that without deciding the question of RPIP-4, and I believe it is now the best course of action, as sentiment on the interpretations of RPIP-4 is clearly divided.
This may be pedantic, but this topic thread is quite literally about “debating whether people under 10% should be able to vote”. I agree with langers/darcius that as the author of said topic, I have some idea about the original intent. It went off the rails to argue things we apparently can’t possibly know or agree on; however the substantiative argument remains: “going forward, should NOs under 10% vote?”; and I appreciate umeku and neveranisland’s substantive contributions. If people feel this thread has become too uncomfortable, we can start a new one with a clean slate.
