MEV: Front-running, Sandwiching & PBS

Every attack in this part so far shared a premise: some contract was wrong. Reentrancy let control escape mid-call; integer overflow wrapped a balance; the Parity multisig forgot to guard a function; oracle manipulation trusted a price an attacker could bend. Fix the code, close the hole.

This page is different, and it is the reason the security overview split its threat model into two families. Here no contract is buggy. The victim’s trade does exactly what the victim wrote it to do. The loss comes from a rule of the state machine itself: transactions are public before they are final, and whoever assembles the block gets to choose which ones go in and in what order. That power to order is not a side effect. It is money. This page names it, shows how it is extracted, and traces how Ethereum’s plumbing — the public mempool, then Flashbots, then proposer-builder separation after the Merge — reshaped who captures it and at whose expense.

Ordering is a resource

Recall the mental model from the account model: a block is a sequence of transactions, applied one after another to the world state, each one seeing the state the previous one left behind. Order is not cosmetic. Run tx A then tx B and you get one world; run B then A and you can get a different one. On a market, a different world means a different price.

The block producer — a miner under proof-of-work, a proposer/validator since the Merge — has a free hand within a block. Nothing in the protocol says transactions must be ordered by arrival time. The producer may include any valid transactions it likes, in any order, and drop the rest. Historically it sorted by fee to maximize revenue, but nothing forces even that.

MEV — originally Miner Extractable Value, now usually read as Maximal Extractable Value to cover the post-Merge world — is the name for the profit a block producer (or anyone who can influence ordering) can capture purely by choosing which transactions to include and in what order, beyond the ordinary block reward and fees. It is value that exists because the right to sequence a block is itself worth something.

   the same two transactions, two orders, two worlds:

   order 1:  [victim buys DAI]  → then → [you buy DAI]     you paid the higher price
   order 2:  [you buy DAI]      → then → [victim buys DAI]  you bought first, cheaper

   the producer chooses. that choice is worth money. that is MEV.

The uncomfortable part: MEV is not a bug to be patched. It is an emergent property of any system where an ordering agent sees pending transactions before finalizing them. You cannot delete it by writing better contracts. You can only decide who captures it, how the competition for it is run, and how much of it comes out of ordinary users’ pockets.

Front-running: acting on what you can see

The raw ingredient is the public mempool. When you broadcast a transaction, it does not go straight into a block — it sits in a shared, gossip-propagated pool of pending transactions, visible to every node on Earth, for seconds, while it waits to be picked up. Anyone watching can read exactly what you are about to do before it happens.

Front-running is trading on that foresight. You see a pending transaction that will move a price — say a large swap on a decentralized exchange — and you insert your own transaction to execute first, profiting from the price move you know is coming.

   mempool (public):   [victim: swap 1000 ETH → USDC]   ← visible, not yet in a block

   front-run:  attacker sees it, submits [attacker: buy USDC] with a HIGHER priority fee
               → producer orders attacker BEFORE victim
               → attacker buys cheap, victim's big swap pushes the price up,
                 attacker now holds USDC that is worth more

The lever is the fee. Under a fee market (see EIP-1559), a higher priority fee buys earlier placement, because a revenue-maximizing producer orders by what it earns. So “get in front of that transaction” reduces to “outbid its priority fee.” The victim did nothing wrong; they simply announced their intent in public and gave a faster, richer adversary time to react.

Sandwiching: front-run and back-run the same victim

The industrial form of front-running is the sandwich. Instead of one transaction, the attacker wraps the victim’s swap in two of their own — a buy before and a sell after — and pockets the difference the victim’s own trade creates.

   attacker's block, in order:

   ┌──────────────────────────────────────────────────────────┐
   │ 1. attacker BUYS the asset  → pushes price up a little     │  the front slice
   │ 2. victim's SWAP executes   → pushes price up more,        │  the filling
   │        and fills at this now-worse price (their slippage)  │
   │ 3. attacker SELLS the asset → back into the price the      │  the back slice
   │        victim just lifted, at a profit                     │
   └──────────────────────────────────────────────────────────┘

Every automated market maker moves price along a curve as you trade against it: a buy makes the next buy more expensive. The victim protects themselves by setting a slippage tolerance — “fill my swap only if the price is within X% of what I quoted.” The sandwich attacker’s entire craft is to buy just enough in slice 1 to push the victim right up to the edge of that tolerance, so the victim’s swap still succeeds (a reverted victim tx earns the attacker nothing) but fills at the worst price they were willing to accept. Slice 3 then sells into the bump the victim created. The victim’s loss is exactly the slippage they authorized — skimmed by a stranger who did no trading of their own beyond bracketing them.

