What Is Slippage in Crypto?
Slippage is the difference between the price you expected when you submitted a trade and the price your trade actually executed at. It happens because prices move between the moment you see a quote and the moment your transaction confirms, and because your own order, particularly a large one, can consume enough available liquidity to move the price against you as it fills.
What Causes Slippage
Slippage isn’t a single cause; it’s usually some combination of three factors working together.
Volatility. Crypto prices move fast, and markets run continuously with no closing bell. In the seconds or minutes between submitting a trade and having it confirmed, the price can shift meaningfully on its own, independent of anything your order does. The more volatile the asset, the more this factor contributes.
Liquidity depth. Every trading venue, an order book on a centralized exchange or a liquidity pool on a decentralized one, has a finite amount of value available at each price level. A pool with substantial reserves absorbs a given trade size with barely any price movement; a shallow pool can see the same trade size move the price by a large percentage. This is why the same dollar amount of a major asset like BTC or ETH typically slips far less than the identical dollar amount of a thinly-traded token.
Order size relative to available liquidity. This is the factor most directly within your control. A trade that’s small relative to the liquidity it’s routing through barely moves the price. The same trade routed through thin liquidity, or sized large relative to whatever liquidity is available, moves the price meaningfully as it fills. This relationship isn’t linear either: as a trade gets larger relative to available depth, each additional increment tends to cost more than the one before it.
On centralized exchanges specifically, slippage typically comes from walking the order book, filling against progressively worse resting orders as a large trade consumes the best-priced liquidity first. On decentralized exchanges using automated market maker (AMM) pools, the mechanism is different: most AMMs price trades algorithmically based on the ratio of two assets in the pool, so a trade shifts that ratio as it executes, and the price you get reflects where that ratio ends up by the time your trade fully fills, not where it started.
Why Large Orders Suffer More
Size and liquidity depth are the two inputs that matter most, and a large order stresses both simultaneously. A $500 swap in a pool with millions in reserves barely moves the price. The same pool absorbing a $500,000 swap tells a completely different story, the trade has to consume enough of the pool’s liquidity that the ratio shifts substantially, and the execution price reflects that shift.
This is why checking liquidity depth before placing a large trade matters more than almost any other single precaution. Major pairs on major venues, BTC/USDT, ETH/USDC, and similar, typically have deep enough liquidity that even sizable trades produce modest slippage. Smaller-cap tokens or thinner pools can see dramatically worse outcomes for the same trade size, sometimes severe enough that a large order executes at a small fraction of its expected value if the pool simply can’t support that size.
Large orders also carry a second-order risk beyond pure liquidity mechanics: a visible large order, sitting in a public mempool waiting for confirmation, can signal information to other market participants, including automated bots specifically looking for large pending trades to exploit. That risk is significant enough to cover on its own, below.
Slippage Tolerance: How It Works and the Sandwich Attack Risk
Most DEX interfaces, and some centralized platforms, let you set a slippage tolerance: the maximum percentage price movement you’re willing to accept before the trade fails rather than executing at a worse price. If you set a 0.5% tolerance and the price moves more than that before your transaction confirms, the swap reverts and you keep your original tokens, typically losing only the gas fee for the attempted transaction.
The tolerance setting is a genuine trade-off, not a setting with an obviously correct universal value. Too tight, and normal price movement during confirmation causes your transaction to fail repeatedly, wasting gas on each failed attempt. Too loose, and you’re exposed to both a worse fill than necessary and a specific, well-documented form of exploitation: the sandwich attack.
A sandwich attack works like this: your pending swap sits visibly in the public mempool before it confirms. An automated bot monitoring the mempool spots your trade, calculates how much your slippage tolerance allows the price to move, and inserts its own trade immediately before yours (pushing the price up, if you’re buying), lets your trade execute at that now-worse price, then immediately sells back into the price movement your trade caused, capturing the difference as profit. Your trade still executes, technically within your stated tolerance, but at a meaningfully worse price than it would have gotten without the attack. Wide slippage tolerance settings, thin liquidity pools, and large order sizes relative to pool depth are the conditions that make a trade most attractive to sandwich bots specifically.
The uncomfortable reality: for a normal public-mempool transaction, lowering your slippage tolerance alone doesn’t fully prevent sandwich attacks, a bot can still extract whatever your tolerance allows, however small. Real protection comes from where and how you submit the transaction: routing through a private transaction relay that bypasses the public mempool entirely, or using intent-based or batch-auction protocols specifically designed to remove the mempool visibility that makes sandwiching possible in the first place.
How to Minimize Slippage on Big Swaps
For a swap large enough that slippage is a real concern rather than a rounding error, a few practices consistently reduce it:
Check liquidity depth before trading, not after. Understanding how much your specific trade size will move the price in the specific pool or venue you’re using is the single most useful piece of information before committing to a large trade.
Split large orders. Breaking a large trade into smaller pieces, executed sequentially rather than all at once, reduces the cumulative price impact compared to forcing the full size through in one transaction. This is a manual, less efficient version of what routing tools automate.
Route through an aggregator rather than a single pool. An aggregator that compares and splits across multiple liquidity sources can access meaningfully more total depth than any single venue, which directly reduces the slippage a given trade size experiences.
Set a sensible tolerance, not the widest one that guarantees execution. If a trade only succeeds with a very high tolerance setting, that’s a signal the pool’s liquidity doesn’t comfortably support your trade size, not a problem to solve by loosening the setting further.
Trade during deeper-liquidity periods where practical. Order book and pool depth aren’t constant throughout the day; liquidity tends to be thinner during off-hours and immediately following major volatility-inducing news.
For the full mechanics of minimizing slippage and market impact specifically on large, whale-sized orders, including cross-chain routing and splitting strategy, see How to Execute Large Crypto Swaps With Minimal Market Impact.
Same-Chain vs Cross-Chain Considerations
Slippage mechanics apply the same way whether you’re trading on one chain or moving across chains, but a cross-chain trade adds a layer on top: the bridging step itself. Beyond the price movement risk covered above, a cross-chain swap depends on the liquidity and security of whichever bridge protocol handles the cross-chain leg, a separate consideration from slippage but one that compounds with it if a large trade is routed through a specific chain’s liquidity purely because that’s where your assets happen to sit, rather than where the deepest liquidity for that pair actually exists. For a deeper explanation of how bridges and cross-chain aggregators differ mechanically, see Cross-Chain Swaps Explained.
FAQ
What is slippage in simple terms?
Slippage is the gap between the price you expected when you placed a trade and the price you actually got once it executed. It happens because prices move during the time it takes a trade to confirm, and because a trade, especially a large one, can consume enough available liquidity to shift the price against itself as it fills.
What is a good slippage tolerance?
It depends on what you’re trading. For major, highly liquid pairs like BTC or ETH against stablecoins, a tolerance in the range of roughly 0.1%–0.5% is typically sufficient under normal conditions. For mid-liquidity tokens, something in the 0.5%–2% range is more realistic. For thin, low-liquidity tokens, needing a tolerance above 3–5% to get a trade to succeed is usually a signal the pool itself doesn’t have adequate depth for your trade size, not a setting to simply push higher.
Why is slippage higher on large orders?
A large order consumes more of the available liquidity at each price level before it fully fills, whether that means walking further down an order book or shifting an AMM pool’s pricing ratio more significantly. The effect compounds as size increases relative to available depth: each additional portion of a large trade tends to move the price by more than the portion before it did.
How do I minimize slippage on a big swap?
Check liquidity depth before trading, split large orders into smaller pieces rather than executing all at once, route through an aggregator that can access liquidity across multiple sources rather than a single pool, and avoid setting an unnecessarily wide tolerance just to force execution. For the full method on minimizing both slippage and broader market impact on large trades specifically, see How to Execute Large Crypto Swaps With Minimal Market Impact.
What is a sandwich attack?
A sandwich attack is a form of MEV (Maximal Extractable Value) exploitation where a bot spots your pending trade in the public mempool before it confirms, places its own trade immediately before yours to push the price against you, lets your trade execute at that worse price within your slippage tolerance, then immediately trades back to capture the price movement your trade caused as profit. Wide slippage tolerance, thin liquidity, and large trade size relative to pool depth all increase the likelihood a given trade becomes an attractive sandwich target.
Get Started
For programmatic access to liquidity routing designed to reduce slippage and market impact on large trades, see the YiFi Swap API documentation.
For how bridges and cross-chain aggregators handle routing differently, see Cross-Chain Swaps Explained.