Sandwich Attack: How MEV Bots Sandwich DEX Trades

1. What is a sandwich attack?
2. The mechanics: front-run + victim + back-run
3. Multi-layer sandwiches (5-layer, 7-layer)
4. The swap-JIT sandwich combo
5. Sandwich attack examples on Etherscan
6. How to protect yourself from sandwich attacks
7. Sandwich bot vs arbitrage bot

What is a sandwich attack?

A sandwich attack exploits the fact that DEX trades execute against a public liquidity pool. When a victim swaps a large amount of token A for token B on Uniswap, the swap consumes B from the pool and adds A — pushing B's price up. A sandwich bot that buys B before the victim, lets the victim's swap execute against the (now slightly worse) pool, then sells B after the victim's swap captures the price elevation as profit.

The whole sequence — front-run, victim, back-run — is submitted as an atomic bundle to a block builder. The bundle lands in one block or none of it lands. This atomic guarantee is what makes sandwich attacks risk-free for the bot: if the back-run can't execute profitably, the front-run also doesn't execute.

The mechanics: front-run + victim + back-run

Walk through a concrete example. The pool is Uniswap V3 USDC/WETH at price 1 WETH = 3,000 USDC. Pool reserves: 100 WETH, 300,000 USDC.

1. Front-run: bot buys 5 WETH with USDC. After the swap the pool holds 95 WETH and 315,000 USDC; new price is 1 WETH = ~3,315 USDC.
2. Victim: a user submits a 10-WETH buy with 5% slippage tolerance. The user's 10 WETH executes at the elevated rate. After the swap: 85 WETH, 350,000 USDC; new price is 1 WETH = ~4,118 USDC.
3. Back-run: bot sells its 5 WETH back into the pool at the new elevated rate, receiving roughly 17,000 USDC — net of the ~15,000 USDC spent on the front-run, the bot profits ~2,000 USDC minus gas and builder bribe.

The exact numbers depend on pool depth, victim size, victim slippage tolerance, and current gas conditions. Production bots run thousands of these per day, sized to each opportunity by their off-chain solver.

Multi-layer sandwiches (5-layer, 7-layer)

A traditional sandwich is 3 transactions: front-run, victim, back-run. JaredFromSubway scaled this into multi-layer variants:

• 5-layer: front-run → victim A → center swap → victim B → back-run. Two pending victims, both in the same direction, are sandwiched together. The center swap pushes price further between them, so victim B pays the worst rate.
• 7-layer: three victims, two center swaps, one front-run, one back-run. Capital efficiency is roughly 2x a traditional sandwich per gas unit spent.

Multi-layer attacks require careful slippage budgeting — each victim has an independent slippage tolerance, and the bundle's layer sizes must respect all of them simultaneously. If any victim reverts, the entire bundle fails. The off-chain optimizer that solves the sizing problem in single-digit milliseconds is the most valuable piece of IP in production sandwich bots.

The swap-JIT sandwich combo

JaredFromSubway combines sandwiching with JIT (just-in-time) liquidity in a single bundle, creating three simultaneous revenue streams:

1. Front-run swap moves the pool price.
2. Bot adds a concentrated-liquidity position around the post-front-run price via direct UniswapV3Pool.mint() — bypassing the NonfungiblePositionManager NFT layer to save gas and obfuscate execution.
3. Victim swap executes against the new pool state at a degraded rate. The bot earns LP fees on the victim's trade.
4. Bot removes liquidity via UniswapV3Pool.burn() and back-runs the swap.

Three revenue sources: price manipulation profit (sandwich), LP fees on the victim's swap (JIT), and arbitrage profit on the residual pool state shift. The bot decides per-opportunity whether plain sandwich, plain JIT, or the combo yields the highest expected value.

Sandwich attack examples on Etherscan

To find a real sandwich on JaredFromSubway's contract:

1. Open the contract on Etherscan and pick any recent transaction with high gas usage.
2. Click into the transaction's "Logs" tab — you'll see Transfer events.
3. The first Swap event is the bot's front-run buying the target token.
4. The next Swap event(s) are the victim transactions executing at the elevated price.
5. The final Swap event is the bot's back-run selling the token back.
6. Net ETH/WETH delta on the bot's address = profit on that bundle.

For attributed historical attack data, Flashbots MEV-Inspect indexes every sandwich on Ethereum with per-block profit breakdown. JaredFromSubway is consistently among the top sandwich operators by weekly volume.

How to protect yourself from sandwich attacks

• Tight slippage: set 0.1–0.5% slippage on public DEX swaps. Sandwich bots need slippage room to profit; tight slippage forces them to skip your trade.
• Flashbots Protect: a private RPC endpoint that bypasses the public mempool entirely. Your transaction goes straight to builders, invisible to sandwich bots.
• CowSwap / 1inch Fusion: intent-based DEX aggregators that batch trades off-chain and execute the cleared batch atomically — no mempool exposure.
• MEV-Share: Flashbots' newer system that selectively reveals minimal data to searchers in exchange for a rebate if MEV is extracted around your transaction.
• Smaller trades: below a certain size, the gas cost of a sandwich exceeds the profit. Splitting a large trade into many small ones reduces sandwich-ability.

Sandwich bot vs arbitrage bot

A crypto arbitrage bot extracts value from price differences across venues — Uniswap vs Sushiswap, DEX vs CEX, chain A vs chain B. Arbitrage doesn't harm any specific user; it's pure efficiency work. Sandwich attacks, by contrast, extract value directly from a counterparty (the victim) — the victim still gets their trade, but at a worse rate than they would in an unsandwiched mempool.

Most production MEV bots, including the JaredFromSubway infrastructure, run both strategies simultaneously. Sandwiching is more profitable when meme-coin volatility spikes; arbitrage is steadier and works through every market regime.

Further reading and references

• Flash Boys 2.0 (Daian et al., 2019) — Section 4 formalizes the sandwich attack and quantifies extracted value on early Ethereum DEXs.
• Flashbots Protect documentation — User-facing private mempool that defeats sandwich attacks by hiding pending transactions.
• Flashbots MEV-Inspect (sandwich classification) — Open-source pipeline that classifies every sandwich on Ethereum mainnet by operator and per-block profit.
• CowSwap MEV protection — Intent-based swap protocol that routes orders through batched solvers, removing the public-mempool surface that sandwich bots exploit.
• 1inch Fusion docs — Dutch-auction order flow that lets resolvers compete for fills off the public mempool; another defense against sandwich attacks.