Rocket Pool MEV Theft and Loss Report - Grant Application
General Information
Continuing the MEV Theft Reporting bounty published by @Valdorff and @ramana in July 2023, @ramana and @ArtDemocrat submit this grant request to fund an updated research paper on this matter, aiming to:
- Extend the analysis to July 2024
- Report on the state of protocol revenue loss coming from (a) MEV theft and (b) neglected revenue due to vanilla block building (see red arrows below)
- Evaluate the need for creating tools and mechanisms to analyse protocol revenue loss on an ongoing basis, since MEV loss currently represents a topic within the Rocket Pool protocol which is not actively monitored or audited
What is the work being proposed?
Rocket Pool currently lacks visibility on
- Whether MEV Theft is happening, how often, and at what magnitude, and,
- How big are the MEV opportunity costs from validators running without registered MEV relays (i.e. producing vanilla blocks).
We aim to bring transparency to this topic by focusing on the following routes of MEV Loss within the Rocket Pool protocol:
During the first phase of the research conducted by @ramana and @ArtDemocrat on this topic in March 2024 we were able to generate the findings listed below. (see Initial Report)
However, we realized quickly that we needed a more detailed investigation of MEV fee recipients and value by cross-referencing additional data sources and methods. For example, some of the findings presented below are contradictory between the sources of information we looked at in our March 2024 research. Therefore, upon the funding of this grant application we aim to expand our methodology to include raw data from each block’s slot, data obtained directly from relays, beaconcha.in data, and NonFungibleYokem’s mevmonitor database.
Regarding the insights of the initial report, we found that up until slot 8,499,999 (2024-02-25 01:20:11 UTC):
Rocket Pool has faced 51 cases of MEV Theft (i.e. incorrect fee recipient) since the grace period ended after the Redstone release (39 opted-in smoothing pool, 12 opted-out). While this represents an incidence rate of 0.06% across all blocks proposed since the grace period ended, this seems to become more prevalent in recent slots (+34 more cases vs. the 17 cases identified in the aforementioned initial MEV Theft report). The ETH loss due to these MEV Theft cases stands at 6.29 ETH (+4.28 ETH more vs the 2.11 ETH identified @valdorff and @ramana’s initial MEV Theft report). (see Report Section: “MEV Theft”)
-
If we also consider slots where no
mev_rewardwas registered for a proposed block, we see a total of 883 cases where an incorrect fee recipient was used by RP validators, raising the theft incidence within RP to 1.02% (see Report Section: “MEV Theft”). The loss from these cases is covered in point 4. below. -
Rocket Pool has faced seven repeat offenders (i.e. node addresses that have used an incorrect fee recipient), of which one gathered MEV 19 times outside of the protocol-defined fee recipients. The largest loss after the grace period ended was of 1.66 ETH (slot: 6376024, fee recepient: btoast777.eth). However, the MEV was manually returned to the smoothing pool by the node operator in this specific case (see Report Section: “MEV Theft”). -
Rocket Pool validators have proposed 6,651 vanilla blocks in the timeframe analyzed (3.3k SP operators and 3.3k non-opted-in operators, which are +2,676 cases more vs the 3,975 identified by the initial report). This led to a revenue loss of 620.4 ETH (+452.4 ETH more vs the 168 ETH loss identified by the initial report). For this reason, subject to this fact being confirmed by the research to be funded by this grant, we would recommend the Rocket Pool protocol to move to MEV capture Phase 3 “Required” as soon as possible, to minimize losses coming from vanilla block building (see Report Section: “Neglected Revenue”).
Will the results of this project be entirely open source?
The results of this project will be entirely open source, licensed under the MIT License.
Benefit
| Group | Benefits |
|---|---|
| Potential rETH holders | rETH’s APR can be proactively protected by shedding light on this matter and acting on time. A competitive rETH EPR is tablestakes to drive demand towards rETH. |
| rETH holders | see above |
| Potential NOs | Higher staking APR by enforcing MEV relayer usage (either individually, or for the entire smoothing pool NO cohort. |
| NOs | N/A |
| Community | Sensitize the Rocket Pool community to the relevance of honest acting (as we observe and report misbehaviour), and to the maximization of MEV rewards for the sake of protocol competitiveness. |
| RPL holders | see points above → demand to mint/create rETH and Rocket Pool validators → direct buying pressure (to spin-up validators) and indirect RPL buying pressure (secondary market premium = incentives to spin-up validators) |
Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from the product of this grant being successfully completed?
Anyone who is looking to research MEV capture and distribution within a protocol can leverage the scripts and tools created for this research.
Work
What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Steps:
-
Expansion of current data-collection scripts in order to cover draw data from each block’s slot, data obtained directly from relays, beaconcha.in data, and NonFungibleYokem’s own database. (PIC: @ramana)
-
Data analysis, MEV theft and loss logic definition, and report production (PIC: @ArtDemocrat)
We aim to complete this report by mid-September.
What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
An initial version of the scripts and tools required to produce the final product exists. Those were used to produce the first version of the MEV Theft and Loss Report by @valdorff and @ramana, as well as the update done by @ramana and @ArtDemocrat earlier this year. As per the objective of this grant application, we now aim to expand and refine these in order to ensure the findings presented are tested across several sources of information. @ramana and @ArtDemocrat have the skills to execute this task, as demonstrated in the March 2024 report produced.
How is the work being tested? Is testing included in the schedule?
The sole purpose of this grant is to expand the data sources used for the initial MEV Theft and Loss report produced by @ramana and @ArtDemocrat, in order to be able to test sources against each other and create a logic which objectively allows us to define MEV theft and loss. Testing would be therefore part of the research itself.
How will the work be maintained after delivery?
All work will be documented on GitHub and linked (if desired / useful) to the Rocket Pool Guides, so that anybody can leverage the data mining and data analysis infrastructure created for this grant.
Costs
The total amount of hours invested in the initial research by @ramana and @ArtDemocrat are estimated at approximately 100 hours (incl. both, @ramana and @ArtDemocrat). No specific tools or software were used which have a direct cost attached to them.
Assuming a similar amount of work for this second iteration, we look for a retroactive grant of $15,000 paid out in RPL. As reference, the compensation awarded to the initial report created by @valdorff and @ramana scoped $15,000-20,000 for the core deliverable. Therefore we come to such compensation request based on 1) how critical this work is for the protocol but 2) the fact that the initial data mining infrastructure from @valdorff and @ramana’s report research could be partially leveraged for the goal of this grant application.
We seek a single pay-out for this retroactive grant, split 60% for @ArtDemocrat and 40% for @ramana.
How will the GMC verify that the work delivered matches the proposed cadence?
The first report created by @ramana and @ArtDemocrat serves as the blueprint of what the final product of this grant would be. It servers, therefore, as a reference on whether the work deliverables match this grant’s application scope.
What alternatives or options have been considered in order to save costs for the proposed project?
To put this cost into perspective, please consider that initial report (numbers TBC by the final product of this grant application) surfaced a loss of 626.69 ETH (6.29 ETH from direct theft + 620.40 ETH from vanilla block building). This represents 456.68 ETH more in losses vs the initial MEV Theft Reporting bounty of @Valdorff and @ramana.
If the community, GMC, and pDAO see value in establishing the proposed ongoing reporting mechanism for MEV Loss tracking, we would have one more “heavy-lift” grant ahead of us to create the regular reporting tools which can then be maintained whenever necessary in a less cost-intensive way.
Conflicts of Interest
Does the person or persons proposing the grant have any conflicts of interest to disclose? (Please disclose here if you are a member of the GMC or if any member of the GMC would benefit directly financially from the grant).
Both, @ramana and @ArtDemocrat benefit directly from this retroactive grant request.
Will the recipient of the grant, or any protocol or project in which the recipient has a vested interest (other than Rocket Pool), benefit financially if the grant is successful?
Not based on our current knowledge.
Data Structure and Sources
For reference, the data structure and sources which would be used to create the report for which we are requesting this grant are as follows.
Note this is our current working draft and may be subject to small changes.
Current data columns:
slot,max_bid,max_bid_relay,mev_reward,mev_reward_relay,proposer_index,is_rocketpool,node_address,in_smoothing_pool,correct_fee_recipient,priority_fees,avg_fee,eth_collat_ratio
Desired data columns:
# Basic slot and block info
slot, # slot number
proposer_index, # proposer index [this and the rest empty for missed blocks]
raw_fee_recipient, # fee recipient specified for the block
last_tx_recipient, # target of the last transaction in the block
last_tx_value, # amount of ETH sent in the last transaction in the block
priority_fees, # total ETH paid as transaction fees above the base fee in the block [only included when is_rocketpool and no max_bid]
# Basic RP info
is_rocketpool, # whether the proposer was a Rocket Pool validator
node_address, # Rocket Pool node that owns the proposer's validator [this and the rest empty for non-RP]
distributor_address, # Rocket Pool node fee distributor address for the node
in_smoothing_pool, # Whether the Rocket Pool node was in the smoothing pool (at this block)
avg_fee, # Rocket Pool average fee for the node (at this block)
eth_collat_ratio, # Rocket Pool ETH collateralisation ratio for the node (at this block)
# Info we queried directly from the RP relays
max_bid, # top bid received by RP relays for this slot [this and the rest empty if no bids]
max_bid_relay, # relays that received the top bid [;-separated]
mev_reward, # MEV reward claimed delivered by any RP relay [this and the rest empty if none claimed delivered]
mev_reward_relay, # RP relays that claim to have delivered the MEV reward [;-separated]
relay_fee_recipient, # Fee recipient according to the RP relay
# Info we get about relays from Butta
beaconcha_mev_reward, # MEV reward claimed delivered by Beaconcha [this and the rest empty if none]
beaconcha_mev_reward_relay, # Relays claimed delivered by Beaconcha [;-separated]
beaconcha_fee_recipient, # MEV fee recipient according to Beaconcha
# Info we get about relays from Yokem
mevmonitor_max_bid, # top bid received by any relays for this slot [this and the rest empty if no bids]
mevmonitor_max_bid_relay, # relays that received the top bid [;-separated]
mevmonitor_mev_reward, # MEV reward claimed delivered by any relay according to MevMonitor [this and the rest empty if none]
mevmonitor_mev_reward_relay, # Relays claiming to deliver according to MevMonitor [;-separated]
mevmonitor_fee_recipient # Fee recipient addresses for deliveries above according to MevMonitor [;-separated]