Baseline MEV computation

Post-Merge, validators earn rewards from maximal extractable value (MEV) as well as from transaction fees on Ethereum’s execution layer when they are elected to propose blocks.

MEV extracted from the perspective of the validator is difficult to accurately estimate. Some of it is embedded in priority fees, some is disbursed in direct payments to the validator fee recipient, some of it might be disbursed in a different payment pattern between a relayer, a builder and a proposer, and some might not ever print on-chain.

The emergence of out-of-protocol proposer-builder separation (PBS) with mev-boost has introduced a menu of different patterns that make it a non-trivial task to estimate how much MEV was extracted by a validator in a given block.

In this page, we are proposing a case based approach in separating MEV from priority fees on a block by block basis (and then on aggregate) based on information aggregated on-chain and from the various MEV relay APIs.

We are approaching crafting this methodology with an iterative mindset, and have yet to enshrine this to the front-end and API. We want to hear from the community on which approach is the most realistic, representative and fair. Discourse forum [coming soon].

Useful definitions

Term	Definition
builder	An agent that constructs a block, drawing from transactions or bundles of transactions sourced from public and/or private mempools.
relay	An entity that gathers blocks and bids from builders. The source of the block that is proposed by a validator who wants to get MEV rewards.
vanilla_block	A block that has not been procured from a MEV relay, and is most likely a build by default spec block.
mev_boost_block	A block that has been procured from a MEV relay.
avg_bid	The average value of bids logged on all relays, in any given block height.
max_bid	The maximum bid observed, from the population of bids received by relays, in any given block height.
winning_bid	The bid that represents the block that made it to the canonical chain as procured from an MEV relay.
fee_recipient	The specified address that receives the priority_fees in the block constructed by the builder. Depending on the case, the fee recipient could be the address of the builder or the proposer.
priority_fees	Also called block rewards; transaction fees paid to the fee_recipient by end-users for their transactions to be included in the block.
end_tx	A transaction that takes place at the end of the block and involves the builder that crafted the block and the block proposer.
proposer_account	Address specified by the validator/proposer where they want to be paid the rewards from the block by the builder
baseline_mev	The minimum MEV rewards calculated in the block, outside of any priority_fees
secondary_builder_address	A second address associated with the builder that is used to pay the proposer_account.
internal_tx	An internal transaction that takes place within the the end of the block that involves the value transfer from any of the builder's addresses to the block proposer.

MEV value transfer patterns in the wild

There are three main on-chain patterns in which we have observed value transfers between a block builder and a validator; (a) one that involves the end_tx as parametrized in the table above, (b) one in which the value transfer happens exclusively via the fee_recipient, and (c) one that involves an an end_tx and an internal_tx.

The following case based approach is based on modulating these three parameters, as well as whether the relay where the block was procured from is known or not.

Case A: Known MEV Relay blocks

Case A.1

This class of cases describe patterns where the builder has set their own address as the fee_recipient and pays the proposer via an end_tx (e.g. Flashbots relay). A builder may choose to use the same address they set as the fee_recipient to pay the proposer or a different one (secondary_builder_address). What is consistent here is that regardless of the address used by the builder, the proposer is paid through an end_tx.

Variable	Value
relay	KNOWN
winning_bid	KNOWN
end_tx	KNOWN
fee_recipient	Builder
internal_tx	n/a

If the winning_bid is greater than or equal to the sum of priority_fees for the transactions in the block, and , we calculate baseline MEV as:

baseline_mev == winning_bid - priority_fees

This is the most straightforward case as the components for computing the baseline_mev are known. The winning_bid is captured from the relay and the priority_fees are computed from the transaction fees in the block.

If the winning_bid is less than the sum of priority_fees, for the transactions in the block, we calculate:

baseline_mev cannot be determined

In the absence of tools to recreate what the block value would have looked like if the proposer made a block by spec, we classify the winning_bid they received as the priority_fees that went to said validator.

Case A.2

This class of cases describe patterns where the builder has set the proposer account as the fee_recipient (e.g. Manifold relay).

Variable	Value
relay	KNOWN
winning_bid	KNOWN
end_tx	n/a
fee_recipient	Proposer
internal_tx	n/a

In this case we revert to:

baseline_mev cannot be determined

Which implies we book everything that went to validator via priority fees.

While initially looking at this from the winning_bid - priority_fees lens appears rational, cases like the Manifold bug have shown that bids can be misconfigured to not show exactly how much a validator receives in the end.

Case A.3

This class of cases describe patterns where the builder has set an alternate receiver address (say a smart contract) in the end_tx which then initiates an internal_tx to send the funds to the validator.

Variable	Value
relay	KNOWN
winning_bid	KNOWN
end_tx	KNOWN
fee_recipient	Builder
internal_tx	KNOWN

If the winning_bid is greater than or equal to the sum of priority_fees for the transactions in the block, and , we calculate baseline MEV as:

baseline_mev == winning_bid - priority_fees

If the winning_bid is less than the sum of priority_fees, for the transactions in the block, we calculate:

baseline_mev cannot be determined

In the absence of tools to recreate what the block value would have looked like if the proposer made a block by spec, we classify the winning_bid they received as the priority_fees that went to said validator.

The calculation is identical to Case A.1, it is just that here, the winning bid would equate to the value of the internal_tx instead of the end_tx.

Case B: Unknown but likely MEV Relay

This class of cases describe patterns where we do not know the relay the block came from, but given the presence of an end_tx this is most likely a relay block.

Variable	Value
relay	UNKNOWN
winning_bid	UNKNOWN
end_tx	KNOWN

In the absence of data from relays, but with an end_tx still observed, if the end_tx is greater than or equal to the sum of priority_fees for transactions in the block, we calculate baseline MEV as:

baseline_mev == end_tx - priority_fees

Conversely, if the end_tx is less than the sum of priority_fees for transactions in the block, we calculate baseline MEV as:

baseline_mev cannot be determined

We then consider baseline_mev undetermined and book all the value that went to the proposer as priority_fees.

Case C: Vanilla block

Variable	Value
relay	UNKNOWN
winning_bid	UNKNOWN
end_tx	UNKNOWN

If all of the parameters we are segregating for are UNKNOWN then we revert to :

baseline_mev cannot be determined

Qualitatively, if this type of state is observed, it could mean a few things: (1) this is a vanilla block, (2) the bid payment was made out of band (e.g. mev-hiding), or (3) the validator is doing their own block building and MEV extraction.

We believe that these cases in their majority are vanilla blocks, but hold out for emerging patterns as the landscape evolves towards maturity.