Slippage and MEV: Why Your Swap Costs More Than the Quote
Slippage is the gap between the price you saw and the price you got. Here is why it happens — pool depth, ordering, and MEV bots that sandwich your trade — and how to pay less of it.
Dive Deeper with AI
Click → prompt copied → paste in AI chat
Slippage is the difference between the price you saw in the quote and the price you actually got at execution. It happens because the pool price moves in the gap between quoting and settling your trade — partly from your own trade size against available liquidity, and partly from other transactions landing first, including MEV bots that deliberately position around your swap.
That is the short answer. The rest of this page explains where each fraction of extra cost comes from, and what you can actually do about it.
Why the price moves between quote and execution
A decentralized exchange quote is a snapshot. On an automated market maker (AMM), the price is a function of the token balances in the pool. Every trade that touches the pool changes those balances, and therefore the price. Your quote assumes the pool looks the way it did when you clicked. By the time your transaction is mined, it may not.
Two separate things push the executed price away from the quote:
- Price impact is the price you move yourself. A pool has finite liquidity. Buying pushes the price up along the curve; the bigger your trade relative to pool depth, the further you push it. This is deterministic and shows in the quote as an estimated price impact percentage.
- Slippage from ordering is the price other people move before you. Between your quote and your inclusion in a block, other trades can execute first, shifting the pool. Some of that is ordinary traffic. Some of it is adversarial — MEV.
Price impact is a property of your trade. Slippage tolerance is a setting that decides how much additional adverse movement you will accept before the transaction reverts.
Slippage tolerance and how it invites attacks
When you swap, the interface sends a minimum-received amount to the contract. That floor is derived from your slippage tolerance: a 1% tolerance means "revert if I would receive more than 1% less than quoted." It protects you from executing at a terrible price.
The tradeoff is direct. Set it too tight and normal price movement makes your transaction fail — you still pay gas for the reverted attempt. Set it too wide and you hand MEV bots a guaranteed margin.
A wide tolerance is an open invitation to a sandwich attack. Here MEV searchers monitor the public mempool, see your pending swap, and place two transactions around it:
- A front-run buy just before yours, pushing the price up.
- Your swap, which now executes at that worse price — still inside your tolerance, so it does not revert.
- A back-run sell just after, closing their position at a profit.
The searcher's profit is exactly the extra you paid. The wider your tolerance, the more room they have to squeeze, because your transaction will not revert until the price has moved by your full tolerance.
Where the extra cost comes from
| Cause of extra cost | What it is | How to reduce it |
|---|---|---|
| Price impact | You move the price against yourself because your trade is large relative to pool liquidity | Trade in deeper pools, split into smaller orders, use an aggregator that routes across pools |
| Slippage tolerance | The buffer you allow for adverse movement between quote and execution | Set it tight but realistic for the pair's volatility and pool depth |
| Sandwich / MEV | Searchers front-run and back-run your public swap for guaranteed profit | Use an MEV-protected RPC or private mempool; avoid wide tolerances |
| Failed-tx gas | A too-tight tolerance reverts the swap but still burns gas | Tune tolerance up slightly; avoid trading during volatile spikes |
Practical defense
- Size trades to pool depth. Check the price impact estimate before confirming. If a single swap shows several percent impact, the pool is too thin for that size.
- Set a tight but realistic tolerance. For deep stablecoin pairs, a fraction of a percent is often enough. For thin or volatile tokens you may need more, but treat every extra point as a gift to a sandwich bot.
- Use MEV-protected RPCs or private mempools. Sending your transaction through a private relay instead of the public mempool means searchers cannot see it pending, which removes the sandwich opportunity for that swap.
- Split large trades. Breaking one big order into several smaller ones reduces the price impact of each and gives bots a smaller target, at the cost of more gas.
- Prefer deep pools and aggregators. Aggregators route your trade across multiple pools and paths to minimize combined price impact, and often surface the real expected output rather than an optimistic quote.
The honest limits
None of this is free or absolute.
A too-tight tolerance does not save money if it makes your transaction revert on ordinary volatility — you pay gas and get nothing. The right number depends on the pair and the moment, not a universal rule.
MEV protection is a reduction, not a guarantee. Private mempools depend on the relay and the builder honoring their promises, coverage varies by chain, and not every venue routes through one. On some chains, block builders themselves can extract value. Treat MEV protection as lowering your exposure, not eliminating it.
The realistic goal is to stop overpaying by wide margins on avoidable causes — not to reach zero slippage, which does not exist on an AMM.
FAQ
Why did my swap execute at a worse price than the quote? Because the pool price moved between the quote and execution. Part of that is your own price impact — your trade size against the pool's liquidity — and part is other transactions landing first, which on public mempools often includes MEV bots sandwiching your swap.
What slippage tolerance should I set? Tight enough that a sandwich bot has little room, loose enough that normal movement does not revert you. For deep, stable pairs a fraction of a percent is common; for thin or volatile tokens you may need more. Watch the price impact estimate and adjust to the specific pair rather than using one default everywhere.
What is a sandwich attack? A form of MEV where a searcher sees your pending swap in the public mempool, buys just before it to push the price up, lets your swap execute at that worse price, then sells just after for profit. Your loss is their gain, and a wide slippage tolerance is what makes it possible.
How do I protect against MEV? Send swaps through an MEV-protected RPC or private mempool so searchers cannot see the transaction pending, keep your slippage tolerance tight, split large trades, and prefer deep pools and aggregators. This lowers your exposure substantially but does not remove it entirely.
Slippage and MEV both trace back to how these venues are built. To understand the extraction layer more deeply, read how MEV works, why liquidity pool depth determines price impact, and how these tradeoffs compare on DEXs versus centralized exchanges.
Read also
Order Books vs AMMs Explained
An order book matches buy and sell orders at chosen prices; an AMM prices trades from a formula against a liquidity pool. Here is how each works, where each wins, and where each fails.
DEX vs CEX: Trade-offs That Actually Matter
A CEX custodies your funds and matches trades on its own order book. A DEX is smart contracts you trade against from your own wallet. Here is the real trade-off — custody and permissionlessness versus liquidity, fiat, and support.
Liquidity Pools Explained Without the Jargon
A liquidity pool is a smart contract holding two tokens that traders swap against. Here is how the pricing formula works, how liquidity providers actually earn, and where impermanent loss quietly eats the profit.