The sandwich attack: how MEV bots trade around you, and how to stop feeding them

When you swap tokens on a decentralised exchange, your transaction does not go straight into a block. It waits, usually in a public mempool, where anyone can read it: which pool, how much, and the worst price you are willing to accept. Whoever builds the next block decides the order in which waiting transactions run. On a blockchain, order is money, and a whole industry of bots exists to buy that order.

This post is the second in our protocol series. The first explained zero-knowledge proofs; this one explains MEV, focusing on the attack you are most likely to suffer as an ordinary user.

What MEV means

MEV originally stood for "miner extractable value" and now stands for maximal extractable value: the extra profit a block producer, or anyone who can pay one, can make by including, excluding or reordering transactions. The term comes from the 2019 paper Flash Boys 2.0, which showed bots on Ethereum racing each other in gas auctions to be first in line.

Not all MEV is harmful. Arbitrage brings prices on two exchanges back in line, and liquidations keep lending protocols solvent; both happen anyway and someone has to do them. MEV becomes harmful when the profit comes directly out of another user's trade. The sandwich attack is the clearest case.

A sandwich, step by step

Take an ETH/USDC pool on a Uniswap v2-style exchange with 1,000 ETH and 2,000,000 USDC, so 1 ETH costs about 2,000 USDC. The pool charges a 0.3% fee and prices trades with the constant-product rule x · y = k: every purchase makes the next one more expensive.

You want to spend 20,000 USDC on ETH. Because your trade is large relative to the pool, the exchange quotes you 9.872 ETH (not 10, because your own trade moves the price). You keep the default 1% slippage tolerance, so your transaction says: "give me at least 9.773 ETH or revert."

A bot sees this in the mempool and bundles three transactions in this order:

1. Front-run. The bot buys ETH with about 10,141 USDC and receives 5.03 ETH. The pool price rises from 2,000 to about 2,020.
2. Your swap. You buy at the worse price and receive 9.773 ETH, exactly your minimum. Your transaction succeeds, so nothing looks wrong. The price rises to about 2,061.
3. Back-run. The bot sells its 5.03 ETH into the now-expensive pool and gets back about 10,281 USDC.

The bot made about 140 USDC before gas and builder tips. You received 0.099 ETH less than quoted, about $197 at the starting price, or 1% of your trade. The difference between your loss and the bot's profit went to the pool's liquidity providers as fees on the two extra trades.

Notice what the bot did not need: no bug, no stolen key, no flash loan. It used only public information and the ability to choose order.

Your slippage setting is the attacker's budget

The most important line in the example is this one: the bot sized its front-run so that you received exactly your minimum. That is not a coincidence. A sandwich bot solves a small optimisation problem for every pending swap: how much to buy first so that the victim still does not revert, while leaving the bot as much profit as possible after fees and gas.

That gives a simple rule. Whatever slippage you allow is roughly what a sandwich bot can take. A 0.1% tolerance on a stablecoin swap leaves almost nothing to extract. A 5% tolerance on a thin memecoin pool is an invitation. Large trades in small pools are the best targets because one trade moves the price a lot, and the bot only profits when that movement is larger than the fees it pays on its two legs.

How big is the problem?

On Ethereum, sandwich attacks are frequent but individually small. Data from EigenPhi analysed by Cointelegraph Research covering November 2024 to October 2025 found 60,000 to 90,000 sandwich attacks every month, with monthly extraction falling from nearly $10M in late 2024 to about $2.5M by October 2025. The average profit per attack was only a few dollars, and about 70% of attacks were linked to a single searcher known as jaredfromsubway.eth.

The same searcher became a lesson in the other direction in June 2026, when an attacker drained more than $7.5M from its bot. According to Blockaid, the attacker fed the bot 66 fake token contracts over several weeks until it approved one controlled by the attacker. MEV bots are automated programs that hold real money and interact with untrusted contracts all day, so they are attack surfaces too.

Volumes on Ethereum have fallen mostly because users moved to protected order flow. On chains where the mempool is still exposed and fees are low, sandwiching remains a daily cost for ordinary traders.

Who sees your transaction

To defend against sandwiches, it helps to know the path a transaction takes on Ethereum today. Since the move to proof-of-stake, most blocks are built through proposer-builder separation (PBS): specialised builders assemble the most profitable block they can, searchers send them bundles (like the three-transaction sandwich above) with a tip, and relays pass the winning block to the validator who proposes it. Searchers do not need to be validators; they only need to see your transaction before it lands.

That points to the defences: hide the transaction, take away the ordering advantage, or make the trade not worth attacking.

Defences, from easiest to most ambitious

1. Set a tight slippage and split large trades. This is free. Use the smallest tolerance that still lets your trade go through, and split big swaps into smaller ones or use a time-weighted order.

2. Send through a private RPC. Services such as Flashbots Protect and MEV Blocker send your transaction straight to builders instead of the public mempool. Searchers never see it, so they cannot sandwich it. Many also refund part of the back-run value that your trade creates. This is the single biggest reason sandwiches on Ethereum fell.

3. Use intent-based or batch-auction exchanges. Instead of a transaction that says "swap on this pool", you sign an intent: "I want at least this much ETH for this much USDC". Solvers compete to fill it, and protocols like CoW Swap settle many orders in a batch at one uniform clearing price, so there is no "before" and "after" inside the batch to exploit. UniswapX and 1inch Fusion use similar auctions.

4. Change the protocol itself. Research directions include encrypted mempools, where transactions are only decrypted after their order is fixed (Shutter on Gnosis Chain is a live example), fair-ordering consensus such as Aequitas and Themis that limits how freely a leader can reorder, and protocol-level PBS with inclusion lists so that one builder cannot censor or reorder at will. Each has costs in latency, trust assumptions or complexity, and none is finished.

At the application level, Uniswap v4 hooks let a pool run custom code before and after each swap, which is a new playground for ideas such as dynamic fees that rise when a pool detects sandwich-like patterns.

Takeaway

A sandwich attack is not a bug in a contract. It is the result of three normal features working together: a public mempool, prices that move with trade size, and someone who can choose order. As a user, the fix is mostly habit: tight slippage and a private RPC. As a researcher, MEV is one of the richest open areas in blockchain, sitting at the junction of game theory, cryptography and systems, and the measurement data is fully public. The next post in this series is an open research idea that builds on exactly this.