Sandwich attacks and MEV
A sandwich attack places one transaction immediately before a victim's pending swap and another immediately after it, moving the pool price so that the victim trades at a worse rate and the attacker keeps the difference.
How does a sandwich attack work?
Two design properties of most blockchains, each sensible in isolation, combine into an exploit.
Pending transactions are public. Before a transaction is included in a block it sits in a queue that anyone can read. This is necessary — validators need to see transactions in order to process them — and it means everyone can see what everyone is about to do.
Ordering can be purchased. Whoever builds a block decides what goes in and in what sequence, and that decision is sold. Priority fees, and increasingly direct arrangements with specialised block builders, determine placement.
Put them together and a pending swap becomes a target.
-
Observe the victim’s transaction. A swap of a known size, against a known pool, with a known slippage tolerance — the worst price the swap will accept before reverting.
-
Buy first. Place a transaction ordered immediately before it, moving the pool price against the victim’s direction. Because the pool prices by formula, the effect is exactly computable in advance.
-
The victim executes at the worse price, up to the limit their slippage tolerance permits.
-
Sell immediately after. Ordered directly behind the victim, unwinding the position into the price the victim’s own trade created.
The attacker’s two transactions are pointless without the one between them. They are pure round trip, economically meaningless in isolation, and profitable only because the victim’s trade sits in the middle.
The extraction is bounded exactly by the slippage tolerance. A user who leaves it at a permissive default has, in effect, specified how much they are willing to lose.
A worked example with real numbers
A pool holding 1,200 ETH against 3,600,000 USDC, so ETH prices at about $3,000. A user submits a swap of 60,000 USDC into ETH with slippage tolerance set to 2%.
Without interference.
Pool: 1,200 ETH · 3,600,000 USDC (constant product k = 4.32e9)
Swap in 60,000 USDC (0.3% fee → 59,820 effective)
ETH out ≈ 1,200 − (4.32e9 / 3,659,820) ≈ 19.61 ETH
Effective price ≈ $3,060
The attack. The attacker front-runs with 220,000 USDC.
After attacker's buy: 1,131.6 ETH · 3,819,340 USDC (price ≈ $3,375)
Victim's 60,000 USDC now buys ≈ 17.51 ETH
Effective price ≈ $3,427
The victim’s slippage tolerance of 2% would have reverted the trade at anything worse than about $3,121 — but tolerance is measured against the price quoted at submission, and interfaces frequently quote conservatively, so a 2% setting on a volatile pair leaves substantially more room than the user imagines.
The attacker’s back-run.
Sells the ETH acquired, into the price the victim's trade created
Gross gain ≈ $4,180
Pool fees paid ≈ $1,320
Priority fee bid ≈ $2,400
Net to attacker ≈ $460
Where the money went.
Victim's loss ≈ $6,300 (2.10 ETH of shortfall)
To the attacker ≈ $460
To liquidity providers as fees ≈ $1,320
To the block builder as priority fee ≈ $2,400
Unrecovered slippage ≈ $2,120
This distribution is the most instructive part of the example. The attacker keeps roughly seven per cent of what the victim lost. Competition between extractors bids the priority fee up to nearly the full available profit, so the majority flows to whoever orders the block.
The economic consequence is that this is not primarily a transfer from users to attackers. It is a transfer from users to the infrastructure that sequences transactions — which is a structural observation about how these systems distribute value, not a moral one.
Why is the legal position unsettled?
This is the hardest legal question on the site, and pretending otherwise would be misleading.
Traditional front running requires a duty. A broker who trades ahead of a customer order breaches an obligation to that customer — the customer entrusted them with the order, and best execution follows from that relationship. That is what makes it unlawful.
None of those elements exists here. There is no broker. There is no customer. The victim did not entrust anything to the attacker. The information was not confidential; it was broadcast to the world by the victim’s own software. And the ordering was not stolen; it was bought at a published price through the mechanism the network provides for exactly that purpose.
The available theories are correspondingly awkward.
Wire fraud requires a scheme to obtain money by materially false pretences. The difficulty is identifying the false pretence. The attacker made no representation to the victim, and arguably made none to anyone.
CFTC Rule 180.1 reaches manipulative and deceptive devices in commodity markets, and moving a pool price to disadvantage a specific counterparty is manipulation in ordinary usage. Whether spot token swaps fall within the CFTC’s authority is contested.
The Computer Fraud and Abuse Act fits poorly, since nothing was accessed without authorisation.
Where prosecutions have succeeded, they have generally involved something more than ordinary sandwiching: deceiving the systems that order transactions, or exploiting block-building infrastructure through misrepresentation. That extra element — a deception of the sequencing mechanism rather than of the victim — is what has supplied the fraud.
Ordinary sandwiching against public transactions has largely not been charged, and this site does not claim it is settled that it is unlawful. It is extraction that is entirely visible, permanently recorded, and legally ambiguous, which is an unusual combination.
The practical response has been technical rather than legal: private transaction relays that bypass the public queue, batch auctions that remove the ordering advantage, and interfaces that default to tighter slippage settings.
| Provision | Citation | Primary text |
|---|---|---|
| Wire fraud | 18 U.S.C. § 1343 | Read the text |
| CFTC Rule 180.1 — fraud-based manipulation | 17 C.F.R. § 180.1 | Read the text |
| SEC Rule 10b-5 | 17 C.F.R. § 240.10b-5 | Read the text |
| Computer Fraud and Abuse Act | 18 U.S.C. § 1030 | Read the text |
How are sandwich attacks detected?
Detection is trivial. Every transaction is public and permanent, and the pattern is unmistakable.
Block-level pattern matching. Three transactions against one pool in one block, where the first and third share an address and run in opposite directions. This is mechanically identifiable and several public dashboards do it continuously.
Economic pointlessness testing. Whether the bracketing transactions would make sense without the middle one. A round trip that loses money on its own is not a trade.
Priority fee analysis. Fees calibrated precisely to the profit available from a specific victim transaction, which indicates the extractor computed the opportunity before bidding.
Address clustering. Repeat extractors are visible across thousands of instances.
Order flow arrangements. Whether an operator had privileged sight of transactions before they were public, which is the element most likely to convert extraction into an offence.
- Three transactions in one block against the same pool, where the first and third are the same address in opposite directions.
- The bracketing transactions being economically pointless without the victim's transaction between them.
- Priority fees paid by the attacker that are calibrated to the profit available from the specific victim.
- Addresses that repeat the pattern thousands of times across pools.
- Private order flow arrangements that give an operator sight of transactions before they are public.
What are the red flags?
- Swap execution consistently at the worst end of the slippage tolerance set.
- Large swaps on public routes receiving materially worse prices than small ones.
- Slippage settings left at a permissive default.
The defence available to any user is more effective than any of the above: tighten the slippage tolerance, split large swaps, and use a private relay. The extraction is bounded by the tolerance you set, so setting it deliberately rather than accepting a default removes most of the exposure.
What sandwich attacks are not
They are not arbitrage. Trading between venues to align prices is necessary and benefits everyone.
They are not all MEV. Liquidations and cross-pool arbitrage are extraction too, and both are functions the system needs.
They are not hacks. Nothing was breached, and every action used public functions as intended.
They are not clearly unlawful. This page says so plainly because it is true, and because a reference work that overstated the legal position here would be less useful than one that describes the gap.
Frequently asked questions about sandwich attacks and mev
- What is maximal extractable value?
- The profit obtainable by choosing which transactions go into a block and in what order. Some of it is benign arbitrage that keeps prices consistent; some of it is straightforward exploitation of transactions that are visible before they execute.
- Why are pending transactions public?
- Because most blockchains broadcast transactions to a public queue before they are included in a block, so that any validator can process them. The visibility is a design property of the system, not a leak.
- Is this front running?
- Functionally similar, legally different. Traditional front running breaches a duty a broker owes a customer. Here there is no broker, no customer and no duty: the information was public and the ordering was purchased. That gap is what makes the legal analysis hard.
- How does the attacker guarantee the ordering?
- By paying for it. Priority fees, or direct arrangements with block builders, determine placement. The attacker calculates the profit available and bids up to just below it, which is why most of the value flows to whoever orders the block.
- What is slippage tolerance?
- The worst price a swap will accept before reverting. A sandwich attack extracts exactly as much as the tolerance permits, so a user who sets a permissive default is defining the size of their own loss.
- Can users defend themselves?
- Yes, substantially. Tight slippage tolerances, private transaction relays that bypass the public queue, splitting large swaps, and using venues with batch auctions rather than continuous ordering all reduce exposure.
- Is all MEV harmful?
- No. Arbitrage between pools and timely liquidations are necessary functions, and whoever performs them is extracting MEV. The distinction is between value created by correcting prices and value taken from a specific identifiable victim.
- Has anyone been prosecuted?
- There have been prosecutions involving manipulation of block-building infrastructure and deception of the systems that order transactions. Ordinary sandwiching against public transactions has largely not been charged, and the legal position remains unsettled.
What techniques are related to sandwich attacks and mev?
Terms defined on this page
Sources
- 18 U.S.C. § 1343 — wire fraud — Cornell Legal Information Institute
- CFTC Rule 180.1 — Electronic Code of Federal Regulations
- SEC Rule 10b-5 — Electronic Code of Federal Regulations