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

TermDefinition
builderAn agent that constructs a block, drawing from transactions or bundles of transactions sourced from public and/or private mempools.
relayAn 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_blockA block that has not been procured from a MEV relay, and is most likely a build by default spec block.
mev_boost_blockA block that has been procured from a MEV relay.
avg_bidThe average value of bids logged on all relays, in any given block height.
max_bidThe maximum bid observed, from the population of bids received by relays, in any given block height.
winning_bidThe bid that represents the block that made it to the canonical chain as procured from an MEV relay.
fee_recipientThe 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_feesAlso called block rewards; transaction fees paid to the fee_recipient by end-users for their transactions to be included in the block.
end_txA transaction that takes place at the end of the block and involves the builder that crafted the block and the block proposer.
proposer_accountAddress specified by the validator/proposer where they want to be paid the rewards from the block by the builder
baseline_mevThe minimum MEV rewards calculated in the block, outside of any priority_fees
secondary_builder_addressA second address associated with the builder that is used to pay the proposer_account.
internal_txAn 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.
VariableValue
relayKNOWN
winning_bidKNOWN
end_txKNOWN
fee_recipientBuilder
internal_txn/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\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: 
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).
VariableValue
relayKNOWN
winning_bidKNOWN
end_txn/a
fee_recipientProposer
internal_txn/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.
VariableValue
relayKNOWN
winning_bidKNOWN
end_txKNOWN
fee_recipientBuilder
internal_txKNOWN
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: 
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.
VariableValue
relayUNKNOWN
winning_bidUNKNOWN
end_txKNOWN
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: 
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

VariableValue
relayUNKNOWN
winning_bidUNKNOWN
end_txUNKNOWN
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.