Thanks to Hasu & MetaChris from Flashbots as well as Sean from Sigma Prime for critical comments and feedback on draft versions of this FAQ.

Several of the following questions have also been recently addressed in an educational collaboration with EthStaker. You may watch it here.

Overly simplifying, MEV (Maximal Extractable Value) deals with generating revenue by optimally ordering transactions (TXs) in a block. It is a rather controversial topic, as gaining value from arbitrarily re-ordering or inserting TXs in a block must not only be ‘good’ (making markets more efficient in case of arbitrage or liquidations), but also ‘bad’ (e.g. by users being front-run or the blockchain potentially being destabilised).

Flashbots can be categorized as a research collective specialized in the topic of MEV. Their self-imposed goal is to mitigate negative externalities of MEV for the Ethereum blockchain and its users. Historically, the team has shown high value-alignment with the broader Ethereum community. Apart from research they offer a variety of MEV related products and play diverse, active roles in their external block builder network (more on this below).

For the majority of users MEV became noticeable for the first time during DeFi summer 2020. As on-chain economic activity and settlement value rose to unseen highs, the infamous ‘gas wars’ began: specialized bots began out-bidding each other with gas for their profitable TX bundles to be included at particular places in a block. This undesirable race condition led to chain congestion and harmed not only the user experience but the blockchain as a whole.

Flashbots reacted by offering external block builder services, side-channeling on-chain auctions to an open off-chain auction environment - utilising a software called mev-geth, a fork of Go Ethereum for sourcing optimal MEV TXs. Flashbots argue that enabling broader access to MEV extraction strengthens Ethereum’s economic security, as leaving MEV on the table for others would in reverse subsidize potential attackers and thus serve as a centralizing force.

Today, more than 90% of miners outsource block construction to Flashbots. Hundreds of millions of dollars in MEV have been extracted to the present day.

As described, democratizing access to MEV during Ethereum’s PoW era has been crucial in order to keep the blockchain resilient. Maintaining similar properties in a post-merge PoS world is where mev-boost comes into play:

MEV-boost - more neutrally known as Builder API - is a free and open source piece of software which serves as middleware, enabling a communication channel between validators and one or more block builders.

As shown in the diagram below, it is based on a network architecture that allows for the functional separation of block proposers and block builders. Importantly, mev-boost is a sidecar to consensus in that it does not interfere with its ruleset (for liveness reasons; see green rectangles). Therefore,

• a pure node runner does not need to run mev-boost in order to follow the chain.

• a validator does not necessarily need to run mev-boost; but there is an economic incentive to do so (i.e. extract MEV when chosen to propose a block).

• if a validator did not run mev-boost, the local execution client would serve as fallback for constructing blocks.

In order to better comprehend the different roles of the various actors in this extra-protocol block builder architecture, consider that all TXs are being sent in plaintext. This leads to the fact that every actor has to trust another to some extent. Main actors represent:

Searchers

• Specialized network participants searching for profitable on-chain activity

• Programm algorithms / bots in order to identify and extract MEV opportunities (e.g. arbitrage or front-running)

• Form bundles of TXs and direct them to builders

Builders

• Highly specialized actors who aggregate and construct blocks based on bundles from searchers

• Run the algorithms (e.g. First Come First Serve, First Price Auctions, etc.) which order the bundles and TXs in a block template (technically: execution payload)

• Serve as DoS protection for validators

• Bid for and buy the validators’ blockspace with the help of one or more relays

Relay(s)

• In normie terms: a ‘bazaar’ for blockspace

• Technically: a doubly-trusted data-availability layer and communication interface between builders and validators

• Function as block & bid simulators (for validity checks) as well as an escrow for execution payloads (i.e. the bundled TXs)

• Enable an economic incentive mechanism for validators to not steal MEV from builders, and thus have to be trusted by both validators and builders

• Ideally facilitate competition amongst block builders, because validators may connect to many relays (to mitigate censorship risks)

Validators

• Receive a block from their local execution client, i.e. their local block builder, and sign / ‘mine’ it, or

