MEV has been a hot topic in the blockchain industry, and particularly relevant in DeFi. When blockchains still relied on proof of work, MEV stood for “miner extractable value,” but it now commonly stands for “maximal extractable value.” Fundamentally, it is the value that can be obtained by including, excluding, or reordering transactions in a block, in addition to standard block rewards.
MEV naturally arises from the fact that block producers are responsible for coordinating users’ preferences and hence are in a position to profit from information asymmetries. (In computer science-speak, they are responsible for “advancing semantically interesting state” — a point in the system where an important change occurs that matters to its operation, like the creation of a new block.)
Because there are many ways to coordinate preferences, block producers can gain value through strategically performing the coordination task in a way that benefits them. This makes MEV fundamental to how blocks get built on nearly all blockchains. And while MEV manifests in various forms — some good, some bad (both of which we’ll discuss below) — it drastically affects protocols by changing the incentives of the people participating in them.
It’s only by understanding MEV that protocol designers can help manage it. And because understanding these effects and addressing the externalities of MEV has been a topic of widespread interest and debate, in this post we explain the basics of what MEV is, how it affects blockchains, and ways to address it.
Perhaps the simplest form of MEV is frontrunning. Frontrunning occurs whenever a transaction is strategically inserted right before a target transaction for some type of market advantage. For example, consider a first-come, first-serve lottery where at some randomly announced block, the first transaction to interact with a smart contract can claim some prize. In this case, the block producer for the slot when the prize is available to claim can always guarantee that they can claim the prize before any users submitting transactions.
Another example of MEV is a form of onchain arbitrage called backrunning. Whereas frontrunning rearranges transactions so the person who finds it can extract profits (or execute other smart contract calls to their benefit) before someone’s transaction executes, backrunning places the transaction after that person’s transaction.
If Alice broadcasts an order to buy 1,000 ETH worth of ExampleTokens via an automated market maker (AMM), it shifts the price at that AMM and creates a price difference compared to other AMMs. The larger her trade as a fraction of the AMM’s liquidity, the larger this price impact. A third party who spots this (typically called a searcher) can insert a sell transaction right after Alice’s to profit from this price differential, moving the spot price of the AMM back in line with the rest of the market in the process.
Note that this MEV opportunity existed because the AMM’s price drifted from the actual price of the asset. In this case, backrunning actually provides a service in keeping AMMs’ prices up to date.
Another kind of MEV is a sandwich attack, in which a target transaction is sandwiched in between frontrunning and backrunning transactions to influence price and more.
Suppose Alice again broadcasts an order to buy 1000 ETH worth of ExampleTokens via an AMM. With no attack, the AMM might fulfill this order at an average price of 0.1 ETH per token. A sandwich attacker can frontrun Alice’s trade by inserting a transaction just ahead of it that buys ExampleTokens from the same AMM. This will increase the spot price of the AMM when Alice’s trade gets executed, causing Alice to pay a higher price than she would have otherwise.
Then the attacker can also backrun Alice’s transaction, adding a transaction just after it that sells the ExampleTokens to the AMM at an inflated price. The net result is that Alice pays a higher price for the ExampleTokens, and the attacker earns a profit.
These simple examples already show a few interesting properties of MEV: First, searchers don’t necessarily need their transactions to appear in an exact order. Backrunning, for example, can be profitable as long as the transactions appear after Alice’s transaction (and any intervening transactions don’t interact with the same decentralized exchange or DEX pool). Second, even if a searcher’s backrunning transaction doesn’t get sequenced as intended (after Alice’s transaction), the searcher’s transaction can automatically abort the attack by reverting.
Combining these two ideas, even without precise control over transaction ordering, searchers can attempt speculative MEV: insert an MEV transaction that will execute if sequenced as hoped, but will revert otherwise. The only cost of failure is transaction fees for the reverted transactions. If transaction costs are low relative to the potential gains from the MEV opportunity, it might be worthwhile for the searcher to attempt many speculative MEV transactions, even if most of them fail. Speculative MEV especially makes sense when gas fees are low so searchers pay almost nothing for failed attempts.
Why is MEV exploitation possible?
In the simplest traditional blockchain designs users broadcast their transactions to a public peer-to-peer network. This process places the transaction into the mempool, a public holding area maintained by each validator of transactions waiting to be included in the chain.
When it is a validator’s turn to propose a block, they scan their mempool to decide which transactions to include and in what order. Naively, a validator might sort the transactions in decreasing order of fees and simply include the maximal prefix of this list that fits within the gas limit to maximize the fees they earn.
But a validator can decide which transactions to include in specific orders to maximize the MEV they earn. Importantly, validators have full jurisdiction over what gets included. Not only are they free to pick the ordering that favors them most, they can add their own transactions — with the benefit of seeing all other transactions in the block.
While this picture captures how MEV started out on blockchains, it omits much of the complexity of how MEV works today. A complex infrastructure has evolved with multiple specialized competing parties who facilitate MEV. For example on Ethereum, proposers rarely construct blocks themselves, instead relying on this infrastructure to decide which block to propose. The most important parties — in addition to the existing users and proposers — are searchers and builders.
In practice, the ways these parties interact with each other is incredibly complex and constantly evolving. For example, users frequently opt to send their transactions not to public mempools, but to private ones, which broadcast their transactions to only a select list of searchers and builders, giving them an edge over their competition. In return, these private mempools sometimes explicitly pay users to submit to them or make promises to users that certain types of MEV won’t be extracted from them. The way the MEV ecosystem works also differs greatly from chain to chain and is constantly evolving.
If not properly addressed, the incentives MEV creates can bring negative externalities to the system, which must be understood so they can be addressed.
For example, in the traditional setup — without MEV infrastructure, where users simply submit transactions to the public mempool and validators pick a block — a searcher might be incentivized to spam many speculative MEV attacks. Or multiple searchers might actively compete for the same MEV opportunity onchain. In both of these cases, lots of blockspace gets taken up by useless transactions, driving gas costs up and decreasing the opportunity for other transactions to land.
MEV can also affect the consensus layer. If the revenue from MEV in a given block outweighs standard block rewards by a large enough margin, it may be rational for the next proposer to fork the chain to claim this value.
Finally, MEV can be a centralizing force in the blockchain ecosystem, which is meant to be decentralized. Those with an edge in MEV extraction can accumulate disproportionate profits, leading to increased control and influence over the network.
In response, researchers, blockchain designers, and users have proposed multiple approaches to mitigate MEV, or at least reduce its negative externalities. Many of the elements of today’s MEV infrastructure have arisen to address these very problems, although not without creating problems of their own.
One of the earliest and most widely adopted approaches to tackle MEV’s externalities is using offchain auctions to facilitate competition for MEV.
Block builders run auctions where searchers compete to win MEV opportunities in a given builder’s block. By competing via these auctions, searchers no longer have incentives to spam the chain with speculative transactions that often revert. Today these auctions rely on trusted third parties (sometimes implemented within trusted hardware enclaves like TEEs) to keep the mempool private and run the auction.
While these auctions address the externalities MEV has on network performance, they don’t address the negative externalities users face.
Order flow auctions (OFAs) aim to address this problem. OFAs allow users to selectively share information about their transaction with searchers. If searchers find a profitable MEV opportunity targeted at the transaction, they bid for the right to extract the MEV. The searcher with the highest bid gains exclusive rights to extract MEV from that user’s transaction; in return the user gets paid the bid. In essence, OFAs redistribute some of the MEV back to users.
Tweaks to the consensus layer can also mitigate the effects of MEV.
For example, single-slot finality (SSF), whereby each block is finalized within a slot (with no possibility of forking), is a partial solution to the consensus-layer risk that MEV poses. Once a block is finalized, a subsequent proposer can no longer fork the blockchain to extract the value in that block themselves.
This doesn’t completely eliminate consensus layer effects, though: Other validators might be incentivized not to finalize a block from a competing proposer if there is valuable MEV that could instead be taken by the next proposer.
Single-slot finality does prevent consensus-layer impact of MEV under an honest majority assumption. One might be tempted to assume that, since consensus protocols already require an honest majority assumption among validators, this is a safe assumption to make. Unfortunately, these two honest majority assumptions are not equivalent. Safety violations in a consensus protocol (e.g., equivocating attestations), which are possible given a corrupt threshold of nodes, typically lead to public evidence of misbehavior.
MEV, however, does not produce attributable evidence. For this reason, validators might reasonably be unwilling to attack consensus (for fear of exposure) but willing to chase MEV. This latter assumption is a strong honest majority assumption (most nodes will be honest even if attacking produces no evidence) versus a weak honest majority assumption (most nodes will be honest only if attacks are detectable) — an important distinction that affects multiple MEV mitigations, which we will come back to.
A second group of approaches to mitigating MEV goes further, targeting MEV itself. Broadly, these approaches can be divided into three categories:
Some types of MEV can be prevented through careful application-specific design.
For example, Dutch Auctions are trivially vulnerable to MEV, because it is profitable to front-run the first broadcast bid. But attacking Vickrey Auctions implemented via a commit-reveal scheme is more difficult, because it would require re-organizing the chain to retroactively insert a bid commitment.
Similarly, limiting the maximal tolerable price slippage, batch auctions, or switching from an AMM to limit order books are all possible design choices that remove or reduce potential MEV extraction for specific applications. Of course, all of these approaches require careful consideration by application developers, and they often impose a performance penalty (e.g., requiring extra transactions or extra data posted on-chain).
Next are approaches that aim to ensure fair ordering of transactions: Transactions are ordered first come, first served.
Given that there is no central server in DeFi but instead a distributed network of nodes that receives and orders transactions, nodes can see transactions in different relative orders. Consequently, agreeing on a relative order is not a straightforward task. Ongoing work therefore focuses on consensus protocols that approximate a fair ordering. Also, once again, fair ordering requires a strong honest majority assumption on validators since there is no way to tell if validators misreport the time they received a transaction.
Last are the solutions that attempt to order transactions blindly: The transaction order is agnostic to the transaction contents.
One way to achieve this is by committing to a set of transactions in a block first, then randomly shuffling them with a randomness beacon that is sampled after the transaction set is finalized. This can make MEV more difficult — but not impossible. Speculative attacks, where searchers spam potential backrunning transactions to hope to land in a favorable spot, still exist.
***
Our goal with this overview is to help protocol designers understand MEV and its effects so they can help address it. While MEV introduces dynamics that can disadvantage users and distort incentives, it is also a transparent and observable phenomenon inherent to public blockchain infrastructure. Because MEV is visible onchain, it allows for market-based accountability: Projects that implement mechanisms to minimize harmful MEV — whether through private mempools, encrypted transaction ordering, or incentive-aligned auction design — can be rewarded by the market (that is, users) and can be integrated into application-layer norms.
These features of MEV stand in contrast to prescriptive regulatory interventions, which may risk slowing the evolution of infrastructure or mischaracterizing emergent behaviors. Innovation often arises in response to adversarial conditions, so a policy framework that permits this evolutionary process — rather than prematurely constraining it — is more likely to produce robust, decentralized solutions.
***
Pranav Garimidi is a Research Analyst at a16z Crypto. He does research on problems in mechanism design and algorithmic game theory as it relates to blockchain systems. He is especially focused on how incentives interact across the blockchain stack. Prior to a16z, Pranav was a student at Columbia University where he graduated with a degree in Computer Science.
Joseph Bonneau is an Associate Professor in the Computer Science Department at the Courant Institute, New York University, and a technical adviser to a16z crypto. His research focuses on applied cryptography and blockchain security. He has taught cryptocurrency courses at the University of Melbourne, NYU, Stanford, and Princeton, and received a PhD in computer science from the University of Cambridge and BS/MS degrees from Stanford.
***
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.
The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.
