Quant Memo
Core

MEV and Sandwich Attacks

Whoever controls the order of transactions in a block can insert their own trades around yours, and a sandwich attack is the cleanest example: buy right before you, sell right after.

Prerequisites: Automated Market Makers, Transaction Lifecycle: From Mempool to Block

In a traditional exchange, orders are matched in a queue nobody outside the exchange can rearrange. On a blockchain, every pending transaction sits visibly in a public waiting room called the mempool before anyone assembles them into a block — and whoever assembles that block gets to choose the order. That power to reorder, insert, or drop transactions before they settle is called MEV, maximal extractable value, and it is worth billions of dollars a year across Ethereum and similar chains.

MEV is the profit available from controlling transaction order. A sandwich attack is the simplest form: see a trade about to move the price, buy just ahead of it, let the victim's trade push the price further, then sell into that price for a guaranteed profit.

How a sandwich actually works

Suppose a trader submits a transaction to buy a large amount of a token on a decentralized exchange (DEX). Because DEXs price trades using an automated market maker curve, a large buy pushes the price up as it executes — the bigger the trade relative to the pool, the worse the price the trader gets on the tail end of their own order. That predictable price impact is the opening a searcher exploits.

A searcher — a bot watching the mempool — spots the pending buy, estimates how much it will move the price, and races to get two transactions of its own included around it in the same block:

  1. Front-run: buy the token right before the victim's transaction, at the pre-impact price.
  2. Victim's trade executes, pushing the price up further, exactly as it would have anyway.
  3. Back-run: sell the token right after, at the now-higher price.
block order (left to right) searcher buys victim's buy searcher sells price
The searcher's two trades bracket the victim's — buying low before impact, selling high after it — profiting purely off the price move the victim's own order caused.

The victim pays the full price impact of their trade twice over: once from their own order size, and again because the searcher's front-run already consumed some of the pool's liquidity before the victim's trade even landed, worsening the price the victim receives.

Worked example

A trader submits a buy for a token trading at $10.00, expecting to pay up to $10.20 for the size involved (a 2% slippage tolerance they set as protection). A searcher sees this pending order and buys $50,000 of the token first, pushing the price from $10.00 to $10.08. The victim's trade then executes against this new, higher starting price, pushing it further to $10.19 — just inside their slippage tolerance, so the trade does not revert. The searcher immediately sells the $50,000 position into that elevated price, capturing roughly the $0.08–$0.11 per-token spread they engineered, minus gas fees paid to get both transactions positioned correctly around the victim's.

What this means in practice

Sandwich attacks are why DEX traders set slippage tolerances, and why that tolerance is itself a trade-off: too tight and ordinary price movement causes failed transactions; too loose and it becomes exactly the room a sandwich needs to operate in. The rise of proposer-builder separation, where specialized builders compete to construct the most valuable block and pay the block proposer for the right to do so, has turned MEV extraction into a formal, auctioned marketplace rather than a free-for-all of competing bots. Some infrastructure now offers "private" transaction routes that skip the public mempool entirely, denying searchers the visibility a sandwich requires.

MEV is not something you avoid by using a "trusted" exchange — it is a structural feature of any system where transaction ordering is decided after transactions are visible. The fix has to happen at the ordering layer (private mempools, batch auctions, encrypted transactions) or through execution protections (tight slippage limits, splitting large orders), not by picking a different DEX.

Related concepts

Practice in interviews

Further reading

  • Daian et al., 'Flash Boys 2.0: Frontrunning in Decentralized Exchanges'
ShareTwitterLinkedIn