Draft Outline for a pDAO proposal on Rules of SP and MEV-Boost

Right, MEV-boost should not be mandatory for people outside the smoothing pool. These constraints are not worth the minimal effect on the rETH price, because most people will activate MEV for more returns anyway.

1 Like

FYSA: Not enabling MEV-boost will have a -11% reduction in maximum APR if no one was in the smoothing pool. Assuming a 50% SP participation rate, it would be a -6% reduction in rate. We would be lagging Lido stETH return by -11%. At current validator numbers, that would be

stETH estimate 7.6%
rETH estimate 6.7%

FYSA. IMO this is a noticeable lower rate of return for investors. Also with out requiring MEV boost non-SP (solitarus) minipools can still MEV for themselves so the protocol has to require the use of a MEV-boost relay. I can be a neutral fair order system if we don’t want to be competitive.


So to be competitive means to be more centralized in regards of block production. Which is certainly against the ethereum ethos. But without competitiveness rocketpool will not grow. Sad.

1 Like

The counter is that if you do not run MEV-boost there are only 5 entities ordering your block transactions. The devs of Prysm, Nimbus, LH, Teku and Lodestar. With MEV-boost there are more block builders and each of them writes unique code that will order the transactions. So, from one point of view, running MEV-boost decentralizes the network more than building your own block.

1 Like

According to the numbers on rocketscan, which may not be up to date, there are still 1591 pools in the smoothing pool that haven’t enabled mev boost. Also Thomas hasn’t yet but has indicated he intends to. That would take us to 85% enabled. I think most will enable it once it is more proven and the credibility benefits for not requiring it will outweigh the small loss in percentage.

This is not a fair comparison. The transaction ordering by your own node is deterministic and open source and we can modify the code to control it if necessary. The MEV boost relays are out of our control and also not open and therefore subject to more risk in terms of network delay/not spreading the block causing a missed block proposal/censorship/possible slashing since the relay is trusted. Obviously some of these will negatively affect the reputation of a relay, so “bad” relays can be blacklisted.

bloXroute already suffered some downtime and caused missed block proposals, 100 blocks or so, since there was a bug spreading the blocks

Read this directly from bloXroute: https://twitter.com/bloXrouteLabs/status/1572620088175661056

Most nodes will enable mev-boost, way more than 50%. Let’s not make it mandatory. If we make it mandatory, that is mandatory centralization. And when we have mandatory centralization there is less of a reason to encourage people to choose Rocket Pool over lido. In addition to encouraging new users, we need to uphold our promises to decentralization to our current users, both node operators and rETH holders.


As discussed in discord, https://medium.com/rocket-pool/the-merge-0x02-mev-and-the-future-of-the-protocol-c7451337ec40 set the expectation that MEV would be an option. I’m comfortable requiring it for the smoothing pool now. I’m comfortable requiring it for everyone once withdrawals exist (so people that took the medium post to heart aren’t punished).

If we wait for withdrawals, it gives us a ton of time to judge if the effects are worth a rule for everyone or not.


Regarding section 1 of the document:

All RP Solitarius nodes SHALL enable at least one of the MEV-boost relays included in the latest smart node release or one included in a smart node releases less than one month old at the time of their block proposal.

This makes it sound like the smartnode implementation is defining the specification of what an acceptable relay is. Assuming we require MEV relays, could we update this section to something like “All RP Solitarius nodes SHALL enable at least one of the Rocket Pool-approved relays.”?

I am a non-technical NO so I don’t know all the ins and outs but do agree with this principle. I would be very hesitant to stray from core values by trading them for higher yield in order to maintain market share. In the long run, the values will count more especially when technological innovations may quickly change the tactical playing field making current decisions moot.


A wording like that begs the question “Who is Rocket Pool?” I would argue that the pDAO is the governing body of Rocket Pool, but some others might interpret Rocket Pool to be the group of individuals that owns rocketpool.net and has their names on it.

It’s clear that the authors want the smartnode developers to maintain control over the relay list, if this proposal were to actually pass. I think the original wording was intentional.

Agreed - I think the wording was intentional and, imo, sensible.

The smartnode devs can move faster than an rpip+vote to add relays and they have shown willingness to add relays as they become available.

If at some point we don’t believe the smartnode devs are doing an adequate job, we can rpip+vote in a different process, but I prefer to avoid large cycles unless they’re strictly needed.

I do think that having an implementation (smartnode source code) define a specification for a protocol is odd, contradicts section 8, and doesn’t match the language of section 4.

My suggestion was to not have how a relay is chosen specified in slightly different ways throughout the document, but to instead refer to section 8 which is dedicated to defining what are acceptable relays. In that section 8 the language used was “Rocket Pool-approved relays”.