• Receive an execution payload header from one or more relays and blindly sign a block without seeing the underlying execution payload (i.e. the blinded TXs escrowed by the relay)

It is worth noting that while mev-geth allows for only a 1:1 relationship between a miner and a block builder, mev-boost by contrast enables validators to connect to multiple relays linked to multiple block builders.

In the context of outsourced block construction several different trust relationships can be examined. Just to highlight a few:

• Builders could unpack bundles and steal MEV from searchers

• Builders could censor TXs from users

• Relays could withhold execution payloads from validators, or unpack and steal MEV from builders

Arguably the most affected trust relationship post-merge is the one between validators and builders, since there are going to be many more at-home block producers than PoW miners. If relays were left out of the block builder network design, validators would have an incentive to steal builders’ MEV. That is because the extractable value from just one block proposal (including MEV) could potentially be more valuable for a solo-staker than its extended relationship with a builder.

The instantiation of relays, however, flips this trust model: validators have to blindly sign off a block (header) and submit it to a relay without knowing the content inside (execution payload), while the relay escrows the valuable execution payload. Hence, by using Builder-API/mev-boost validators can not steal MEV from builders.

Still, a validator needs to trust a relay to not withhold the execution payload and to properly check that the specified fee recipient address (formerly coinbase address) has not been changed after the validator had already blindly signed off a given block header. This would result in the validator losing the MEV opportunity.

As of now, the given network architecture seeks to discourage the aforementioned options for action by enabling validators to connect to not only one but many relays and many builders to many relays, facilitating the application of free market forces and ultimately letting users decide.

TL;DR: a missed block proposal, which is not a slashable event.

At the particular slot where a validator is randomly chosen to propose a block, the consensus client asks the attached mev-boost for the most profitable execution payload to include in that block. A connected relay then provides the validator with an execution payload header which the validator blindly signs off after initial validity checks by the beacon node. If the relay afterwards

a) releases an escrowed execution payload which for some reason is invalid or

b) the relay for some other reason withholds the execution payload

it is likely going to be the relay (operator) who will propagate an invalid block with the validator’s signature to the network.

As a consequence, other nodes will reject the invalid block as it violates their given ruleset. This does not constitute a slashable event for the block proposing validator, but instead leads to a missed block and a missed MEV opportunity followed by the corresponding offline penalty.

Again, the intention and mitigation strategy of the external block builder network design is to expedite competition among builders and relays, thereby encouraging and incentivizing better performance, e.g. by delivering blocks in time.

Note: mev-boost requires the validator to submit the signed blinded beacon block to a relay in order to receive the escrowed execution payload. Otherwise, if it proposed and propagated a different block, e.g. a locally constructed one, it would be subject to a double-signing.

Massive single block MEV opportunities such as shown above represent absolute outliers. Nevertheless, validators are expected to increase their revenue in the double-digit percentage range on average compared to their pre-merge revenues.

By contrast to issuance, which is illiquid at least until withdrawals will have been enabled as part of the first post-merge upgrade, MEV is immediately liquid and adds balance to the specified fee recipient address.

Moreover, it should be noted that priority fees as part of the post-merge validator revenue often contain MEV: Priority fees, MEV as priority fees, direct payments to the fee recipient and side payments to the fee recipient all belong to the potential execution-side revenue of a validator.

The software itself, likely yes.

At the time of writing some clients have an mev-boost-enabled implementation to test with.

This section should be a separate FAQ on its own since the topic is still very much open for debate. In brief:

Generally, node operators could have an incentive to keep parts of the MEV they receive for themselves and hide it from the pool. However, the external builder network design at least creates a more transparent marketplace infrastructure for blockspace and thus for MEV itself. It serves for transparency and enables public auditability of MEV at a given slot so that if node operators kept (parts of) the MEV for themselves, they are identifiable and thus disincentivised to misbehave.

As staking pool design varies, users and pool stakers are well-advised to contact and ask their pool operators about how they intend to handle the distribution of MEV.

****

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

