Rocket Pool MEV Theft & Neglected Revenue Report (Slots 5.2M–10.0M)
A follow-up to the initial analysis by @ramana and @Valdorff (2023 - Bounty BA032304 - Report Here ← ), expanded with broader data and stronger theft detection logic
Read the Full Report with methodology, analysis & tables:
96 confirmed MEV theft cases — up from 17 in ramana and Valdorff’s report.
8.48 ETH stolen, up from 2.11 ETH previously.
Theft is increasingly concentrated: 5 node operators account for >75% of all cases.
Definition of theft: if none of four data sources (relays, beaconcha.in, mevmonitor, block’s last TX recipient) show the expected fee recipient, we flag it as theft.
Neglected MEV via Vanilla Blocks:
7,450 vanilla blocks proposed by RP validators.
749.34 ETH in missed revenue.
380.45 ETH from SP validators
368.89 ETH from non-SP validators
Additional 2,546.37 ETH lost from blocks accepting lower-than-available MEV bids.
How We Define Theft
For SP Opt-In Nodes:
in_smoothing_pool == True AND
sp_address NOT in (relay_fee_recipient, mevmonitor_fee_recipient, beaconcha_fee_recipient, last_tx_recipient)
For Regular (Non-SP) Nodes:
in_smoothing_pool == False AND
distributor_address NOT in (relay_fee_recipient, mevmonitor_fee_recipient, beaconcha_fee_recipient, last_tx_recipient)
If none of these 4 sources point to the expected address, we consider the MEV fee diverted and flag it as theft.
Takeaways & Recommendations
Theft, while small in ETH value, is present and increasingly systematic.
RP misses out on hundreds of ETH annually due to:
Vanilla block production (no MEV boost)
Accepted bids being lower than available max bids
The community / protocol could consider:
Moving to MEV Phase 3 (“Required”) to curb losses
Periodic reporting (e.g., bi-annually)
Long-term ideas to align validator behavior via incentives or tooling
Can you clarify this? If it’s “there was another relay with a better option”, then that can be real. If it’s there was a higher bid – it probably came in too late – the validator does need to sign off on a bid at some point with enough buffer time etc (and we look like solos not like pros optimizing timing games here).
This is interesting. It’s probably worth it to try to communicate (nontrivial). It’s a can of worms, but we could also get into a discussion around penalizing for continuous misbehavior. If we had the ability to exit validators, that would certainly be called for in my opinion, but that’s an easier bar.
On MEV Submission Delay:
Thanks for the question. The topic of bid submission timing is a good one. In this report, we didn’t look at when the bids actually arrived, so we didn’t filter out any late bids. That means the 2,546.37 ETH we mark as “lost” could include some bids that were realistically never going to make it into the block due to timing.
So yes, some of this might not be actual neglect, but just the result of relays sending bids too late. We’d need to define what counts as a fair delay (i.e. what’s still acceptable for a typical RP node to include the bid), and then filter based on that. I haven’t looked into where we this kind of data could be obtained yet, but it might be possible (maybe from something like The Lab by ethPandaOps). If anyone knows how we could approach this (@ramana, Val, or others) I’d be curious to hear your thoughts.
On the Top Offenders Topic:
Yeah, I agree with you. The top 5 repeat offenders (with more than 3 confirmed thefts each) are behind over 75% of all high-confidence theft cases. That’s a pretty clear pattern, and I think the protocol should should acknowledge it at least by trying to communicate with the top offenders.
I’m not saying we should go straight to penalties, but we should do something in order to signal to the community (and rETH/RPL) holders that this is being actively looked at. The loss in ETH due to high-confidence theft so far is still small, but it’s gone up since the last report (especially in more recent slots i.e. > slot number 8M), and we shouldn’t wait for a situation where a 60 ETH mega-block gets lost to actively address it (even if such an outcome is 0.0…01% probable).
[quote=“ArtDemocrat, post:3, topic:3614”]If anyone knows how we could approach this (@ramana, Val, or others) I’d be curious to hear your thoughts.
[/quote]
I think we empirically looked at the value for this once upon a time? It was like “for a user that had relay X on and accepted from that relay, what is the ratio between highest bid and accepted bid?” That sidesteps the exact timing and provides a usable correction factor. See bid2reward in GitHub - xrchz/rockettheft: Rocket Pool MEV theft analysis
Rocket Pool MEV Theft & Neglected Revenue Report (Slots 5.2M–10.0M)
Read the Full Report with methodology, analysis & tables:
GitHub Report Link
In a nutshell
MEV Theft Findings:
Neglected MEV via Vanilla Blocks:
How We Define Theft
Takeaways & Recommendations