Comment on page
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].
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. At the time of writing, relays that prescribe for builders to set the fee_recipient as their own address and then disburse the reward to the proposer separately, on a subsequent transaction collectively represent ~90% of the MEV relay landscape. |
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 |
There are two 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, and (b) one in which the value transfer happens exclusively via the fee_recipient.The following case based approach is based on modulating these two parameters, as well as whether the relay where the block was procured from is known or not.
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). Variable | Value |
|---|---|
relay | KNOWN |
winning_bid | KNOWN |
end_tx | KNOWN |
fee_recipient | Builder |
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 |
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.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.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.
Last modified 7mo ago