Markets III: Commodities, Energy and Crypto · Markets

22Maximal Extractable Value

A trader sends a transaction that buys a million dollars of ether from a public pool, accepting up to half a percent of slippage. Before it is included, someone else’s purchase of ether lands in the same block just ahead of it, and a sale of that ether just behind it. The trader receives the least his tolerance allowed; the other party pockets the difference, less what it paid the builder of the block for the privilege of those two positions. Nothing in the exchange was hacked. The value came from the right to order transactions, which on a blockchain belongs to whoever builds the block, and which is bought and sold in a market of its own. This chapter explains that market: where extractable value comes from, the sandwich with its arithmetic, the arbitrages and liquidations that are its benign cousins, the auctions and the separation of roles through which blocks are now built, and the private channels and designs meant to keep traders’ orders out of it.

22.1 Ordering power and extractable value

Definition 22.1 (Maximal extractable value, searcher)

Maximal extractable value (MEV) is the value that can be obtained by including, excluding or reordering transactions in a block beyond the ordinary fees. A searcher is a participant, usually an automated system, that watches pending transactions and the chain’s state for such opportunities and submits transactions to capture them.

The term was introduced as “miner extractable value” by Daian and co-authors, who documented bots that bid up transaction fees against each other in open auctions to be first in line for arbitrage opportunities on decentralised exchanges, likened them to high-frequency traders, and warned that the fees paid for priority posed a risk to the chain’s consensus. The value has three sources. A transaction may create a price discrepancy that someone can trade on (a large swap moves a pool). A change of external prices may create one (an automated market maker’s stale price, Chapter 20). And a protocol may pay whoever acts first (a liquidation bonus, Chapter 23). In each case the value goes to whoever can be first, or around, in the order of a block.

Definition 22.2 (Front-running, back-running)

Front-running is placing a transaction ahead of a known pending one to profit from the price move that the pending one will cause. Back-running is placing a transaction immediately after a known pending one, to capture the opportunity it leaves (an arbitrage, a liquidation) without harming it.

22.2 Front-running and the sandwich

Definition 22.3 (Sandwich attack, slippage tolerance)

A sandwich attack is a front-run and a back-run around a victim’s swap in the same pool: the attacker buys what the victim is buying, the victim buys at the higher price, and the attacker sells after it. The victim’s slippage tolerance is the worst price, expressed as a percentage below the quote at submission, at which it allows its swap to execute; below it, the swap reverts.

**Figure 22.1.** A sandwich attack. The attacker’s two trades bracket the victim’s in the same block; the victim’s slippage tolerance is the only limit on the size of the first. Schematic.

Proposition 22.4 (The tolerance bounds the sandwich)

Let a victim swap $\Delta x$ of token A for token B in a constant-product pool with minimum output $(1 - \tau)$ times the quote at submission. The victim’s output falls as the attacker’s front-run grows, so there is a largest front-run $a^*(\tau)$ that leaves the victim at exactly its minimum; any larger front-run makes the victim’s swap revert and the attack fail. The victim’s loss is at most $\tau$ times its quoted output, and $a^*$ and the attacker’s gross gain grow with $\tau$ . With $\tau = 0$ no sandwich is possible.

Proof. A front-run moves the pool’s price of B up, so the victim’s output (Proposition 20.3) is decreasing in the front-run; the feasible set is an interval $[0, a^*]$ , with $a^*$ increasing in $\tau$ . The victim receives at least its minimum, so it loses at most $\tau$ of its quote. At $\tau = 0$ only a zero front-run is feasible. ∎

Within the feasible interval the attacker’s gain rises with the size of its front-run, so it attacks at the bound: the tutorial finds the bound by binary search, in the pool’s integer arithmetic. For a USD 1 million purchase of ether in a pool holding USD 15 million and 5 000 ether with a 0.30% fee, a tolerance of 0.5% allows a front-run of USD 38 912 and a gross gain of USD 5 067; the victim receives 1.56 ether fewer than its quote, about USD 4 700 at the pool’s starting price. At 1%, the front-run doubles to USD 78 119, the gain to USD 10 130 and the victim’s loss to 3.12 ether.

