MEV Sandwich Attacks: How Bots Tax Your Crypto Swaps
MEV bots can trade around a pending swap and worsen its execution. Learn how sandwich attacks work and which protections matter.
A swap can execute within its stated slippage limit and still give an unnecessarily bad price. One reason is maximal extractable value, or MEV: profit captured by controlling or influencing transaction order inside a block. A sandwich attack is the clearest example. A bot sees a pending swap, buys before it, then sells immediately after it.
The victim's own trade creates the price movement that pays the attacker. Understanding that sequence helps separate normal price impact from avoidable execution loss.
How Transaction Ordering Creates MEV
Most public blockchains do not process transactions in the exact order users submit them. Pending transactions first enter a public queue, commonly called a mempool. Validators or block builders then choose which transactions enter the next block and in what order, usually considering fees and other incentives.
That flexibility creates MEV. Arbitrage bots can use it to correct price differences between exchanges. Liquidators can close undercollateralized loans before they create bad debt. Those activities can improve market efficiency, even though the operators earn profit.
The problem starts when ordering works directly against a user's execution. A public pending swap reveals the asset, size, route, and maximum acceptable slippage before settlement. Searchers continuously scan that information for profitable opportunities.
MEV is not the same as a network fee:
| Cost | Who receives it | What drives it |
|---|---|---|
| Gas or priority fee | Validator and protocol | Network demand and transaction complexity |
| Price impact | Liquidity pool | Trade size relative to available liquidity |
| Sandwich loss | MEV searcher and block participants | Public order visibility and loose execution limits |
What Happens During a Sandwich Attack
Consider a user swapping 20 ETH for a token through an automated market maker. The order is large enough to raise the token's pool price, and the user permits 2% slippage. A searcher sees the pending transaction before it confirms.
The searcher builds a three-transaction sequence:
- The searcher buys the token first, pushing its pool price higher.
- The user's swap executes at the newly inflated price.
- The searcher sells the token after the user's purchase pushes the price higher again.
The searcher keeps the difference after gas and builder payments. The user receives fewer tokens, but the transaction does not revert because the result remains inside the 2% slippage limit.
Loose slippage tolerance defines the attacker's available profit budget. It does not guarantee a sandwich attack, but it tells a searcher how far execution can move before the transaction fails. Larger orders in thinner pools provide more room because they move prices further.
Sandwich attacks also involve risk for the searcher. Competing bots may bid away the profit, the victim may cancel the swap, or market conditions may change before inclusion. Searchers therefore target orders where expected proceeds clearly exceed transaction costs.
Why Slippage Settings Alone Do Not Solve MEV
Tightening slippage reduces the maximum loss an attacker can impose. It can also make a sandwich unprofitable. But an excessively tight setting causes swaps to revert during ordinary price movement, leaving the user with a gas bill and no trade.
Slippage combines several effects:
- Market movement between quote and settlement
- Price impact caused by the trade itself
- Route changes across liquidity pools
- Adversarial reordering by MEV searchers
A tolerance that works for a small ETH-to-USDC swap may fail for a volatile or illiquid token. The right limit depends on liquidity depth, order size, and current market activity. The crypto slippage guide explains how those inputs affect the minimum received amount.
Order splitting also needs care. Smaller trades usually create less price impact, which can reduce sandwich profitability. Yet several public swaps expose the user repeatedly and add transaction fees. A well-routed single order may outperform manual splitting when an aggregator can access deeper liquidity.
Which MEV Protections Actually Matter
Private transaction submission is the strongest common defense against sandwiches. Instead of broadcasting a signed swap to the public mempool, a wallet or routing service sends it directly to a trusted builder or protected relay. Searchers cannot attack an order they cannot see before settlement.
Some systems use intents rather than conventional transactions. The user specifies a desired outcome, such as receiving at least a certain amount of USDC for ETH. Competing solvers find and execute a route. This can move routing complexity away from the user, but protection still depends on how the intent is shared and settled.
Useful protections include:
- Private routing: keeps the pending order out of the public mempool.
- Firm minimum output: prevents settlement below the user's stated floor.
- Short deadlines: limits how long a signed quote remains executable.
- Route aggregation: finds deeper liquidity and reduces unnecessary price impact.
- Batch auctions: settles multiple orders together, making individual ordering less valuable.
No interface label proves complete protection. A "MEV protected" route may prevent sandwiches while still allowing other value extraction, including backrunning after the user's trade. Backrunning does not necessarily worsen the user's quoted outcome, and it can help restore prices across pools.
The practical question is whether the routing system protects the user's minimum output and hides exploitable information before execution. Marketing language matters less than those mechanics.
Read the swap before you sign.
MEV exists because transaction ordering has economic value. Not every form harms users, but sandwich attacks turn a pending swap into a predictable source of profit. Public visibility, meaningful price impact, and generous slippage create the opening.
Before signing, compare the quoted output, minimum received, price impact, and route. Treat an unusually wide gap between quoted and minimum output as a risk budget, not harmless flexibility. For Ethereum swaps, check the live gas tracker as well: high priority fees can make failed retries expensive, while volatile periods often attract more searcher competition.
Private routing and well-defined execution limits offer stronger protection than trying to outbid bots. A good swap route should make the intended outcome clear before the transaction leaves the wallet.
After settlement, compare the final amount with the signed minimum and the earlier quote. Repeated gaps on similar trades can reveal weak routing, thin liquidity, or persistent public-mempool exposure. That record gives users a concrete way to evaluate execution quality over time.