This post was originally posted on 20210515
Author: Alejo Salles, @fiiiu
Maximal (formerly Miner) Extractable Value (\textrm{MEV}) is the value that can be extracted from a blockchain by any agent without special permissions. Considering this permissionless nature, any agent with transaction ordering rights will be in a privileged position to perform the extraction. In Proof of Work blockchains, it is miners who determine transaction ordering within a block, hence the former “miner” term. In practice, bot operators seek to extract \textrm{MEV} by either paying high fees to increase the likelihood that their transactions are mined, or by finetuning their gas price choices in order to “time” their transactions right, as is the case when backrunning an oracle update to perform a liquidation.
Despite much recent discussion about the topic and, in particular, its associated risks for the Ethereum protocol, we still lack a cohesive formal model for quantifying \textrm{MEV} extraction. At Flashbots, we have released an \textrm{MEV} explorer where we shed light on various aspects of this phenomenon. While we do elaborate on our metrics in the site, they still lack a formal definition. Here, we attempt to provide a unifying operational framework that consolidates \textrm{MEV} extraction metrics, focusing on the Ethereum network^{[1]}.
General Considerations
The first important point to make is that \textrm{MEV} is a theoretical quantity that we can only approach asymptotically. Unforseen extraction methods can and will be devised (every new DeFi hack is an \textrm{MEV} extraction event). Hence, we will here focus instead on the Realized Extractable Value, notated \textrm{REV}, where \textrm{REV} \leq \textrm{MEV}. In other words, \textrm{REV} is the actual value extracted from the blockchain from \textrm{MEV} opportunities^{[2]}.
We note that there’s two classes of actors in the system, searchers and miners. We use the generic label miner for actors that bear the privileged role of transaction inclusion and ordering. Searchers are any nonprivileged actors aiming to profit from these opportunities. Crucially, miners can also act as searchers.
Extracting \textrm{MEV} incurs externalities, like increasing gas costs for all users of the network, or bloating the chain. We won’t dwell into the implications of these externalities here, but we will make them manifest in the model. For more on this and the “\textrm{MEV} Crisis”, be sure to check our Flashbots introductory post.
We are now ready to begin building our framework, starting with a simple model that ignores direct miner payments and searcher competition and other externalities like opportunity checks. We will revisit the model to account for these at a later stage.
Extraction Model
We begin with a model where a single searcher performs an \textrm{MEV} extraction, sharing proceeds with the block miner via gas fees only. We further assume that miners order transactions by descending gas price, which approximates well their optimal strategy and is the default in Ethereum node software.
We decompose the opportunity’s \textrm{REV} in two terms:
where \textrm{REV}_S is the value that goes to the searcher, and \textrm{REV}_M is the value that goes to the miner. Note that, as we expand on below, \textrm{REV} already encompasses the opportunity’s extraction costs (i.e. the actual \textrm{REV} of an opportunity depends on the gas price of the network at extraction time^{[3]}).
Let’s dive into the two different terms. The searcher \textrm{REV} is composed by:
where V_{out} is the value that flows from the searcher to the blockchain in the transactions performing the extraction (excluding gas); V_{in} is the value flowing from the blockchain to the searcher; g_{\textrm{MEV}} is the gas price of the transactions; and s_{\textrm{MEV}} is their size, i.e. the total amount of gas they consumed. V_{out}, V_{in}, and g_{\textrm{MEV}} are denominated in the base network currency (ETH), while s_{\textrm{MEV}} is in units of gas. Separating the gas term from V_{out} will be helpful in quantifying the extraction costs, and it is also how we compute \textrm{REV}_S in practice.
We use “the blockchain” loosely here to refer to any other addresses (corresponding to smart contracts or EOAs) that are not the EOA of the extracting transactions, or smart contracts controlled by the searcher. Note that identifying these is a heuristicguided process based on known searcher patterns, and by all means fallible. Also, we stress that any ancillary transactions related to the \textrm{MEV} extraction (like the “meat” in a sandwich attack) are not part of the set of transactions that contribute to the above variables.
Turning to the miner side, we have:
where g_{eff} is the effective gas price of the transactions that would have been included in the block had the opportunity not been taken. \textrm{REV}_M is thus defined to include the opportunity cost the miner incurs by including the \textrm{MEV}extracting transactions.
As transactions in the mempool are ephemeral, it is impossible to measure g_{\textrm{eff}} a posteriori from only blockchain data and logs. We resort to an approximation that also serves as a lower bound for the value realized by the miner:
where g_{tail} is the gas price of the last transaction in the block^{[4]}.
Plugging equations (2) and (4) we get for the total realized value:
In this rendition the miner and searcher roles are blurred, but we can clearly identify the extraction costs of the opportunity, given by the subtrahend s_{\textrm{MEV}}.g_{tail}.
Finally, note that the value split between searcher and miner at this stage is entirely decided by the choice of g_{\textrm{MEV}}, which is in turn affected by the nature of the opportunity and the presence of other searchers trying to exploit it.
Including Externalities
The scenario presented so far ignores the fact that while singlesearcher successful value extractions exist, they constitute only a small fraction of all \textrm{MEV} activity. In practice, each time an opportunity arises in the network, several searchers will try to take it by engaging in Priority Gas Auctions or submitting multiple competing transactions to backrun a target state change. Moreover, sometimes searchers perform onchain calculations to validate the existence of an opportunity (“preflights”). When these checks fail, there is no value extracted, but miners will still benefit from the collected gas fees.
Note, however, that all of this activity is zerosum: all costs incurred by searchers by competing with each other, validating state, etc., directly becomes miner profit. From the miner’s perspective, the fee paid by a searcher’s preflight is no different from, say, the one coming from an unsuspecting token transfer. This goes to say that none of this value amounts to a contribution to the {\textrm{REV}}. However, it is of interest of us to quantify it, since it is precisely what generates trouble for regular users of the network not involved in this commerce.
We will then need to take a broader view of \textrm{MEV}, and define a new term, the Extractable Value Cost ({\textrm{EVC}}), which summarizes all the extra value induced by \textrm{MEV} extraction activity, that is not part of the extracted value itself. With this definition, we have:
In words, the total \textrm{MEV} activity is composed of the extracted \textrm{MEV} (\textrm{REV}, divided among searchers and miners), and the global costs of extractable value, going directly to miners and quantified by {\textrm{EVC}}. Note that {\textrm{EVC}} only encompasses onchain activity, ignoring offchain costs like network bloating due samenonce transaction replacement.
We can compute the {\textrm{EVC}} as follows:
While altogether eliminating \textrm{MEV} is likely impossible^{[5]}, it is Flashbots’ core mission to reduce the negative externalities of \textrm{MEV}related activities by improving the overall efficiency of the extraction process. The present framework allows us to state this mission concisely as that of reducing {\textrm{EVC}}.
Flashbots Bundles
Flashbots optimizes \textrm{MEV} extraction by allowing searchers to submit bundles of ordered transactions, effectively transferring part of the ordering privileges from the miners to the searchers. These bundles are included by the miners provided they get more out of them than by mining regular transactions. While searchers can still set a gas fee, the preferred way to pay the miners for inclusion is via a direct coinbase
transfer included in the bundle^{[6]}.
We thus need to account for this extra term in our miner revenue formula (4):
where V_{direct} is the total value transferred to the coinbase
address. Note that this new term doesn’t affect the total \textrm{REV} as it is accounted for by a corresponding increase of the V_{out} term.
Apart from the extra term, we now expand the set of transactions that contribute to the terms in the formula to include all transactions included in the bundle. In particular, if a bundle includes the “meat” in an arbitrage, its size and gas price count towards the extracted value. This ensures we account for the opportunity cost incurred by miners when including bundles instead of regular transactions.
Finally, expression (2) for searcher value stays the same, but also requires expanding the implied transaction set to all transactions in the bundle. The rest of the model remains unchanged by the utilization of Flashbots’ bundles. With these changes, the model also encompasses alternative relay services like private mempools.
It is worth noting that Flashbots reducing {\textrm{EVC}} does not imply a decrease in miners’ revenue, since their share of extracted value might increase as a result of the extraction optimization. Flashbots executions are deterministic and therefore searchers are likely to pay the miners more than if they risked paying for reverts or cancellations. Finding the revenue sharing equilibrium is ultimately a gametheoretic problem which deserves independent treatment.
Final Thoughts
By unifying various quantities involved in \textrm{MEV} extraction, our framework enables us to pose clearcut questions like “how big are the costs of \textrm{MEV} extraction activities for the network?”, or “to what extent has Flashbots helped in reducing these costs?”. These and other interesting perspectives on \textrm{MEV} extraction based on this framework will be included in coming versions of \textrm{MEV}Explore.
Throughout this work, we have swept under the rug the complications involved in actually measuring the “atomic terms” entering the definitions, like V_{out}, or the actual set of \textrm{MEV}extracting transactions. This task involves ad hoc heuristics for an evergrowing number of \textrm{MEV} extraction strategies, and while we strive for establishing a useful classification, there will always be unforeseen opportunities that will elude detection^{[7]}.
We pass no judgment as of which types of \textrm{MEV} extraction are “good” and which are “bad”, although there’s certainly ways in which this question could be meaningfully approached (“has an unrelated third party incurred loss due to the extraction?”). We leave this subtle question for future work, but we restate our belief that {\textrm{EVC}} is undesirable and we shall strive to minimize it.
Join our Efforts!
At Flashbots, we perform research and build systems for mitigating the upcoming \textrm{MEV} crisis, and we would love your help. We are a distributed organization with the principles of a pirate hacker collective, and have several open positions. We also issue grants to external researchers doing work aligned with ours, please find out more in our Research repository, or join our Discord!
Special thanks to Scott Bigelow, Phil Daian, Stephane Gosselin, Alex Obadia, Tina Zhen, and Jason Paryani for welcoming me onboard and all Flashbots’ crew for the work and discussions leading to this post.

Note however that most of what is presented here should apply with minor variations to other blockchains that have actors with transactionordering privileges. Work is underway to flesh out these variations. ↩︎

The definitions here are consistent with a theoretical approach to \textrm{MEV} to be published in an upcoming paper (sneak peek here). ↩︎

It’s up for discussion whether the (nonmeasurable) \textrm{MEV} should also depend on this. ↩︎

One would need to look into adjacent block gas prices if the entire block was taken up by \textrm{MEV}extracting transactions. ↩︎

Note however that it can likely be reduced to some extent with smart protocol design, there’s some ongoing efforts to this avail. ↩︎

A direct
coinbase
transfer could also be present in a standard, nonbundled extraction, but it would make little sense for the searcher to do it since miners typically only look at gas prices for transaction inclusion and ordering. ↩︎ 
See this paper for a complementary, protocol agnostic approach to \textrm{MEV} detection based on flagging certain types of “transaction dynamics” (displacement, insertion, and suppression). ↩︎