The sandwich of a USD 1 million purchase of ether in a pool of USD 15 million and 5 000 ether (0.30% fee), at the largest front-run the victim’s tolerance allows (). Both grow linearly with the tolerance. Integer pool arithmetic; illustrative pool. Data: the chapter’s tutorial. — **Figure 22.2.** The sandwich of a USD 1 million purchase of ether in a pool of USD 15 million and 5 000 ether (0.30% fee), at the largest front-run the victim’s tolerance allows (Proposition 22.4). Both grow linearly with the tolerance. Integer pool arithmetic; illustrative pool. Data: the chapter’s tutorial.

The attacker’s gross gain against the size of its front-run for the swap of at a 0.5% tolerance. The gain keeps rising, but beyond USD 38 912 the victim’s swap would revert and the attacker would be left holding ether bought at a premium. Data: the chapter’s tutorial. — **Figure 22.3.** The attacker’s gross gain against the size of its front-run for the swap of Figure 22.2 at a 0.5% tolerance. The gain keeps rising, but beyond USD 38 912 the victim’s swap would revert and the attacker would be left holding ether bought at a premium. Data: the chapter’s tutorial.

The arithmetic tells a trader what to do. Tolerance is an option written to anyone who can order the block; it should be set from the expected price impact of the trade itself plus a small margin, not a round number; large swaps should be split or sent through channels where the order is not public (below).

22.3 Back-running, CEX–DEX arbitrage and liquidation races

Most extracted value does not harm a particular user.

Definition 22.5 (CEX–DEX arbitrage)

CEX–DEX arbitrage is trading an automated market maker’s stale price back to the price on centralised exchanges after they move, usually hedged at once on a centralised exchange, and placed first in the next block.

It is the loss-versus-rebalancing of Chapter 20 seen from the arbitrageur’s side. In the tutorial’s pool, a 1% rise of ether on centralised exchanges lets an arbitrageur buy about USD 52 000 of ether from the pool with a profit of about USD 180 after the pool’s fee; a 2% rise, about USD 127 000 with a profit of about USD 1 070. The profit is a race: whoever’s transaction is first in the block takes it all, and the competition is over the right to be first. Liquidation races are the same race for a lending protocol’s liquidation bonus. Back-running a large swap to arbitrage the pool it has moved is harmless to the swapper, and the private channels below return part of its value to the swapper.

22.4 Gas auctions, proposer–builder separation and bundles

Definition 22.6 (Priority gas auction)

A priority gas auction is the open competition in which searchers bid up the priority fees of transactions in the public mempool, each outbidding the others, to be ordered first for the same opportunity.

Priority gas auctions spam the network with failed and replaced transactions and give the right to order to the block producer, who can also take the opportunity itself. Since Ethereum’s move to proof of stake the market has been organised differently.

Definition 22.7 (Proposer–builder separation, block builder, MEV relay, transaction bundle)

Proposer–builder separation is the division of block production between block builders, specialised parties that assemble the most valuable blocks from public transactions and private bundles and bid for the right to have them proposed, and proposers (validators) that choose the highest bid. An MEV relay is an intermediary that receives builders’ blocks, keeps their contents hidden from the proposer until it commits to propose, and forwards the best bid. A transaction bundle is an ordered list of transactions that a searcher submits to builders, to be included together and in that order, or not at all.

**Figure 22.4.** The supply chain of an Ethereum block under proposer–builder separation: searchers send bundles to builders, builders send blocks and bids to relays, and the proposer signs the most valuable block without seeing its contents first. Private order flow goes straight to builders. Schematic.

As of September 2026 — Proposer–builder separation in practice

Flashbots describes MEV-Boost as open-source middleware run by validators to access a competitive block-building market, its implementation of proposer–builder separation for proof-of-stake Ethereum: builders send blocks to relays, relays forward the most profitable block to the proposer. Testimony in a 2025 criminal trial put the share of validators using MEV-Boost in April 2023 at 95%. Relayscan’s statistics for the 24 hours to 24 September 2026 counted 6 526 blocks delivered through relays, of about 7 200 slots, of which three builders built about 93%; the MEV-Boost dashboard maintained by Toni Wahrstätter put the share of MEV-Boost blocks at 91.58% on the same day, with 7 relays and 25 builders active over fourteen days.