Thanks to Hasu & MetaChris from Flashbots as well as Sean from Sigma Prime for critical comments and feedback on draft versions of this FAQ.

Several of the following questions have also been recently addressed in an educational collaboration with EthStaker. You may watch it here.

Overly simplifying, MEV (Maximal Extractable Value) deals with generating revenue by optimally ordering transactions (TXs) in a block. It is a rather controversial topic, as gaining value from arbitrarily re-ordering or inserting TXs in a block must not only be ‘good’ (making markets more efficient in case of arbitrage or liquidations), but also ‘bad’ (e.g. by users being front-run or the blockchain potentially being destabilised).

Flashbots can be categorized as a research collective specialized in the topic of MEV. Their self-imposed goal is to mitigate negative externalities of MEV for the Ethereum blockchain and its users. Historically, the team has shown high value-alignment with the broader Ethereum community. Apart from research they offer a variety of MEV related products and play diverse, active roles in their external block builder network (more on this below).

For the majority of users MEV became noticeable for the first time during DeFi summer 2020. As on-chain economic activity and settlement value rose to unseen highs, the infamous ‘gas wars’ began: specialized bots began out-bidding each other with gas for their profitable TX bundles to be included at particular places in a block. This undesirable race condition led to chain congestion and harmed not only the user experience but the blockchain as a whole.

Flashbots reacted by offering external block builder services, side-channeling on-chain auctions to an open off-chain auction environment - utilising a software called mev-geth, a fork of Go Ethereum for sourcing optimal MEV TXs. Flashbots argue that enabling broader access to MEV extraction strengthens Ethereum’s economic security, as leaving MEV on the table for others would in reverse subsidize potential attackers and thus serve as a centralizing force.

Today, more than 90% of miners outsource block construction to Flashbots. Hundreds of millions of dollars in MEV have been extracted to the present day.

As described, democratizing access to MEV during Ethereum’s PoW era has been crucial in order to keep the blockchain resilient. Maintaining similar properties in a post-merge PoS world is where mev-boost comes into play:

MEV-boost - more neutrally known as Builder API - is a free and open source piece of software which serves as middleware, enabling a communication channel between validators and one or more block builders.

As shown in the diagram below, it is based on a network architecture that allows for the functional separation of block proposers and block builders. Importantly, mev-boost is a sidecar to consensus in that it does not interfere with its ruleset (for liveness reasons; see green rectangles). Therefore,

• a pure node runner does not need to run mev-boost in order to follow the chain.

• a validator does not necessarily need to run mev-boost; but there is an economic incentive to do so (i.e. extract MEV when chosen to propose a block).

• if a validator did not run mev-boost, the local execution client would serve as fallback for constructing blocks.

In order to better comprehend the different roles of the various actors in this extra-protocol block builder architecture, consider that all TXs are being sent in plaintext. This leads to the fact that every actor has to trust another to some extent. Main actors represent:

Searchers

• Specialized network participants searching for profitable on-chain activity

• Programm algorithms / bots in order to identify and extract MEV opportunities (e.g. arbitrage or front-running)

• Form bundles of TXs and direct them to builders

Builders

• Highly specialized actors who aggregate and construct blocks based on bundles from searchers

• Run the algorithms (e.g. First Come First Serve, First Price Auctions, etc.) which order the bundles and TXs in a block template (technically: execution payload)

• Serve as DoS protection for validators

• Bid for and buy the validators’ blockspace with the help of one or more relays

Relay(s)

• In normie terms: a ‘bazaar’ for blockspace

• Technically: a doubly-trusted data-availability layer and communication interface between builders and validators

• Function as block & bid simulators (for validity checks) as well as an escrow for execution payloads (i.e. the bundled TXs)

• Enable an economic incentive mechanism for validators to not steal MEV from builders, and thus have to be trusted by both validators and builders

• Ideally facilitate competition amongst block builders, because validators may connect to many relays (to mitigate censorship risks)

Validators

• Receive a block from their local execution client, i.e. their local block builder, and sign / ‘mine’ it, or

