Skip to main content
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.

​
Useful definitions

​
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. 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\text{baseline\_mev} = \text{winning\_bid} - \text{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:
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). In this case we revert to:
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. 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\text{baseline\_mev} = \text{winning\_bid} - \text{priority\_fees}
If the winning_bid is less than the sum of priority_fees, for the transactions in the block, we calculate:
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. 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\text{baseline\_mev} = \text{end\_tx} - \text{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:
We then consider baseline_mev undetermined and book all the value that went to the proposer as priority_fees.

​
Case C: Vanilla block

If all of the parameters we are segregating for are UNKNOWN then we revert to :
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.