Builders compete in an auction for each slot, and searchers compete for position within builders’ blocks by paying them: in a competitive market a searcher keeps only a small share of an opportunity’s value and pays the rest to the builder, which passes most of it to the proposer. With a 90% payment, the sandwich of the previous section nets its searcher about USD 487 of its USD 5 067, and the builder about USD 4 560. The value extracted from the victim ends mostly with the validator.

The system relies on trust in relays and their code. Prosecutors in New York charged two brothers with exploiting a flaw in MEV-Boost relay software in April 2023: according to the government’s post-trial filing, they baited other searchers’ sandwich bots with transactions, registered validators to obtain a block’s private contents from a relay by submitting an invalid block header, and replaced the bundled transactions to take more than USD 26 million. The trial ended in a mistrial on 7 November 2025 when the jury failed to reach a verdict; the defence then moved for acquittal, a motion argued on 23 March 2026.

22.5 Private order flow, rollup sequencing and mitigations

Definition 22.8 (Private order flow, order-flow auction)

Private order flow is transactions sent directly to builders or through private channels rather than to the public mempool, where searchers cannot see them. An order-flow auction is a mechanism that lets searchers bid for the right to back-run a user’s transaction, returning part of the proceeds to the user, without revealing the transaction in full.

As of September 2026 — A private channel and an order-flow auction

Flashbots Protect sends transactions to a private mempool hidden from front-running and sandwich bots, includes them only if they do not revert, and refunds MEV and priority fees. Its MEV-Share node shares selected information about a user’s transaction with searchers, simulates their bundles and forwards successful ones to builders on condition that the user is paid a specified share of the MEV they create (by default 90%); it accepts only back-runs.

Private channels cut sandwiches but move the trust: the user relies on the channel and the builders it sends to not to exploit the flow themselves, and flow that goes to a few builders concentrates block building further, which is one reason why three builders build most blocks. On rollups, the sequencer (Chapter 14) orders transactions; if it processes them first come, first served and keeps its queue private, there is no public mempool to front-run, and the race moves to latency to the sequencer, as on a centralised venue. The designs of earlier chapters address the same problem from the other side: intent-based routing and batch auctions (Chapter 20) clear orders at one price, so that order within a batch does not matter.

22.6 Tutorial: anatomy of a sandwich

Goal. Given a pool and a victim’s swap with its tolerance, find the attacker’s largest front-run, its profit after gas and the builder’s payment, and the victim’s loss; show that the tolerance bounds both. End state: Figures 22.2 and 22.3 and the numbers of the weekend problem.

The attack. Front-run, victim, back-run, in the pool’s integer arithmetic; binary search for the bound.

def run(ra: int, rb: int, dx_v: int, dx_a: int, fee_bps: int = 30) -> tuple[int, int]:
    """Victim output and attacker gross gain (token A) for a front-run of dx_a."""
    b_a = cp_amount_out(dx_a, ra, rb, fee_bps)
    ra1, rb1 = ra + dx_a, rb - b_a
    b_v = cp_amount_out(dx_v, ra1, rb1, fee_bps)
    ra2, rb2 = ra1 + dx_v, rb1 - b_v
    a_back = cp_amount_out(b_a, rb2, ra2, fee_bps)
    return b_v, a_back - dx_a


def min_out(ra: int, rb: int, dx_v: int, tolerance_bps: int, fee_bps: int = 30) -> int:
    return cp_amount_out(dx_v, ra, rb, fee_bps) * (10_000 - tolerance_bps) // 10_000


def max_front_run(ra: int, rb: int, dx_v: int, tolerance_bps: int, fee_bps: int = 30) -> int:
    """Largest dx_a that still lets the victim's swap execute (binary search: the victim's output falls
    as the front-run grows)."""
    floor = min_out(ra, rb, dx_v, tolerance_bps, fee_bps)
    lo, hi = 0, ra * 10
    while lo < hi:
        mid = (lo + hi + 1) // 2
        if run(ra, rb, dx_v, mid, fee_bps)[0] >= floor:
            lo = mid
        else:
            hi = mid - 1
    return lo


