MEV-Distribution

The distribution of MEV in Ethereum and associated methodology for gathering data.

Q: How do we determine the distribution of value within a specific block? How is the MEV value allocated among searchers, builders, and proposers?

Terminology:

• Builder: The entity creating the block.
• Proposer: A validator who can delegate block production to a builder.
• Searcher: An Entity who engage in MEV (Miner Extractable Value) activities

In Ethereum, validators set a feeRecipient, this it the person who will get the transaction fees from a block. If a validator is not running MEVboost, this will be their own address. However in MEVboost, proposers set the feeRecipient to builder and the proposer gets paid from a transaction that sends money directly to them.

1. Understand how much the builder tipped the proposer for transaction inclusion.
   1. In MEVboost, generally the last transaction in the block is the builder tip. If that transaction is a transfer from the builder's address, we assume it is to the proposer and the builder's tip. The majority of MEVboost follows this pattern. Example
   2. However not all blocks follow this pattern. In these cases, the feeRecipient is set as the proposer instead of the builder, which makes it difficult to detect what is the builder payment for block acceptance as there maybe multiple payments to the proposer. And as a result we did not include blocks that fit this pattern. Example in this block there are 2 payments to the proposer, it is unclear which one is the builder payment.
      1. Therefore we are under reporting how many MEVboost blocks there are.
   3. Alternatively MEVboost blocks can be detected by using the MEVboost APIs that each relay uses. However this methodology wasn't done as we wanted to use Dune as our backend for auditability. See here for more data providers.
2. Understand how much searchers tipped in a specific block to the builder
   1. Searchers pay by sending value directly to the builder though an eth transfer()
      1. Note a searcher may increase the value of the transfer through EIP1559 tips, however this value was not included in our calculations. (In practice this represents less than 1% of total tip value)
3. Calculating Builder profitability
   1. Builders get all EIP1559 tips in the block. Therefore we use: EIP1559 Tips + Searcher Tips - Builder Payment = Builder Profit
   2. Note the begining of MEV boost, builder profits were occasionally negative.
   3. Also the above methodology only works if the builder is set as the feeRecipient, which is not the case for all MEVboost blocks - however the case where the builder is not the feeRecipient was not included.
4. Calculating Searcher profitability
   1. This was outsourced to EigenPhi, which has analytics on identifying searcher transactions and determining their revenue, costs, and profit.
5. Calculating Relay profitability - well relays currently don't make any money, thus this value is hard coded at 0.
6. Calculating new value given to the Proposer through MEV
   1. If a proposer does not run MEVboost, their execution layer rewards are all EIP1559 tips. By running MEVboost, proposers tend to get more money, as the builder payment is greater than the EIP1559 tips. This net new money is calculated by builder payment - EIP1559 tips.
7. Calculating the total value generated by MEV
   1. Searcher Profits + Builder Profits + Proposer New Money

The above data was captured in this Dune dashboard, to replicate this data using data from relays instead of heurists start here