---
tags: mev, research, ethereum
---
# Lido and MEV on Ethereum Discussion Document - DRAFT
```
STATUS: Open for comment
```
## ToC
* [Introduction](#Introduction)
* [Should Lido Node Operators extract MEV](#Should-Lido-Node-Operators-extract-MEV)
* [If so, how should Lido Node Operators extract MEV?](#Should-Lido-Node-Operators-extract-MEV)
* [What might a possible solution look like?](#What-might-a-possible-solution-look-like)
* [Next steps](https://hackmd.io/oxiIc_rMRuOMUjFFpAGnbQ?both#Next-steps)
## Introduction
Following the adoption of the Lido Operator Set Strategy, and specifically the Strategy for Ethereum, Lido also needs to adopt a clear and public strategy with regards to MEV extraction on Ethereum. From a rewards perspective, Lido has already [outlined a plan and technical approach](https://research.lido.fi/t/lip-12-on-chain-part-of-the-rewards-distribution-after-the-merge/1625) on how both priority fees as well as possible MEV rewards can be (re)-distributed between stakers, node operators, and the protocol. What remains to be clarified is if and how Lido Node Operators (NOs) will participate in MEV extraction.
## Should Lido Node Operators extract MEV?
Given market dynamics, the widespread adoption of MEV extraction in PoW Ethereum, the close alignment between the Ethereum Foundation and teams like Flashbots, and clear plans for Proposer Builder Separation in [the Ethereum Endgame](https://vitalik.ca/general/2021/12/06/endgame.html), it would be hard to argue that Lido Node Operators should not extract MEV and share rewards with Lido stakers. Concisely:
- Stakers will generally go to the staking provider with best returns, and if Lido does not extract MEV rewards and share it with stakers, some other staking provider will;
- Efforts should be made to minimize MEV at the application layer, and even at the base layer when possible, but the reality is that some MEV will always be available and thus a market for it will emerge;
- By enforcing an open and democratic approach to MEV, Lido stands to be able to “set the tone” in terms of discouraging deleterious MEV (e.g. reorg-based MEV), and paving the way for in-protocol PBS by adopting the prevailing form of PBS-lite in the meantime.
## If so, how should Lido Node Operators extract MEV?
MEV extracted by Lido Node Operators should be done as openly, transparently, and democratically as possible. Exploring the solution space around this is why Lido joined the [Flashbots ETH2 Working Group](https://research.lido.fi/t/join-the-flashbots-eth2-working-group/1451). Given the potential share of total stake that could be running through Lido NOs, it would not make sense for Lido to use an MEV extraction and rewards mechanism that is opaque and not open to the rest of the ecosystem.
Therefore, the optimal possible solution would be:
- Utilizing middleware/infrastructure that is open source, useable by any interested party, and transparently operated by Node Operators who run nodes & validators for Lido.
- Outsourcing block building to the maximum extent possible. This means that Lido validators should only include blocks that come from public/open block builder markets, and not engage in building blocks "in-house" (referring to both Lido and/or Node Operators).
## What might a possible solution look like?
The most likely solution until PBS comes to fruition looks something like the below:
- Lido DAO and Lido Node Operators formulate an agreed-upon policy regarding the possible extraction of MEV and sharing of MEV rewards with Lido stakers;
- We imagine the policy could take various forms and also evolve over time, with some examples being:
- All NOs agree to participate in MEV using the same manner and usage of this infrastructure becomes obligatory for all NOs (present and future, with a possible escape hatch for those who do not wish to participate),
- NOs agree to participate in MEV extraction, and others may abstain (apart from the MEV inherent to public mempool tx-ordering by priority fee),
- NOs generally agree to participate in MEV, but some percentage of validators could be used to test MEV-minimizing block proposal approaches (e.g. [shutterized beacon blocks](https://ethresear.ch/t/shutterized-beacon-chain/12249/18))
- This manner would adopt the most robust and open solution available on the market at the time (e.g. currently the solution with most product-fit and general acceptance is Flashbots’ MEV-boost, but solutions should be periodically re-evaluated);
- Lido NOs would run MEV-boost as a part of the infrastructure that they run for Lido (along with Execution Layer nodes, Consensus Layer Nodes, Validator Clients);
- Lido NOs would use a public set of possible relays to ensure inclusivity of prospective block builders, to be maintained by the Lido DAO (possibly in coordination with other staking solutions);
- Blocks would only be accepted from the open block market via the chosen infrastructure (e.g. MEV-boost) or from the normal block-building process via the public mempool (fallback mode in case MEV-boost is not functioning properly), blocks should not be built in-house by Lido or by Lido Node Operators (NOs are free to build their own blocks for blocks proposed by other validators that they run, but not for Lido validators);
- Node Operators who fail to uphold the policy would be subject to having stake de-allocated from them (post-withdrawals), their validators exited ([post triggerable exists via 0x03](https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021/19) or [something similar](https://ethresear.ch/t/withdrawal-credentials-exits-based-on-a-generalized-message-bus/12516)), and potentially become de-registered from operator registries across “Lido on X” protocols.
## Next steps
The DAO should deliberate on the above and any additional considerations and establish a policy on MEV extraction and rewards distribution on Ethereum.
I propose the following:
* The policy should be ratified by the DAO prior to the Merge.
* The policy should include, at a minimum:
* The goals and scope of the policy;
* Whether blocks should be built by Node Operators (NOs) in the ideal flow, and in which cases deviation from this may be acceptable;
* The infrastructure that Lido NOs can utilize in furtherance of execution of the policy;
* The repercussions for NOs not adhering to the policy;
* How often the policy should be reviewed & re-evaluated by the DAO.
* Infrastructure identified in the policy should be appropriately tested to the satisfaction of Lido and its Node Operators before being put to use on Ethereum mainnet; in case this has not been achieved before the Merge then implementation of MEV rewards gathering and distribution should be delayed until the solution is performing satisfactorily.
* The policy should be periodically reviewed (e.g. every 12 months at a minimum) in order to assess whether its implementation is accomplishing its stated purpose and to re-evaluate tools and infrastructure that could be utilized.
#### Proposed Deadlines
*This set of deadlines assumes that the Merge could occur in late August at the earliest (we think that this is highly optimistic and not very likely, but can plan against it).*
|Topic|Date|
|-|-|
|Discussion| Week of Jun 20 - Week of July 18th|
|Policy is drafted posted on forums for final comment| Week of July 25th |
|Policy is ratified by DAO vote (Snapshot) | Week of Aug 4th |
|Implementation is fully tested on testnets & status is reported to the DAO | By late August |
###### tags: `Node Operators` `MEV` `Strategy` `Policy`
Sign in with Wallet
Connect another wallet