def sandwich(ra: int, rb: int, dx_v: int, tolerance_bps: int, gas_cost: int, builder_share_bps: int,
             fee_bps: int = 30) -> Sandwich:
    """The attack at the largest feasible front-run; the builder is paid a share of the gross gain."""
    dx_a = max_front_run(ra, rb, dx_v, tolerance_bps, fee_bps)
    b_v, gross = run(ra, rb, dx_v, dx_a, fee_bps)
    clean = cp_amount_out(dx_v, ra, rb, fee_bps)
    tip = max(gross, 0) * builder_share_bps // 10_000
    return Sandwich(dx_a, b_v, clean - b_v, gross, gross - gas_cost - tip)

Listing 22.1. The sandwich at the largest feasible front-run. code/firm/sandwich/firm_sandwich.py

Tolerances. by_tolerance() with and without a 90% payment to the builder.

Detection. Find the pattern in a block’s swaps: one sender on both sides of another’s trade in the same pool.

def find_sandwiches(txs: list[tuple[str, str, str]]) -> list[tuple[int, int, int]]:
    """Positions (i, j, k) of sandwich patterns in a block's list of (sender, pool, direction) swaps: the
    same sender trades one way at i and the other way at k in the same pool, around a different sender's
    trade in that pool and direction at j."""
    found = []
    for i, (s, p, d) in enumerate(txs):
        for k in range(i + 2, len(txs)):
            s2, p2, d2 = txs[k]
            if s2 == s and p2 == p and d2 != d:
                for j in range(i + 1, k):
                    if txs[j][0] != s and txs[j][1] == p and txs[j][2] == d:
                        found.append((i, j, k))
                break
    return found

Listing 22.2. Detecting a sandwich in a block’s list of swaps. code/firm/sandwich/firm_sandwich.py

Run cex_dex_arbitrage(3030) and fig_mev.py.

What to change next. Let the victim split its swap in ten across blocks; add a competing searcher who bids for the same sandwich and find the builder’s share at which the attack stops paying; run find_sandwiches on a synthetic block with two overlapping attacks.

22.7 Build: the sandwich simulator

Purpose. The miniature firm swaps on chain as a customer and trades arbitrages as a searcher: it must know what its own transactions expose, set tolerances, price back-runs and detect when it has been sandwiched.

Interface. run(ra, rb, dx_v, dx_a); min_out(ra, rb, dx_v, tolerance_bps); max_front_run; sandwich(ra, rb, dx_v, tolerance_bps, gas_cost, builder_share_bps) returning the front-run, the victim’s output and loss, and gross and net gains; find_sandwiches(txs). Swaps from firm.amm.

Rules. Integer base units and the pool’s exact rounding; the victim’s minimum computed from the quote at submission, as wallets do; the attack refused if the victim would revert.

Acceptance tests. code/firm/sandwich/tests/: the bound is exact to one unit; gain and loss grow with tolerance; a builder’s share lowers the net; zero tolerance leaves nothing; a sandwich detected in a block and not across pools.

Stretch. Concentrated-liquidity pools crossing ticks; multi-pool sandwiches; back-run pricing for an order-flow auction.

Sources and further reading

P. Daian et al., “Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges”, arXiv:1904.05234, 2019.
Flashbots documentation (MEV-Boost, MEV-Share, Flashbots Protect), GitHub repository flashbots/flashbots-docs, September 2026; relayscan.io and mevboost.pics, 24 September 2026.
United States v. Peraire-Bueno, No. 1:24-cr-00293 (S.D.N.Y.): government’s memorandum of 16 January 2026 (Doc 236) and the docket’s declaration of mistrial of 7 November 2025; joint motion for acquittal (Doc 225, 12 December 2025); order setting oral argument (Doc 240).

22.8 Exercises

Exercise 22.1 ★

Why can no one sandwich a swap sent with zero slippage tolerance, and why do wallets not default to zero?

Solution

Solution of Exercise 22.1.

Any front-run lowers the victim’s output below the quote, so the swap would revert and the attacker would be left with its front-run position. Wallets allow some tolerance because the pool can move for innocent reasons between submission and inclusion (other trades, arbitrage), and a zero-tolerance swap would often fail.

Exercise 22.2 ★

Classify as front-running, back-running or neither: a liquidation of an undercollateralised loan placed right after an oracle update; an arbitrage placed right after a large swap; a purchase placed right before a large purchase.

