The term "front-running" gets used in crypto to describe two related but different things. One is simply placing a transaction ahead of another. The other — the sandwich attack — is more surgical: a bot inserts itself both before and after a victim's trade, extracting value from both ends of the price movement. The name is accurate.
Understanding why sandwiches work requires understanding why large DEX trades are predictable.
Price Impact and the AMM
On a traditional order book, your trade doesn't necessarily move the price unless there aren't enough matching orders. On an automated market maker like Uniswap, price is determined by a formula — typically x × y = k — and every trade moves the price in the direction of the trade. Buy token A, and each successive unit costs slightly more. The bigger your buy, the more expensive the later units get.
This means price impact is calculable before a trade executes. A searcher bot monitoring the mempool can look at a pending swap, run the math against the pool's reserves, and know exactly how much the price will move if that transaction goes through. If the price movement is large enough to cover two additional gas fees with profit left over, the sandwich is worth running.
The Attack, Step by Step
The bot constructs three transactions in a specific sequence and submits them as a bundle:
First, it buys the same token the victim is buying — using a higher gas fee to ensure it lands before the victim's transaction. This nudges the price up.
The victim's swap then executes at this slightly elevated price and pushes the price further in the same direction. This is the price impact the victim was always going to pay. The sandwich just front-loads some of it.
Then the bot sells its position immediately after, at the price the victim's trade helped create.
The extracted value is the price difference between the bot's two execution prices, minus gas. The victim received fewer tokens than they would have without the bot's intervention.
The Slippage Variable
Here's where it gets a bit nuanced. The victim's trade executes successfully only if the final price stays within their slippage tolerance — the maximum price deviation they're willing to accept. If the sandwich pushes the price beyond that limit, the victim's transaction reverts. Both of the bot's transactions also revert, since they were bundled with the expectation the victim's trade would succeed. Everyone eats gas.
Very tight slippage is a defense of sorts. But it's a double-edged one. In volatile markets, legitimate trades revert constantly even without a sandwich attempt. Setting 0.1% slippage might protect you from MEV bots and also guarantee that any meaningful price movement reverts your transaction entirely.
What's Changed
Two things are worth knowing here.
Private transaction channels — Flashbots Protect, MEV Blocker, and the private RPC options now baked into most major wallets — route transactions without broadcasting them to the public mempool. No public visibility, no target. These are practical today, not experimental, and the right call for anyone doing a large swap they'd prefer not to have sandwiched.
But the more structurally interesting development is batch auction design. CoW Protocol collects batches of trades, matches willing counterparties directly where possible, and clears the rest through a pool at a single uniform price. Because every trade in the batch settles at the same clearing price, there's no positional advantage to exploit. The sandwich requires a "before" and an "after." A batch has neither. The attack vector isn't suppressed — it doesn't exist within that mechanism.
That's a meaningful distinction. Slippage settings and private channels reduce exposure. Batch auction design removes the structural prerequisite.
Confirmation Signals
Sandwich attack volume declining as a share of total DEX activity. Wider batch auction adoption in routing infrastructure. Wallets defaulting to private mempools as a standard rather than an opt-in.
What Would Invalidate the Concern
An encrypted mempool deployed at production scale would change this entirely. Several research projects are working on it, but none have deployed on a major chain in a way that affects real trading volumes. Until then, the prerequisite conditions — public mempool visibility and discretionary transaction ordering — remain in place on all major EVM-compatible networks.
At the individual level: the attack can't complete if slippage is set tight enough, or if the transaction doesn't touch the public mempool.
Timing Perspective
Now: Active risk on any large public mempool DEX swap. Private RPC options exist and work today.
Next: Batch auction adoption is growing; whether it reaches the scale to meaningfully shift the overall MEV landscape is an open question.
Later: Encrypted mempools remain a research-stage development, not a deployed reality.
Scope and Limits
This is a mechanism explanation. It doesn't recommend any specific wallet, protocol, or routing configuration — those decisions depend on chain, trade size, and acceptable friction. What's tracked at the signal level lives elsewhere.
The mechanism is understood. The structural solution — batch auctions — is live but not dominant. That gap is where the sandwich attack remains a real cost of doing business on public AMMs.
