You submit a swap on a decentralized exchange: 10 ETH for USDC. The price looks good — the interface shows you will get roughly $32,000. You click confirm, pay the gas fee, and wait.

A few seconds later, your trade executes. But instead of $32,000, you receive $31,200. The price moved against you in the seconds between submitting and executing. You check the chart — there was no market movement, no news, no volatility. The price simply went up right before your trade and came right back down immediately after.

You were sandwiched.

This happens thousands of times per day on Ethereum and other EVM chains. The attackers are not hackers in the traditional sense — they do not break into contracts or steal private keys. They use a perfectly legal feature of public blockchains: the ability to see pending transactions before they are confirmed, and to pay for priority ordering.

BLUF: A sandwich attack works like this: a MEV bot monitors the mempool for large pending swaps on a DEX. When it spots your trade, it submits two transactions: one that buys the same token before you (front-run), and one that sells immediately after you (back-run). Your trade pushes the price up because of how AMMs work. The bot’s front-run buys low, your trade pumps the price, and the bot’s back-run sells high. The profit comes directly from your wallet — you get a worse price than you should have. The defense is simple: set low slippage tolerance, split large trades, and use MEV-protected routers.

How Sandwich Attacks Work

To understand sandwich attacks, you first need to understand two things about blockchain: the mempool and AMM pricing.

The Mempool Is Public

When you submit a transaction on Ethereum, it does not go directly into a block. It enters the mempool — a public waiting room where transactions sit until a validator or miner includes them. Anyone can read the mempool. There are services (Flashbots Protect, bloXroute, mempool watchers) that stream pending transactions in real time.

This means that between the moment you click “confirm” and the moment your transaction is included in a block, your trade is visible to everyone. The amount, the token, the direction — all public.

AMM Pricing Moves With Every Trade

Most DEXs use an Automated Market Maker (AMM) — a liquidity pool that prices tokens based on the ratio of reserves. The core formula for Uniswap-style pools is x * y = k, where x and y are the reserves of two tokens and k is a constant.

When you buy token B with token A, you remove token B from the pool and add token A. This shifts the ratio — there is now less token B and more token A. According to the formula, token B becomes more expensive. The larger your trade relative to the pool, the bigger the price impact.

This price movement is predictable. If someone can see your pending trade, they can calculate exactly how much the price will move.

The Attack in Three Steps

Here is the full sequence:

Step 1 — Front-run. The MEV bot sees your pending swap: you are buying 10 ETH worth of a token. The bot calculates that your trade will push the token price up by 3%. It submits its own buy order for the same token, with a higher gas price so that miners/validators include it before yours.

Step 2 — Your trade. Your trade executes. The token price moves up as expected — partly because of your trade, and partly because the bot’s front-run already moved it. You pay a higher price than you would have if the bot had not front-run you.

Step 3 — Back-run. The bot immediately submits a sell order for the tokens it just bought. It sells at the inflated price — the price your trade helped create. It pockets the difference between its buy price and sell price, minus gas fees.

The profit formula is simple: the bot buys at price P, your trade pushes the price to P + Δ, and the bot sells at P + Δ. The Δ — the price slippage you absorbed — is the bot’s profit, extracted from your trade.

A Concrete Example

You swap 10 ETH for Token X on a Uniswap pool. At current pool ratios, 10 ETH should get you 31,000 Token X.

  1. Bot front-runs: Buys 5 ETH worth of Token X. Price of Token X rises slightly. Your same 10 ETH now buys only 30,500 Token X.
  2. Your trade executes: You buy at the inflated price. You push the price even higher. You receive 30,500 Token X instead of 31,000 — you lost 500 Token X (about $1,600).
  3. Bot back-runs: Sells the Token X it bought. Sells at the peak price your trade created. Walks away with a profit of ~$800–$1,200 (depending on pool depth and gas costs).

You lost $1,600 in value. The bot made ~$1,000. The rest went to gas fees and pool mechanics. You were the meal.

Sandwich attacks exploit a structural property of public blockchains: transaction ordering is for sale. Validators and miners choose which transactions to include and in what order. They are incentivized to maximize their own revenue. MEV (Maximal Extractable Value) is the total value that can be extracted by reordering, inserting, or censoring transactions within a block.

Sandwich attacks are a form of MEV extraction. They are not illegal — they exploit protocol design, not a vulnerability in code. The bot operators are not hacking anything. They are reading public data and paying for transaction priority.

But that does not make them harmless. Sandwich attacks extract value from ordinary users who have no way to compete. They function as an invisible tax on every DEX trade — one that disproportionately affects users who do not know to protect themselves.

How to Protect Yourself

1. Set Low Slippage Tolerance

Slippage tolerance is the maximum price change you will accept. If you set it to 0.5%, your trade will revert if the price moves more than 0.5% between submission and execution. A sandwich bot’s front-run will push the price past your tolerance, and your trade will simply fail rather than executing at a bad price.