Solution

Solution of Exercise 22.2.

The liquidation after an oracle update is a back-run; the arbitrage after a large swap is a back-run; the purchase before a large purchase is a front-run.

Exercise 22.3 ★

What does an MEV relay guarantee the builder, and what does it guarantee the proposer?

Solution

Solution of Exercise 22.3.

To the builder: the proposer cannot see or change the block’s transactions before committing to propose it. To the proposer: the bid it accepts is valid and will be paid if it proposes the block.

Exercise 22.4 ★★

The victim’s tolerance doubles from 0.5% to 1%. By how much do the attacker’s gross gain and the victim’s loss change?

Solution

Solution of Exercise 22.4.

Both double: USD 5 067 to 10 130 of gross gain, and 1.56 to 3.12 ether of loss.

Exercise 22.5 ★★

A searcher pays the builder 90% of the gross gain and USD 20 of gas. What does it net on the 1% sandwich?

Solution

Solution of Exercise 22.5.

$10\,129.57 \times 10\% - 20 =$ USD 992.96.

Exercise 22.6 ★★

Why does private order flow tend to concentrate block building?

Solution

Solution of Exercise 22.6.

Channels send flow to the builders they trust or are paid by; the builders with most private flow can build the most valuable blocks, win more auctions, and attract more flow, a feedback loop.

Exercise 22.7 ★★★

Coding. With cex_dex_arbitrage, find the smallest centralised price rise that makes the arbitrage worth USD 20 of gas.

Solution

Solution of Exercise 22.7.

A rise of about 0.54% (to 3 016.20): the arbitrage buys about USD 17 900 of ether for a profit of about USD 21. Below the pool’s 0.30% fee there is no arbitrage at all.

Exercise 22.8 ★★★

Find the flaw. “We send our swaps through a private channel, so we pay no MEV.”

Solution

Solution of Exercise 22.8.

The channel prevents sandwiches but the swap still moves the pool, whose back-run value is shared or kept by the channel and builders; priority fees and the channel’s own terms are costs; and the trader trusts the channel and its builders not to use the flow. MEV exposure is reduced and moved, not removed.

22.9 Problem: Anatomy of a Sandwich

Problem 22.1

Weekend problem — a USD 1 million swap and the searcher who saw it

A trader buys ether with USD 1 million in a constant-product pool holding USD 15 million and 5 000 ether with a 0.30% fee, through the public mempool. A searcher’s two transactions cost USD 20 of gas.

Part I — The quote.

How much ether does the quote promise, and what is the swap’s own price impact?
What is the trader’s minimum output at 0.5% tolerance? At 1%?
What is the largest front-run at each tolerance?
Why is that the searcher’s best choice?
What would the searcher do at 0% tolerance?

Part II — The profit.

What is the searcher’s gross gain at each tolerance?
What does the trader lose, in ether and at 3 000 dollars per ether?
What does the searcher net if it pays the builder nothing? If it pays 90%?
Who ends up with most of the value?
Why does a competitive builder market push the searcher’s share towards zero?

Part III — Defences.

What tolerance would you set for this swap, and why?
What would splitting the swap in ten across ten blocks change?
What would a private channel change, and what would it not?
How would an intent or a batch auction change the outcome?
How would you detect after the fact that the swap was sandwiched?

Part IV — Judgement.

Is a sandwich front-running in the sense of the market-abuse rules that bind brokers in regulated markets?
Why are back-runs and CEX–DEX arbitrage treated differently from sandwiches?
What does the 2023 relay exploit show about the block-building supply chain?
State the named result: the searcher’s maximal net profit and the trader’s loss at 0.5% and 1% tolerance.
In one sentence: what is a slippage tolerance?

Solution

Solution of Problem 22.1.