This is why the oracle-manipulation page and this one are cousins: both weaponize the fact that a price is a function of transaction order within a block. There the attacker bent a price a contract read; here they bend a price a user trades against. Same lever, different victim.

It actually happened — the “dark forest” and a rescue gone wrong

In August 2020, researchers Dan Robinson and Georgios Konstantopoulos published “Ethereum is a Dark Forest,” describing the mempool as a place where predatory bots devour any profitable transaction the instant it appears. Their proof was painful: attempting to rescue funds from a vulnerable contract, they broadcast a recovery transaction — and a generalized front-running bot, which blindly copies any transaction that looks profitable, saw it in the mempool, replayed it with a higher fee, and captured the funds they were trying to save. Weeks later, in “Escaping the Dark Forest” (September 2020), samczsun described extracting funds from another vulnerable contract only by never touching the public mempool — by submitting the transaction privately, straight to a miner, so no bot could see and copy it. The lesson landed hard: on a public mempool, broadcasting your intent is itself the vulnerability. Private orderflow was not a convenience; it was survival.

The pre-Flashbots dark forest: gas wars

Before there was any structured market for ordering, MEV competition happened in the open, and it was ugly. Multiple bots would spot the same profitable pending transaction — a liquidation, an arbitrage, a sandwich target — and race to be the one whose transaction landed first. The only lever was the gas price, so they bid it up against each other in real time. These were Priority Gas Auctions (PGAs).

   one profitable opportunity, five bots that all see it:

   bot A: 50 gwei → bot B: 55 → bot A: 120 → bot C: 200 → bot B: 260 → ...
                                    (all racing for ONE prize; four will lose)

   result: the winning bot overpays; the FOUR losing bids still hit the chain,
           congesting the network and burning gas on transactions that revert.

This was wasteful on every axis. The winner bid away most of its profit to the miner. The losers spent real gas on transactions that failed or reverted — pure deadweight loss. And the bidding storms congested the whole chain and drove up fees for everyone, including ordinary users who had nothing to do with the auction. Worse, because ordering was ultimately at the miner’s discretion, the whole thing invited chain reorganizations: a miner tempted by a fat MEV opportunity in an already-mined block had an incentive to re-mine it, threatening the stability of the chain itself. The extraction was inefficient and it leaked out and harmed consensus.

Flashbots: a sealed-bid auction off the public mempool

Flashbots, launched in 2020, reframed the problem. If MEV is going to be extracted anyway, the argument went, at least run the competition somewhere that does not spill gas wars onto the public chain — and let the value be discovered by a clean auction instead of a screaming match.

The core idea is private orderflow plus bundles. Instead of broadcasting to the public mempool, a searcher (a bot hunting MEV) sends a bundle — an ordered list of transactions it wants included together, in exactly this order, or not at all — directly to a relay, along with a bid (a payment to the block producer). The producer runs a sealed-bid auction: it receives many private bundles, simulates each, and picks the combination that pays it the most, without any of it ever touching the public mempool.

   pre-Flashbots (public gas war)        Flashbots (private sealed-bid auction)
   ────────────────────────────────      ──────────────────────────────────────
   bots shout bids in the mempool        searchers send sealed BUNDLES to a relay
   losing bids congest the chain         losing bids are never broadcast → no waste
   miner orders by public gas price      producer picks the highest-paying bundle set
   reverted txs still cost gas           bundles are all-or-nothing: no on-chain revert

What this bought:

• No wasted gas. Losing bids never hit the chain, so the four-bots-lose deadweight of PGAs vanished. Bundles either land whole or are silently dropped.
• Atomic, all-or-nothing bundles. A searcher can express “these three transactions, in this order, or none” — perfect for a sandwich or an arbitrage that only works as a set. No half-executed exploit stuck on-chain.
• Less congestion, cheaper for bystanders. Taking the auction off the public mempool removed the gas-war storms that had been inflating fees for uninvolved users.
• A cleaner split of the money. The sealed bid surfaces the true value of the opportunity and routes it to the block producer as an explicit payment, rather than it evaporating into overpaid public gas.

Flashbots did not end MEV, and it did not stop sandwiching victims — a private auction can order a sandwich just as happily as a public gas war could. What it did was make the extraction machinery efficient and move it out of everyone else’s way. That is the honest framing: a fairer, less wasteful market for a thing that was never going to disappear.

Proposer-builder separation and MEV-Boost

The Merge introduced a deeper structural change to who does the ordering. Under proof-of-stake, the party who gets to propose a block is a randomly chosen validator (see validators and staking) — often a hobbyist running a node at home on a Raspberry Pi. Building a maximally profitable block, by contrast, is a specialized, capital-intensive, latency-sensitive craft: you need to ingest every bundle, simulate thousands of orderings, and win a sealed-bid auction in milliseconds. Asking a home validator to also be a world-class MEV extractor would hand all the rewards to the biggest, best-connected operators and centralize staking.

