Extracting MEV in early stage Ethereum PoS - Stakers’ options
September 28th, 2022

With just few weeks into the Ethereum’s Proof-of-Stake era, liquid transaction fees and MEV rewards on the table, stakers are confronted with a more enriched but also more complex reward scheme for serving the network.

Most recent discussions have revealed a non-trivial decision tree of trade-offs between validator reward maximisation, censorship resistance, and network security (specifically: a decentralised validator set).

“I'm hesitant about MEV and staying away from it.”

- Superphiz

Since the merge, Ethereum effectively makes use of non-native proposer-builder-separation (PBS), leveraging an external builder network in order to mitigate more severe harm to the chain because of MEV opportunities. Its current design utilises relay providers as trusted entities - widely received as at least sub-optimal - and furthermore fuels fear of an endgame that potentially involves one block builder capturing the right for all of the blockspace.

For the attempt to explore and frame the current landscape of MEV extraction options for stakers it is worth to prepend that:

  • Data sets are still limited, allowing only for early indications

  • The adoption rate of externally built blocks in comparison to late stage PoW mev-geth is still comparably low (yet slowly increasing)

1. Maximal extraction

When opting for maximal extraction, stakers run MEV-boost (or other relay multiplexers) and ideally register validators to various different relays with the aim to receive the highest possible bid for their blockspace. Their main goal is to maximally extract MEV to benefit from significantly higher immediate validator rewards.

Maximally extracting stakers moreover adhere to the Flashbots school of thought and do not leave MEV on the table for other validators, potentially leading to more extensive concentration of power (i.e. pushing stakers in the hands of centralized staking pools as they can offer comparably higher returns).

Unfortunately, the currently most adopted relay (operated by Flashbots) is censoring TXs - apparently for regulatory compliance reasons.

Nonetheless, it should be remarked that the more limited the scope of includable TXs is due to censoring, the less likely it is for a relay/builder to offer the most profitable bid. Hence, in a competitive builder market censoring also comes at a cost for the censoring entity.

Pool stakers should keep in mind that staking pool operators are incentivised to opt for maximal extraction in order to provide competitive products - Lido node operators, for example, are supposed to run mev-boost.

2. Altruistic self-building

Altruistic self-builders do not make use of MEV-boost and thus refrain from additional node stack complexity.

Reminder: MEV-boost is a sidecar to Ethereum. Its usage is purely optional.

Although leveraging mev-boost generally increases the risk of software bugs and thus potentially negatively impacts overall validator rewards, this effect is expected to become more and more negligible as the software hardens over time.

Consequently, these validators build their blocks locally (also referred to as “vanilla” blocks) and include TXs dependent on the local execution clients’ view of the public mempool.

Self-builders generally miss out on the majority of MEV opportunities, netting lower overall validator rewards, which arguably degrades network security in a pure economic-rationality model.

However, self-builders know *for fact* that they are not going to censor TXs, thereby fostering Ethereum’s credible neutrality property and adding to ETH’s long-term value proposition.

3. Partial extraction

Partially extracting proposers do not optimise for the most valuable payload. They can rather be attributed to values-based proposers. For the moment there appear to be two main types of partial MEV extractors, both sharing the utilisation of MEV-boost:

3.1. regulated / ethical

Regulated or ethical MEV extraction means registering validators only with a selected list of

  1. regulatory compliant relays (i.e. censoring transactions related to blacklisted addresses according to a given jurisdiction) or

  2. so called ethical relays (i.e. censoring toxic MEV transactions such as sandwiching attacks on users)

In this context it must be added that relays are generally trusted to (not) censor.

→ But how does a staker know for sure?

Obviously there’s a lot of room for improvement regarding relay and builder transparency. It is expected to see further monitoring tools around relay and builder infrastructure in the near future which will hopefully shed more light on these actors.

3.2. Opportunistic MEV-forgoing

“If we rely on altruism, don’t make altruism expensive [...]

Proposers should not have to sacrifice large amounts of revenue to help ensure censored transactions get in.”

- Vitalik

The core mechanism of opportunistic MEV-forgoing is straightforward:

Validators provide MEV-boost (or the consensus client) with a minimum required absolute value of an external bid (technically: “payload”, e.g. 0.2 ETH) to be considered for inclusion in a block proposal. Otherwise the proposer falls back on the local execution client’s payload (i.e. self-builds).

Consequently, proposers gain exposure to larger MEV opportunities while still adding to the decentralization of the network (if MEV is small or non-existent).

Even though this extraction tactic is not the most profitable, it offers a way out to achieve less costly altruism. Validators autonomously decide on the price tag for guaranteed censorship resistance, e.g. by setting the threshold requirement slightly higher than the median external payload over a certain timeframe.

One technical caveat: the specified value requires manual adjustment to changing network conditions. A future feature enhancement possibly includes a comparison between the value of the locally built block with the external builder's submission using a relative reward delta instead of a fixed one. In order to compare the bids before signing, a few more standardizations around the communication between the beacon client and the execution client have to be worked out.

The above described options represent short-term approaches to extract MEV for stakers given the current external builder network architecture which is patching temporary shortcomings in Ethereum’s current blockchain design.

It seems worthwhile to closely follow the discussions around mid-term MEV mitigation solutions which will likely be in-protocol and entail:

In the meantime stakers should be aware of current trade-offs and compromises when extracting MEV (or not). It appears reasonable to strive for a healthy balance between sufficiently incentivised, decentralised staking setups and not giving up on censorship-resistance as one of the core properties for a thriving Ethereum ecosystem.


This post was supported by a grant from a CLR funding round held by EthStaker, mainly matched by the EF.

Subscribe to Ladislaus
Receive new entries directly to your inbox.
View collectors
This entry has been permanently stored on-chain and signed by its creator.