What Is Slippage in DeFi?
On a DEX, price can move between the quote and settlement. Slippage tolerance sets your floor, and setting it too high invites sandwich-attack bots.
Quick answer
Slippage is the difference between the price you were quoted and the price your trade actually gets when it settles on-chain. On DEXs it is unavoidable because of block delay and how AMM pools move price, and you cap it with a slippage tolerance that enforces a minimum-received amount. Setting tolerance too high risks a bad fill and invites sandwich attacks, so use the tightest value that still executes.
Key points
- Slippage is the gap between your quoted price and the price your trade executes at.
- AMM pools move price as you trade, so larger trades in shallow pools slip more.
- Slippage tolerance enforces a minimum-received amount; if price moves past it, the trade reverts.
- A high tolerance risks a worse fill and enables sandwich attacks by MEV bots.
- A tight tolerance limits how much value an attacker can extract from your swap.
- Slippage is distinct from gas fees and from impermanent loss faced by liquidity providers.
Slippage is the gap between the price you expect when you submit a trade and the price you actually get when it settles on-chain. On a decentralised exchange (DEX) this gap is unavoidable, because there is always a delay between pressing “swap” and your transaction landing in a block, and the market can move in that window. Understanding slippage, and the slippage tolerance setting that controls it, is essential to trading on DeFi without silently overpaying or exposing yourself to attackers.
Why slippage exists on a DEX
Most DEXs do not use an order book. They use automated market makers (AMMs), where prices are set by a formula against the balances in a liquidity pool. A common design keeps the product of the two token balances constant, so every trade moves the price along a curve. When you buy from the pool, you push the price up for the next unit you buy. This has an immediate consequence: the larger your trade relative to the pool, the worse your average execution price. Uniswap’s own explainer lists the main drivers of slippage as market volatility, low liquidity, trade size, and MEV or sandwich attacks.
Price impact vs. slippage
These two terms are related but distinct. Price impact is the movement your own trade causes by consuming liquidity along the curve; it is predictable from the pool’s size and is larger for big trades in shallow pools. Slippage is the broader gap between quote and execution, which also includes price changes from other transactions that land before yours. You control price impact by trading smaller sizes or using deeper pools; you manage the rest with a tolerance setting.
How slippage tolerance protects you
Slippage tolerance is the maximum price movement you are willing to accept before the transaction should fail instead of executing. If you set 1%, the swap is allowed to fill at up to 1% worse than quoted; if the price moves further, the contract reverts and your trade does not go through. This is enforced by a minimum-received (or minimum-output) amount encoded in the transaction: the AMM contract will only complete the swap if you receive at least that amount, otherwise it cancels. In Uniswap’s example, selling 1 ETH quoted at 2,000 USDT with 1% tolerance sets a minimum received of 1,980 USDT.
The Uniswap web app suggests tolerances roughly between 0.1% and 5% depending on conditions. The setting is a balance:
- Too low and legitimate trades fail repeatedly in volatile markets or thin pools, and you still pay gas for the failed attempts.
- Too high and you authorise a much worse fill than expected, which is exactly what predatory bots want.
The dangerous link: slippage and sandwich attacks
A high slippage tolerance is not just a chance of a bad price, it is an open invitation to attackers. Public blockchains broadcast pending transactions in a shared waiting area called the mempool, where anyone can see your swap before it confirms. This visibility enables a specific form of MEV and front-running called the sandwich attack.
Here is the mechanism:
- A bot spots your pending swap and your generous slippage tolerance in the mempool.
- It front-runs you: it buys the same token just before your trade, pushing the price up.
- Your trade executes at that worse price, still within your tolerance, so it does not revert.
- The bot back-runs you: it immediately sells at the inflated price, pocketing the difference.
You are the filling in the sandwich. Crucially, the attack only succeeds up to the slippage you allowed, a tight tolerance limits how much can be extracted, because a larger price move would trip your minimum-received check and revert the trade.
Practical ways to manage slippage
- Set the tightest tolerance that still executes. Start low and raise only if the trade fails, rather than defaulting to a large buffer.
- Size trades to the pool. Very large swaps in shallow pools cause heavy price impact. Splitting an order or using an aggregator that routes across pools can reduce it.
- Watch the minimum received. Before confirming, read the worst-case output the interface shows. That number, not the headline quote, is your guaranteed floor.
- Trade deeper liquidity. Pools with more liquidity move less per trade, lowering both price impact and the room for sandwiching.
- Consider a private transaction route. Some services let you submit swaps through a private channel that bypasses the public mempool, removing the visibility sandwich bots depend on.
- Beware auto-set high tolerances. Some low-liquidity or fee-on-transfer tokens require large tolerances to trade at all; that is a warning sign, not a convenience.
Slippage is not the same as fees or impermanent loss
Keep three costs separate. Network (gas) fees pay for computation and are charged even when a trade reverts. Slippage is a price difference on execution. And impermanent loss is something liquidity providers experience when pool prices diverge, not something traders pay per swap. Confusing them leads to bad decisions, for example blaming “slippage” for what is really a large price impact from an oversized trade in a thin pool.
A quick mental model
Think of slippage tolerance as a stop switch you set before every swap. The quote is a hope; the minimum received is a promise. Set the switch as tight as market conditions allow, respect what the pool depth is telling you about price impact, and treat any swap that demands a very high tolerance with suspicion. Done consistently, this turns slippage from a hidden tax and an attacker’s opening into a controlled, understood cost of trading on-chain. For the wider context of how bots profit from transaction ordering, see our explainer on MEV and front-running, and to see where your pending swap actually sits before it confirms, read about the mempool.
A worked example of the numbers
Concrete figures make the mechanism clear. Suppose a swap is quoted to return 2,000 units of a stablecoin, and you consider two tolerance settings:
| Slippage tolerance | Minimum received (worst case) | What it means |
|---|---|---|
| 0.5% | 1,990 | Trade reverts if it would return less than 1,990; very little room for an attacker |
| 1% | 1,980 | A balanced setting for normal conditions |
| 5% | 1,900 | Executes even in volatile conditions, but gives bots up to 100 units of room to extract |
The figures are illustrative, but the relationship is exact: your minimum received is simply the quote reduced by your tolerance, and it is the only number the contract actually guarantees. Everything above it is best-case marketing; the floor is what protects you.
Special case: fee-on-transfer and low-liquidity tokens
Some tokens charge a built-in tax on every transfer, or sit in very shallow pools. These frequently demand large slippage tolerances just to complete a swap, and interfaces may warn you or auto-raise the setting. Treat that as a signal about the asset, not a routine adjustment: a token that cannot be traded without a wide tolerance is a token whose swaps are easy to sandwich and whose true cost is higher than the quote suggests. Some of these designs are legitimate; others are engineered so that buying is easy and selling is punished, a pattern worth investigating before you commit funds.
Slippage beyond simple swaps
The same principle appears wherever a DeFi action’s output depends on live on-chain state, adding or removing pool liquidity, or interacting with lending markets, not just token swaps. In each case the interface typically lets you set a minimum acceptable outcome. The habit generalises: before signing, find the guaranteed worst-case number, decide whether it is acceptable, and only then confirm. Reading how prices move inside a pool, covered in how automated market makers work, makes it obvious why that worst-case buffer exists in the first place.
Why the setting exists at all
It is tempting to see slippage tolerance as an annoyance, an extra field standing between you and a trade. But it exists because on-chain settlement is fundamentally different from clicking “buy” on a centralised app. When you submit a swap, you are not accepting a fixed price; you are broadcasting an instruction that will be executed later, by someone else, against a pool whose state may have changed. Without a minimum-received guardrail, you would be signing a blank cheque, agreeing to whatever price the pool happens to offer whenever your transaction lands, however far it has moved and however many bots have positioned themselves around you. The tolerance is your way of bounding that uncertainty. A tight value says “execute me at close to the quoted price or not at all”; a loose value says “execute me almost regardless of price.” Seen that way, the setting is not friction, it is the primary consumer protection you carry into every on-chain trade, and treating it thoughtfully is one of the clearest signs of a careful DeFi user.
Common mistakes to avoid
- Blindly accepting an auto-raised tolerance. If an interface bumps your tolerance to a large value to make a trade go through, pause and ask why.
- Reading the quote instead of the floor. The estimated output is optimistic; the minimum received is what you are actually guaranteed.
- Assuming a failed swap cost nothing. A reverted transaction can still consume gas, so repeatedly retrying with a too-tight setting has a real cost.
- Trading illiquid tokens at market without checking pool depth. Thin pools turn even modest orders into heavy price impact.
Sources
- What is Slippage? — Uniswap Labs blog
- How to Minimize Slippage on Your Swaps — Uniswap Labs blog
- Maximal extractable value (MEV): sandwich trades and front-running — ethereum.org
- Flashbots Protect: hiding transactions from sandwich bots — Flashbots Docs
Frequently asked questions
What is a good slippage tolerance?
What is minimum received?
Why did my swap fail with a slippage error?
Is slippage the same as price impact?
How does slippage tolerance relate to sandwich attacks?
Can I avoid slippage entirely?
Note: CamoCrypt is security & education only — no prices, no predictions, no investment advice. Verify every address and contract yourself; we cannot recover lost funds and neither can anyone who contacts you claiming they can.