1. 311.62 ether, an average of 3 209.03 dollars: about 7% above the pool’s price, of which 0.30% is the fee and the rest the swap’s own impact. 2. 310.06 and 308.50 ether. 3. USD 38 912 and 78 119. 4. Its gain rises with the front-run up to the point where the victim would revert. 5. Nothing: no front-run is feasible. 6. USD 5 067 and 10 130. 7. 1.56 and 3.12 ether, about USD 4 674 and 9 349 at 3 000. 8. USD 5 046.72 and 10 109.57 with no payment; USD 486.67 and 992.96 paying 90%. 9. The builder, and through its bid the proposing validator. 10. Every searcher who sees the same opportunity bids for it; the highest bid approaches the whole value. 11. Just above the swap’s expected slippage from other trades before inclusion, a few basis points, or send it privately; 0.5% is a gift of up to USD 4 700. 12. Each piece moves the pool less, so each tolerance can be tighter and each sandwich smaller; the trader bears price risk across blocks and ten times the gas. 13. It hides the swap from public searchers and can refund back-run value; it does not remove the price impact or the trust in the channel. 14. Solvers or fillers compete to fill at one price, and within a batch the order does not matter; the trader’s worst price is still its signed limit. 15. Look in the block for the same address buying the same token just before and selling just after, in the same pool (find_sandwiches), and compare the fill with the quote. 16. It exploits knowledge of a pending order to trade ahead of it, which is the substance of front-running, but the attacker owes the victim no duty as a broker does; whether it is illegal depends on jurisdiction and facts, and it is contested. 17. They trade on information that is public after the transaction and do not worsen the user’s price; they correct prices. 18. That the separation of roles depends on software that can have flaws, and that participants who control validators can exploit them; trust has moved to relays and their code. 19. Named result: USD 5 046.72 net and 1.56 ether lost at 0.5%; USD 10 109.57 net and 3.12 ether lost at 1%. 20. A written option on the swap’s price, exercisable by whoever orders the block.

22.10 Interview questions

Interview question 22.1 ★ trader

What is a sandwich attack and how do you protect your swaps from it?

Solution

Solution of Interview question 22.1.

A buy before and a sell after a victim’s swap in the same pool, bounded by the victim’s slippage tolerance. Protect by tight tolerances, private channels, splitting large swaps, and intent or batch mechanisms.

What the interviewer is looking for: tolerance as the bound, and private flow.

Interview question 22.2 ★ developer

Explain proposer–builder separation and the role of relays.

Solution

Solution of Interview question 22.2.

Builders assemble blocks and bid for inclusion; proposers pick the highest bid without seeing contents; relays hold the block contents until the proposer commits (a commit-and-reveal) and check bids, so that neither side can cheat the other.

What the interviewer is looking for: the commit and reveal and who trusts whom.

Interview question 22.3 ★★ researcher

Derive the largest front-run a victim’s tolerance allows in a constant-product pool.

Solution

Solution of Interview question 22.3.

The victim’s output falls with the front-run; set the output after a front-run $a$ equal to $(1 - \tau)$ times the quote and solve for $a$ (in closed form for the constant product, or by binary search in integer arithmetic).

What the interviewer is looking for: monotonicity and the binding constraint.

Interview question 22.4 ★★ trader, researcher

How is CEX–DEX arbitrage related to a pool’s loss-versus-rebalancing?

Solution

Solution of Interview question 22.4.

It is the same flow seen from two sides: the arbitrageur’s profit from trading the stale pool to the external price is the pool’s loss to rebalancing, net of the fee.

What the interviewer is looking for: the arbitrageur’s gain equals the pool’s loss.

Interview question 22.5 ★★ risk

What risks does a firm running searchers take, operationally and legally?

Solution

Solution of Interview question 22.5.

Operational: bugs in bundles that lose money, key management, dependence on relays and builders, reverted transactions and gas. Legal: strategies that harm users (sandwiches) may be treated as fraud or market manipulation; validators or exploits of infrastructure bring criminal exposure, as the 2023 relay case shows.

What the interviewer is looking for: separation of benign back-running from harmful strategies.

Interview question 22.6 ★★★ developer, researcher

Design an order-flow auction that returns value to users without leaking their trades.

Solution

Solution of Interview question 22.6.

Users send transactions to a trusted node that reveals only hints (pool, direction, not size or limit); searchers bid for the right to back-run with bundles the node simulates; the node forwards the best bundle with the condition that the user is paid a stated share, and only back-runs are accepted. Harden with sealed bids, several builders and audits.

What the interviewer is looking for: hints not orders, back-runs only, and payment conditions.

Terms defined in this chapter

See all 2333 terms in the glossary