The trade-off: if you set slippage too low, your transaction may fail entirely on volatile tokens. A good default is 0.5% for stablecoin pairs and 1–2% for more volatile tokens.

2. Split Large Trades

Sandwich bots target trades that will cause significant price impact. If you swap $10,000 worth of a token in a small pool, the price impact is large and the sandwich profit is high. If you split that into five $2,000 trades spread across different blocks, each individual trade has less impact and is less attractive to sandwich bots.

Some DEX aggregators (1inch, CowSwap, Paraswap) automatically split trades across multiple pools and routes to minimize both price impact and sandwich risk.

3. Use MEV-Protected Routers

Several services now offer MEV-protected transaction routing:

  • Flashbots Protect: Routes your transaction through a private mempool that MEV bots cannot see. Your trade goes directly to block builders, bypassing the public mempool entirely. Free to use — you just need to set a custom RPC endpoint in your wallet.
  • CowSwap: Uses a batch auction model. All trades in a batch settle at the same uniform price, making sandwich attacks impossible within the batch. No front-running because there is no ordering advantage.
  • UniswapX: Uniswap’s own MEV-protected router that uses fillers (professional market makers) to compete for your trade, passing savings back to you instead of to MEV bots.
  • 1inch Fusion: Uses a reservation model where your trade is filled off-chain by resolvers, avoiding the mempool entirely.

These services are the single most effective defense against sandwich attacks. If you use a protected router, your transaction never enters the public mempool, and sandwich bots cannot see it.

4. Avoid Trading Low-Liquidity Tokens

Sandwich bots focus on pools where a single trade causes large price movements. In a deep pool with millions in liquidity, a $5,000 trade barely moves the price. In a shallow pool with $50,000 in liquidity, that same trade moves the price 10%. The deeper the pool, the less profitable the sandwich — and often bots will not bother.

Check a pool’s TVL before trading. If the pool has less than $500,000 in liquidity, assume your trade will be sandwiched unless you use protection.

5. Use Limit Orders

Some DEXs now support limit orders — you specify the exact price you want to buy or sell at, and the order only executes when the market reaches that price. Limit orders are immune to sandwich attacks because they do not execute at a worse price than you specified. If a bot tries to front-run, the order simply waits.

The Scale of the Problem

Sandwich attacks are not rare. According to data from MEV-Explore and Flashbots, sandwich attacks extract an estimated $100,000 to $500,000 per day from Ethereum users alone. That is tens of millions of dollars per year drained from ordinary traders — money that goes directly into the pockets of MEV bot operators.

The problem is worse on Layer 2 networks and alternative chains where mempool monitoring is cheaper and transaction fees are lower, making it profitable to sandwich even small trades.

The Broader MEV Landscape

Sandwich attacks are the most visible form of MEV, but they are not the only one. Understanding the broader MEV landscape helps contextualize the risk:

  • Arbitrage: Bots exploit price differences between pools or exchanges. This is generally beneficial — it keeps prices aligned across markets. You are not harmed.
  • Liquidations: Bots compete to liquidate undercollateralized positions on lending protocols. This is protocol-functioning, not an attack on users.
  • Front-running: The broader category of profiting from advance knowledge of pending transactions. Sandwich attacks are a specific form of front-running.
  • Back-running: Inserting a transaction immediately after another to profit from its effects. Sandwich attacks combine front-running and back-running.

The key distinction: arbitrage and liquidations are generally neutral or beneficial to the ecosystem. Sandwich attacks are purely extractive — they create no value and take it directly from users.

Identifying If You Were Sandwiched

You can check whether a past transaction was sandwiched:

  1. Use EigenPhi or ZeroMEV: These tools analyze transactions for MEV extraction. Paste your transaction hash and they will show whether a bot front-ran and back-ran your trade.
  2. Check the block on Etherscan: Look at the transactions immediately before and after yours in the same block. If the same address bought the same token before you and sold it after you, you were sandwiched.
  3. Compare expected vs. received: If your DEX interface showed you would get 31,000 tokens but you received significantly less — and the price returned to normal within the same block — that is a sandwich signature.

The Future of MEV Protection

The Ethereum ecosystem is actively working to reduce sandwich attacks:

  • Proposer-Builder Separation (PBS): Separates the roles of block proposal and block building, making it harder for any single party to extract MEV.
  • Encrypted Mempools: Proposals like Shutter Network and threshold encryption would encrypt transactions until they are included in a block, making front-running impossible.
  • Order Flow Auctions: Systems like UniswapX and CowSwap route trades through competitive auctions rather than the public mempool, redistributing MEV value back to users.

Until these solutions are fully deployed, individual protection remains essential.

For more on the broader MEV ecosystem, read our guide on MEV explained, how flash loan attacks work, and the red flags to watch for in DeFi protocols.

On-chain analysis helps you understand risk, not eliminate it. Always do your own research and use MEV protection when trading on decentralized exchanges.