Proposer-builder separation (PBS) splits the job in two:

   BUILDERS                          PROPOSER (validator)
   ─────────────────────────────     ───────────────────────────────────────
   specialized firms that assemble   the randomly-chosen home validator that
   the most profitable block body    signs and PROPOSES the block to the chain
   from searchers' bundles

        builder builds ──── bids for its block ────►  relay  ────►  proposer
        (WHO ORDERS the txs)                                        (WHO PROPOSES it)

• Builders compete to assemble the most valuable block body from searchers’ bundles and public transactions. This is the ordering job — the MEV extraction — done by specialists.
• Proposers (validators) do not build. They receive complete, pre-built block bodies from builders (via a relay that holds the block until the proposer commits), pick the one that pays them the most, and simply sign and propose it. They never see the transactions until after they have committed to include the block — which protects them from stealing the builder’s MEV.

In practice this is delivered by MEV-Boost, optional middleware from Flashbots that a validator runs alongside its consensus client. MEV-Boost turns the validator into an auctioneer: it polls relays, collects sealed bids for full blocks from competing builders, and hands the validator the highest-paying header to sign. A large majority of Ethereum validators run it, because a validator that builds its own block by hand earns less than one that auctions the slot to professional builders. The clean sentence: PBS separates who orders transactions from who proposes the block — and lets small validators earn near the MEV frontier without becoming MEV experts.

By the numbers — why a home validator opts in to MEV-Boost

The pull is pure economics. Consider one slot, with round, illustrative figures:

   validator builds its own block:     0.04 ETH  (ordinary priority fees only)
   validator auctions slot via relay:  0.11 ETH  (a builder's winning bid, which
                                                   already includes the MEV it captured)

   difference per profitable slot ≈ 0.07 ETH — for running one extra process.

A solo staker who runs MEV-Boost captures a share of MEV they could never have extracted themselves; one who refuses simply leaves that money on the table. Multiplied across a year of slots, the gap is large enough that opting out is a meaningful sacrifice — which is exactly why adoption is so high, and exactly why builder concentration becomes a systemic concern. (Figures are illustrative and vary enormously slot to slot; the mechanism — outsourcing beats self-building — is the durable point.)

Under the hood — the trust seam is the relay

PBS has a subtle chicken-and-egg problem, and its solution reveals where the real power (and risk) sits. The proposer wants to see the block before signing, to be sure it is valid and pays what was promised. The builder refuses to reveal the block before the proposer commits to it — otherwise the proposer could copy the profitable ordering and propose it themselves, stealing the builder’s MEV.

The relay resolves the standoff as a trusted intermediary: the builder sends the full block to the relay; the relay shows the proposer only a header plus a promised payment; the proposer signs that header (committing to it) and only then does the relay release the full body. Neither side can cheat the other — but both must trust the relay. That is the seam. A relay can, in principle, censor transactions (refuse to relay blocks containing certain addresses), and because a handful of builders and relays win most blocks, that power is concentrated. The efficiency of PBS is real; so is the fact that it created a small number of chokepoints that a censor could lean on.

The trade-offs: efficiency bought with new centralization

Hold the whole arc in view. MEV cannot be deleted; it is intrinsic to any orderable, publicly-visible sequence of transactions. So the honest question is never “how do we remove it?” but “who captures it, how fairly, and at what collateral cost?” Each step traded one problem for another:

   dark forest (PGAs)     Flashbots (private auction)     PBS + MEV-Boost (post-Merge)
   ───────────────────    ───────────────────────────    ───────────────────────────────
   + fully permissionless + efficient, no wasted gas      + small validators earn MEV
   + no privileged relay   + no chain congestion            without being MEV experts
   − gas wars, congestion  + reorg incentive reduced       + slot auction, clean split
   − reverted-tx waste    − relies on a private relay      − builder/relay CONCENTRATION
   − reorg incentives     − still sandwiches users         − CENSORSHIP chokepoints
                                                           − user sandwiching UNSOLVED

Two harms survive every version and deserve naming plainly:

• User harm. Sandwiching still comes straight out of ordinary users’ slippage. Private auctions made extraction tidier, not gentler. The main user defenses are tight slippage limits and using private transaction submission (sending your swap straight to a builder so it never appears in the public mempool for a sandwicher to spot) — the direct descendant of samczsun’s dark-forest escape.
• Centralization and censorship. Concentrating block-building in a few professional builders and relays creates chokepoints. If most blocks flow through a small set of relays, and those relays choose to exclude certain transactions (for example, to comply with a sanctions list), the chain’s credible neutrality — the property that makes it useful to untrusting strangers at all — is at stake. This is an active area of research (proposals like enshrined PBS and inclusion lists aim to force builders to include censored transactions), and as of 2024 it remains unsettled.