• Receive an execution payload header from one or more relays and blindly sign a block without seeing the underlying execution payload (i.e. the blinded TXs escrowed by the relay)

It is worth noting that while mev-geth allows for only a 1:1 relationship between a miner and a block builder, mev-boost by contrast enables validators to connect to multiple relays linked to multiple block builders.

In the context of outsourced block construction several different trust relationships can be examined. Just to highlight a few:

• Builders could unpack bundles and steal MEV from searchers

• Builders could censor TXs from users

• Relays could withhold execution payloads from validators, or unpack and steal MEV from builders

Arguably the most affected trust relationship post-merge is the one between validators and builders, since there are going to be many more at-home block producers than PoW miners. If relays were left out of the block builder network design, validators would have an incentive to steal builders’ MEV. That is because the extractable value from just one block proposal (including MEV) could potentially be more valuable for a solo-staker than its extended relationship with a builder.

The instantiation of relays, however, flips this trust model: validators have to blindly sign off a block (header) and submit it to a relay without knowing the content inside (execution payload), while the relay escrows the valuable execution payload. Hence, by using Builder-API/mev-boost validators can not steal MEV from builders.

Still, a validator needs to trust a relay to not withhold the execution payload and to properly check that the specified fee recipient address (formerly coinbase address) has not been changed after the validator had already blindly signed off a given block header. This would result in the validator losing the MEV opportunity.

As of now, the given network architecture seeks to discourage the aforementioned options for action by enabling validators to connect to not only one but many relays and many builders to many relays, facilitating the application of free market forces and ultimately letting users decide.

TL;DR: a missed block proposal, which is not a slashable event.

At the particular slot where a validator is randomly chosen to propose a block, the consensus client asks the attached mev-boost for the most profitable execution payload to include in that block. A connected relay then provides the validator with an execution payload header which the validator blindly signs off after initial validity checks by the beacon node. If the relay afterwards

a) releases an escrowed execution payload which for some reason is invalid or

b) the relay for some other reason withholds the execution payload

it is likely going to be the relay (operator) who will propagate an invalid block with the validator’s signature to the network.

As a consequence, other nodes will reject the invalid block as it violates their given ruleset. This does not constitute a slashable event for the block proposing validator, but instead leads to a missed block and a missed MEV opportunity followed by the corresponding offline penalty.

Again, the intention and mitigation strategy of the external block builder network design is to expedite competition among builders and relays, thereby encouraging and incentivizing better performance, e.g. by delivering blocks in time.

Note: mev-boost requires the validator to submit the signed blinded beacon block to a relay in order to receive the escrowed execution payload. Otherwise, if it proposed and propagated a different block, e.g. a locally constructed one, it would be subject to a double-signing.

Massive single block MEV opportunities such as shown above represent absolute outliers. Nevertheless, validators are expected to increase their revenue in the double-digit percentage range on average compared to their pre-merge revenues.

By contrast to issuance, which is illiquid at least until withdrawals will have been enabled as part of the first post-merge upgrade, MEV is immediately liquid and adds balance to the specified fee recipient address.

Moreover, it should be noted that priority fees as part of the post-merge validator revenue often contain MEV: Priority fees, MEV as priority fees, direct payments to the fee recipient and side payments to the fee recipient all belong to the potential execution-side revenue of a validator.

The software itself, likely yes.

At the time of writing some clients have an mev-boost-enabled implementation to test with.

This section should be a separate FAQ on its own since the topic is still very much open for debate. In brief:

Generally, node operators could have an incentive to keep parts of the MEV they receive for themselves and hide it from the pool. However, the external builder network design at least creates a more transparent marketplace infrastructure for blockspace and thus for MEV itself. It serves for transparency and enables public auditability of MEV at a given slot so that if node operators kept (parts of) the MEV for themselves, they are identifiable and thus disincentivised to misbehave.

As staking pool design varies, users and pool stakers are well-advised to contact and ask their pool operators about how they intend to handle the distribution of MEV.

****

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