Slippage: What It Is and Why It Happens
Slippage is a term you'll hear constantly in DeFi, and it's simply the difference between the price you expected when you submitted a trade and the price you actually received when it confirmed. Understanding why it happens requires connecting two mechanics you've already learned: the AMM pricing formula from "How Decentralized Exchanges Work," and the fact that blockchain transactions take time to confirm, during which the world doesn't stand still.
There are two distinct sources of slippage, and it's worth separating them clearly. The first is price impact — your own trade mechanically shifts the pool's ratio, as shown in the worked example two lessons ago, so the effective price you pay for a large trade is always somewhat worse than the pool's starting price, purely as a function of your trade's own size. The second is time-based slippage — between the moment you submit your transaction and the moment it's actually included in a block and confirmed (which might be seconds or, during network congestion, much longer), other traders' transactions may also execute against the same pool, shifting the ratio further before your transaction lands. Your final executed price reflects whatever the pool's state is at the moment your transaction actually confirms, not the moment you clicked "swap."
Both sources matter, and both are the reason every DEX interface shows you a "slippage tolerance" setting (covered in depth in the next lesson): a safety limit on how much worse than the quoted price you're willing to accept before the transaction simply fails and reverts, rather than executing at a price you didn't agree to.
Worked Example
Suppose a DEX interface quotes you 0.500 ETH for swapping 1,000 USDC, based on the pool's reserves at the instant you requested the quote. You submit the transaction, but it takes three blocks to confirm — perhaps 30-45 seconds on a congested network — during which several other traders also swap against the same pool, shifting its ratio slightly in a direction that makes ETH marginally more expensive relative to USDC by the time your transaction actually executes. Your transaction confirms and you receive 0.495 ETH instead of the quoted 0.500 — a 1% slippage. Depending on the pool and market conditions, 1% might be an entirely normal, acceptable outcome for a liquid pair during active trading, or it might be unusually large for that specific trade size, signaling either unusually high network activity or a thinner, more volatile pool than you realized.
The key diagnostic question slippage raises is: was this difference caused mostly by my own trade size (price impact, which is predictable and calculable in advance, as you'll do in the next lesson) or mostly by other activity during my confirmation window (time-based slippage, which is less predictable)? A trade that shows large slippage even at a small size relative to the pool strongly suggests the pool itself is thin and risky, a signal worth noting before committing larger amounts.
A third, more adversarial factor can also widen slippage beyond ordinary price impact and time-based drift: sandwich attacks, where a bot specifically watches the pending-transaction queue (the "mempool"), spots your swap before it confirms, and deliberately places a trade immediately before yours (pushing the price against you) and another immediately after (capturing the resulting price movement as profit), effectively manufacturing extra slippage at your expense. This is a deliberate, targeted version of the time-based slippage described above rather than ordinary market activity, and it's one of the main reasons tight, well-chosen slippage tolerances (covered next) and transaction-privacy features offered by some wallets and routers matter in practice, not just in theory.
Common Pitfalls
- Treating all slippage as the same problem. Price impact is predictable in advance from reserves and trade size; time-based drift and sandwich attacks are not — don't assume a tight tolerance alone protects you from every source.
- Trading large size in a thin pool without checking price impact first. Most interfaces show an estimated price impact percentage before you confirm — read it, don't skip it.
- Ignoring repeated high slippage on the same pool. If a pool consistently shows outsized slippage even for modest trades, that is a signal of thin or manipulated liquidity worth investigating before committing more funds.
Exercise
Find two pools for comparison on a DEX interface (or using cached data): one with relatively small total liquidity (a thin pool) and one with relatively large total liquidity (a deep pool) — ideally for tokens you're not planning to actually trade, so you can compare safely. For the same hypothetical trade size in both, check the quoted price impact or slippage estimate the interface shows before you'd confirm anything.
Compare the two numbers and note how much larger the slippage estimate is for the thin pool versus the deep pool at the identical trade size. Write one or two sentences explaining, using the AMM reserve-ratio mechanics from the earlier lesson, exactly why a smaller pool shows more price impact for the same trade size — and what that tells you about using thin pools for anything beyond small, exploratory trades.
Recap
- Slippage combines price impact (your own trade shifting the pool ratio) and time-based drift (other trades happening before yours confirms).
- Unusually large slippage even at small trade sizes is a warning sign of a thin, risky pool rather than normal network conditions.
- Comparing a thin pool and a deep pool at the same trade size makes the relationship between pool depth and slippage concrete before you trade real funds.