That last point is where MEV rejoins the book’s throughline. A world computer is only worth trusting if it will process your transaction whether or not the powerful want it processed. MEV, and the block-building market that grew up around it, is the place where that neutrality is quietly bargained over — one slot at a time.

The architect’s lens

MEV-Boost and proposer-builder separation are the major technology this page introduces, so we run the lens on them.

• Why does it exist? Because building a maximally profitable block is a specialist, latency-and-capital-intensive craft, but proposing a block under proof-of-stake falls to a randomly chosen, often-amateur validator. Without separation, all the MEV rewards would flow to whoever could also afford to be an elite builder — centralizing staking around the few who can.
• What problem does it solve? It lets a home validator capture near-frontier MEV by auctioning its slot to professional builders instead of building by hand, while keeping the roles of ordering (builder) and proposing (validator) cleanly separate. It also moves MEV competition into an efficient sealed-bid auction, killing the gas wars of the dark forest.
• What are the trade-offs? Efficiency and small-validator income, bought with concentration: a handful of builders and relays win most blocks, creating censorship chokepoints and a relay you must trust. It makes extraction tidy but does nothing to stop users being sandwiched.
• When should I avoid it? As a solo staker, you might run without MEV-Boost — accepting lower rewards — if you value maximal decentralization, want to build censorship-resistant blocks yourself, or refuse to trust any relay. As a user, avoid the public mempool entirely for sensitive swaps; submit privately.
• What breaks if I remove it? Take away PBS and MEV extraction reverts to public gas wars (congestion, reorg incentives) and centralizes staking, because only large, sophisticated validators could then compete for MEV. The chain would be both messier and less decentralized — the opposite of the goal.

Check your understanding

1. The pages before this one all fixed a bug in a contract. Explain precisely why MEV is a different kind of problem, and why “write correct contract code” does not remove it.
2. Walk through a sandwich attack transaction by transaction. Why must the attacker be careful not to push the victim past their slippage tolerance, and where does the victim’s exact loss come from?
3. What were Priority Gas Auctions, and name two concrete harms they inflicted on the chain beyond the participants in the auction.
4. What two things did Flashbots change about how MEV is captured, and why does the phrase “Flashbots did not end MEV” matter? What harm survived it?
5. State what proposer-builder separation separates, and explain the relay’s role and why it is the point where censorship risk concentrates.

Show answers

1. In every earlier case the contract’s code did something it should not have; the fix was correct code. MEV involves no buggy contract — the victim’s transaction does exactly what it was written to do. The loss comes from a rule of the protocol: transactions are public before they are final, and whoever assembles the block chooses which ones are included and in what order. That ordering power is intrinsic to any orderable, publicly-visible sequence of transactions, so no amount of correct contract code can delete it — you can only change who captures it and how the competition is run.
2. (1) The attacker buys the asset just before the victim, nudging the price up. (2) The victim’s swap executes into that raised price and pushes it up further, filling at a worse price — their slippage. (3) The attacker sells back into the bump at a profit. The attacker must not push the victim past their slippage tolerance, because a swap that exceeds tolerance reverts and the attacker earns nothing; the craft is to lift the price to just the edge of what the victim authorized. The victim’s loss is exactly the slippage they set as acceptable — skimmed by a stranger who only bracketed them.
3. Priority Gas Auctions (PGAs) were open bidding wars in the public mempool: multiple bots chasing the same profitable pending transaction bid the gas price up against each other in real time. Beyond the bidders, they (a) congested the whole chain and raised fees for uninvolved users, and (b) created reorg incentives — a miner tempted by MEV in an already-mined block had reason to re-mine it, threatening chain stability. (Also acceptable: losing bids wasted gas on reverted transactions — deadweight loss.)
4. Flashbots moved MEV competition to (a) private orderflow — searchers send sealed bundles to a relay instead of broadcasting to the public mempool — and (b) a sealed-bid auction where the block producer picks the highest-paying combination of bundles. “Flashbots did not end MEV” matters because a private auction can order a sandwich just as easily as a public gas war could; it made extraction efficient and out of everyone’s way, not gentler. The surviving harm is user sandwiching — victims still lose their slippage.
5. PBS separates who orders the transactions (the builder) from who proposes the block (the validator/proposer). The relay is the trusted intermediary that lets the builder reveal only a block header plus a promised payment; the proposer signs that header (committing) before the relay releases the full body, so neither side can cheat the other. It concentrates censorship risk because a small number of relays and builders win most blocks, and a relay can refuse to relay blocks containing certain transactions — putting the chain’s credible neutrality in a few hands.