A friend sent me a transaction hash after a swap filled a few percent worse than the quote he had screenshotted, and his question was whether the DEX had cheated him. It had not, at least not in any way a block explorer would show. He had told it, through a setting he had never once opened, that a fill that bad was acceptable, and something in the pipeline took him up on the offer. The setting is slippage tolerance, and most people treat it the way they treat a cookie banner. Click whatever makes the error go away and move on.
It is worth being precise about what the number actually does, because the name is misleading. When you sign an AMM swap you are not signing a price. The pool can change between the moment you get quoted and the moment your transaction lands in a block, so the router computes a minimum output instead: the quoted amount reduced by your tolerance, written directly into the transaction. If the pool would give you less than that minimum at execution time, the whole thing reverts and you eat the gas. If it would give you anything at or above the minimum, it fills. So tolerance is a floor on what you receive, and equivalently a ceiling on how much worse than the quote you are willing to be filled. Everything between the quote and the floor is fair game, and you agreed to all of it in advance.
It also helps to keep slippage separate from price impact, because interfaces show both as percentages and people blur them together. Price impact is the move your own trade causes by walking along the pool curve. It is deterministic given the pool state, it is known before you sign, and it sits right there in the swap preview. Slippage tolerance covers the other thing, whatever happens to the pool between your quote and your execution. Some of that is innocent, just other trades landing first. Some of it is trades that exist specifically because yours was visible in the mempool.
Why the default is wrong in both directions
Most interfaces default to something like half a percent, or an auto mode that lands in the same neighborhood. For a stable-to-stable swap on a deep stableswap pool, that is generous by roughly an order of magnitude. Two stablecoins should exchange within a few basis points of parity. If a stable swap genuinely needs half a percent of tolerance to clear, either the pool is shallow or one of the stables is trading off its peg, and both of those are things you want to notice, not paper over with a bigger number.
For a thin long-tail token the same default is often too tight. The pool moves more than that between blocks from ordinary noise, so the swap reverts, and the standard user response is to crank the slider until the transaction goes through. That is how people end up signing swaps with 10 or 15 percent tolerance on tokens where that much slippage is a plausible outcome rather than a safety margin. One default cannot be right for both cases, and in practice it is usually right for neither.
A generous tolerance is an invitation
Sandwich mechanics deserve a paragraph, because once you see them you never set tolerance casually again. Your pending swap sits in the public mempool with your minimum output visible inside it. A bot reads that, computes exactly how far it can push the pool against you before your transaction would revert, and buys ahead of you. Your swap then executes at the worse price, right at your floor if the bot is well written. The bot sells immediately after and pockets roughly the gap. Your tolerance setting is, functionally, a published maximum on how much you are willing to donate, and a competent bot will take almost all of it. At a tenth of a percent the sandwich is rarely worth the gas and the inventory risk. At 5 percent you are worth queueing for.
I should caveat this honestly. Not every chain and not every route carries the same exposure. Private order flow, MEV-protected RPC endpoints, and chains without a public mempool all change the math, and the better aggregators route around the worst of it. But if you are broadcasting through a default public RPC on a chain with an open mempool, the safe assumption is that a fat tolerance will eventually get used against you, because someone has written a bot whose entire job is finding it.
Ranges that have held up for me
None of this is gospel. Liquidity conditions vary, and you should lean higher when the market is moving fast. But as starting points:
- Stable pairs on deep stableswap pools: 0.05 to 0.1 percent. If the swap reverts at that level, investigate the pool or the peg before you raise anything.
- Majors against stables, meaning top-liquidity assets in deep pools: 0.1 to 0.5 percent, toward the high end when volatility is elevated.
- Mid-liquidity tokens: 0.5 to 1 percent.
- Thin long-tail tokens: 1 to 3 percent. If the quoted price impact is already above a couple of percent, the fix is a smaller trade or a split order, not a bigger tolerance.
- Fee-on-transfer tokens: the token's transfer tax comes straight out of your output, so tolerance has to exceed the tax or nothing fills. This is the one legitimate reason for a double-digit setting. Verify the tax from the contract or a token scanner first, because a swap that only clears at 12 percent slippage is also exactly what a soft honeypot looks like from the outside.
The thirty-second check before you sign
The habit that actually protects you is boring. Before signing, read the price impact line and ask whether it makes sense for your size in that pool. Then sanity-check the quoted rate against a second venue, an aggregator quote or a centralized-exchange price, because a quote that looks fine on price impact can still be terrible if you are in the wrong pool entirely. Then look at the tolerance field itself, every single time, because most interfaces persist the last value you used. A sticky 8 percent left over from some illiquid trade weeks ago will silently apply to your stablecoin swap today, and in my experience that is the single most common way careful people end up with careless fills.
For anything sizable on a public-mempool chain, route it through an MEV-protected RPC so your floor is not on display while the transaction waits. And when a swap reverts, treat the revert as information. The pool moved more than you allowed for, and the useful next question is why, not which number makes the error disappear. Sometimes the answer is ordinary volatility and a small bump is reasonable. Sometimes the answer is that you are about to buy something nobody can sell.
When we built DEX routing into Blockcircle we ended up setting default tolerance per pair type rather than using one global number, because watching real fills made it obvious that no single default survives contact with both a stablecoin pool and a week-old listing. You can get most of the same benefit manually with about thirty seconds of attention per trade. A reverted swap costs you gas, which stings. A lazy tolerance costs whatever the fastest bot in the mempool decides it should, which stings more and never shows up as a fee anywhere.