A step-by-step breakdown of how sandwich bots front-run pending swaps in the mempool, with a worked example and the concrete settings that shrink the attack window.
Selin AydinSecurity Editor · Crypto security, custody, exploits and smart-contract risk
A sandwich attack front-runs a pending swap: a bot buys ahead of it, lets the victim's trade push the price up, then sells into it. Slippage tolerance defines the attack surface, because a wide tolerance authorises anyone watching to take up to that amount. Tight tolerance plus an MEV-protected or intent-based route removes the exposure.
Sandwich attacks are the most common form of front-running in DeFi, and they cost traders real money every single day, usually without the victim ever realising they were targeted. The mechanism is simple enough to explain in a sentence: a bot spots your pending trade, jumps in front of it to push the price against you, lets your trade execute at the worse rate, then jumps out behind you to pocket the difference. Understanding exactly how this works is the fastest way to stop being an easy target.
It starts with a large pending swap sitting in the public mempool, say, someone swapping 50 ETH for USDC on a decentralized exchange. A bot watching the mempool sees this transaction before it's confirmed and recognises that a trade of this size will move the pool's price meaningfully. The bot immediately submits its own buy order for the same asset, paying a higher gas fee to ensure it lands in the block ahead of the victim's transaction.
That front-run buy pushes the price up before the victim's trade executes. The victim's swap then goes through against this already-worse price, receiving fewer tokens than they would have gotten in a clean market. From the victim's side, nothing looks obviously wrong: the transaction confirms, it just settles at a price a bit worse than expected, easily mistaken for ordinary slippage rather than a targeted attack.
Immediately after, the bot places a sell order, the back-run, unwinding its position at the new, higher price the victim's own trade helped create. The bot buys low, the victim trades in the middle at an inflated price, the bot sells high, and the entire sequence happens within the same block or two, in seconds rather than the trader ever having a chance to react.
Say a liquidity pool holds 1,000 ETH and 3,000,000 USDC, pricing ETH at roughly $3,000. A trader submits a swap of 50 ETH for USDC with 1% slippage tolerance, expecting close to $149,000. A sandwich bot front-runs with its own buy, shifting the pool's effective price upward by, say, 0.8% before the victim's trade lands. The victim's 50 ETH now sells into a pool that's already been nudged against them, executing near the edge of their slippage tolerance and receiving closer to $147,500, roughly $1,500 worse than a clean execution. The bot's back-run sale then captures most of that difference, minus gas costs, which on a busy day for popular pairs can still be a very profitable trade repeated dozens of times.
Slippage tolerance exists for a legitimate reason, to let a trade go through even if the price moves slightly between submission and confirmation, which happens naturally in volatile markets. But that same tolerance is precisely the room a sandwich bot needs to operate in. A trader who sets 3% slippage tolerance "just to be safe" is, in effect, telling every bot watching the mempool exactly how much room they have to extract before the transaction would revert. Wider tolerance doesn't just risk more slippage from normal market movement, it directly enlarges the profitable range for an attacker.
Sandwich bots run as automated searchers, continuously parsing every pending transaction in the mempool for swaps large enough, and with wide enough slippage tolerance, to be worth attacking after accounting for gas costs. They simulate the outcome before committing, and when a target looks profitable, they submit both the front-run and back-run transactions as a bundle, often through a private relay like Flashbots Protect, guaranteeing their exact ordering around the victim's trade without broadcasting their intent to the public mempool first. This is why sandwich attacks have become more surgical and harder to spot over time; the bots doing it have gotten very good at hiding their own tracks while watching everyone else's.
The single most effective individual defence is tightening slippage tolerance to the minimum the trade actually needs, which shrinks or eliminates the attacker's profitable window entirely, at the cost of the trade occasionally failing to execute in fast-moving markets. Beyond that, routing transactions through a private RPC or an MEV-protection service keeps the trade out of the public mempool entirely, so bots never see it coming until it's already confirmed. Several wallets and aggregators, including 1inch, CoW Swap and MetaMask's own MEV-protection options, now build this in by default or as an easy toggle.
If you trade directly through a DEX front-end, check three things before your next swap: what slippage tolerance is currently set, whether the interface offers a private transaction or MEV-protection mode, and whether you're trading a size large enough or a pair thin enough to be worth attacking in the first place. Small trades on deep, liquid pairs are rarely worth a bot's gas cost to sandwich; large trades on thinner pairs are the highest-risk combination, and exactly where tightening slippage and routing privately matters most.
Sandwich attacks persist because they're a direct, mechanical consequence of public mempools and permissionless transaction ordering, not a flaw anyone can simply patch out of a specific protocol. Private order flow and encrypted mempools are gradually shrinking the surface area, but as long as pending trades are visible and profitable to intercept before confirmation, someone will build a bot to intercept them. Treat every public, high-slippage swap as visible to an adversary before it's visible to you, because on most chains today, it is.
Sandwich bots have extracted billions from ordinary swaps since the Merge. Here's what the actual technical countermeasures — PBS, encrypted mempools, and private order flow — do and don't fix.
No order book, no market makers standing by — just a formula and a pool of reserves. Here's the mechanics behind the constant-product curve that prices most of DeFi.
Smart contracts can't see the outside world on their own. Oracles are the systems that feed them prices, events, and data — and getting that design wrong has cost DeFi protocols hundreds of millions.