The core of it is a “Guiding Principles” section, copied below, with the rest of the document attempting to make that somewhat more concrete, while not getting to fully concrete due to likely unknown unknowns.
Guiding Principles
Rocket Pool will act in the best interest of Ethereum health
Rocket Pool will consider the impacts of its choices on Ethereum, both immediately and long term
Rocket Pool will prefer to damage itself before endangering the stability of Ethereum
Rocket Pool will willingly limit its dominance within staked Ethereum
Rocket Pool will give its NOs autonomy to make meaningful choices and to leave the RP system if they find it unsatisfactory (eg, we currently allow exiting without pre-conditions, and minipool upgrades are opt-in)
I’d love to get some more feedback from the community before opening up a poll to see if it’s got a shot in a snapshot vote and should move forward. Fire away
One related item that was brought up was whether this fits in the RPIP flow at all. I think there are 3 possible paths here. (1) We could say "this fits under the existing “Meta RPIP” category, which calls out “guidelines” as an example. (2) We could say it doesn’t fit Meta, and more explicitly add a category for this kind of definitively non-technical item where consensus from the voters is desired; this would be something like “Additional/modified text” below. (3) We could say it doesn’t fit RPIP at all, and come up with a separate system that also feeds into snapshot for this genre of vote.
(1) This should go under “Meta RPIP”
(2) This should go through the RPIP flow, but we should modify the categories to better allow for this genre
(3) This genre should use a non-RPIP flow
0voters
Existing text
A Protocol RPIP describes any change that affects the core Rocket Pool protocol as is currently defined via the smart contract implementations. Protocol RPIPs consist of a design specification and an implementation. Furthermore, Protocol RPIPs can be broken down into the following categories:
Core: improvements relevant to core protocol design.
RPRC: application-level standards and conventions, including non-core contract standards such as RPRC-3.
A Meta RPIP describes a process surrounding Rocket Pool or proposes a change to (or an event in) a process. They may propose an implementation, but not to Rocket Pool’s codebase. Examples include procedures, guidelines, changes to the decision-making process (i.e. governance).
An Informational RPIP describes a Rocket Pool design issue, or provides general guidelines or information to the Rocket Pool community, but does not propose a new feature.
Additional/modified text
A Consensus RPIP describes a position held by community consensus that has neither a direct implementation in the codebase, nor a direct implementation in process. This would include, for example, DAO values or principles.
An Informational RPIP describes a Rocket Pool design issue, or provides general guidelines or information to the Rocket Pool community, but does not propose a new feature. Informational RPIPs do not necessarily represent community consensus or a recommendation.
Ok… so this has been up a couple days and not gotten discussion here. I’m going to go ahead and put up a poll to see if we have enough positive sentiment to move forward.
Yes - let’s vote for these principles
No - I’m against these principles
There’s something I don’t like in the current RPIP; I’ll comment below
There’s something I don’t understand in the current RPIP; I’ll comment below
0voters
Clarification (polls can’t be edited): the “Yes” should be “let’s vote for the principles per this RPIP” - so the whole RPIP, not just the “Guiding Principles” section.
Just a quick thought, about self limiting, I think it needs to be detailed a bit more.
The current argument for it is that Rocket Pool could become a major risk for ethereum and hurts its decentralization.
I think the question has to be seen who are we giving the share to. A handful of centralized ctasking providers? I’d argue RocketPool could be better there, although the ODAO may need to be changed a bit.
edit: I’m dumb and skipped the header lines containing lot of details about what I’m talking about
i agree with everything listed and would like to stress that we should take a nuanced approach and make the total staking landscape one of the most important factors when considering if and at what point to self limit.
Rocket Pool will willingly limit its dominance within staked Ethereum
I think Rocketpool marketshare can not be judged in a vacuum but instead by considering the total staking landscape.
For example, self limiting at 20% market share to me would have completely different implications depending on wether the market has a diverse field of established decentralized liquid staking alternatives or wether it is still dominated by centralized actors like Lido and exchanges where any marketshare we pull to us might still be a significant net positive for Ethereum even above 20%
thats why i think the self limiting goal should be formulated more nuanced than plainly stating a target % marketshare or even just proclaiming a goal to self limit.
Something like “self limit in a way that strives for optimization of Ethereums decentralization”
I don’t have any deep thoughts on this topic except to say that (a) the market share at which we are mooting self-limiting is so high that economically we’ll all be thrilled if we get anywhere near it and (b) the argument about not self-limiting because we’d be yielding stake to even more centralized entities is the one Lido used to justify not self-limiting.
This issue is tricky to figure out because we have to not only be aware the decentralization of Ethereum’s overall staking landscape, and how our share of that fits in, we have to also be aware of our own internal decentralization metrics. If we end up dominated by 2-3 SaaS vendors that might also be hosting validators for other staking protocols, or if the ODAO ends up with more power to shape operator behaviors then now, a lower target threshold should be considered. Perhaps a way to phrase this as a principle is that “Rocketpool’s growth should be improving the decentralization of Ethereum, and should limit itself if it detracts from it.”
There is a minor issue with the RPIP where the link about “Rocket Pool core team agrees with the importance of limiting, but says the decision lies with the community” is pointing to a comment by StakeWise. I think we should update that link.
Talked a little with a couple folks that have convinced me there should be a little more meat around cross-protocol-spanning entities, how we judge a protocol as “good”, explicitly noting we’re not automatically good and should apply the same process to ourselves that we apply to other protocols.
I’ll take a stab at adding that and some of the thoughts above later today, while not messing with the big picture since it seems folks generally like it.
Above all, I like the overall direction of these principles and think it’s a solid signal of intent, that can readily be voted on.
As for the self-limiting examples, I like the hard-cap and soft-cap with redirection of funds. Not quite sold on the ‘funding/creating our own competitor’ angle. I’m not sure how effective a use of funds this would be, how independent such a competitor would be in practice, and if it’s even Rocket Pool’s place as a protocol to undertake this.
I recognize all these are just example methods of self-limiting and we should really fill in the blanks as we have more insight in the situation as it develops. But we should be wary that people don’t start perceiving these as promises set in stone (expectations management.)
I know these are just principles - and I’m not trying to be super clever here - but there is no mention of timeframe.
Just one edge case - RP is #4 in the top 4; Lido has a blackswan event and out… like “out out”… basically we went from a 30/25/23/22 world to 35/32/31 world. Rebalancing and new market participants will come, but not overnight.
Anyhow just a thought - some timeframe dimension could be useful.
But I agree with the principles.
edit - I guess I’m trying to express that RP growth as a share of the total validators is expected to occur by growth of RP minipools, but it can also occur via attrition/exit of other market participants.
This is an interesting thought, and a case I hadn’t considered…
I think the plain reading is that we should go pretty hard to limit at that point (thus as soon as we can). Everything is a SHOULD, so that feels OK in terms of balancing clear intent and practical reality.
Do you have a suggestion? Maybe a bullet under the “further consideration” section?
Any flexible wording I try to use like “reasonable timeframe” seems like a backpedal on all the principles - which I do not want to compromise. So again, these being principles and not hard coded anywhere perhaps timeframe can be forgone.
This is an interesting thought, and a case I hadn’t considered…