Jump to content
Block Press

Protocol, chain and market reporting

Why Tight Slippage Settings Revert Swaps

A swap reverts when execution misses its minimum output. Set that floor from a fresh quote, then widen tolerance only enough to cover expected price movement.

The Block Press Editors5 min read

Abstract cover artwork for Why Tight Slippage Settings Revert Swaps

A swap with tight slippage settings reverts when its router receives less output than the transaction’s minimum-output limit allows. That limit protects the trade from filling at a worse price than you accept, but the quote can go stale before the transaction executes. The practical fix is to set the limit from a fresh quote, account for expected price movement and trade size, and avoid loosening it beyond the price you are willing to accept.

What does slippage tolerance check?

On an exact-input swap, the router checks that the output is at least the specified minimum amount. Many swap interfaces calculate that floor from a quote and the slippage tolerance: a wider tolerance lowers the minimum output, while a tighter one raises it. If execution falls below the floor, the router reverts the transaction instead of completing the trade at the worse rate.

The quote is an estimate based on a particular route and pool state. Between signing and execution, other swaps can change that state. The transaction may then produce less than the quoted output, even if the price change is small. For a guide to using Blackhole Swap from a wallet, see how to swap using Blackhole Swap. The tolerance check is a transaction limit; it does not guarantee that a quote stays available or that the swap will execute.

Price impact and slippage are related but distinct. Price impact is the effect the trade itself has on the pool price, given the trade size and available liquidity. Slippage is the difference between the quoted and executed result. A large trade can have high price impact before it is submitted; a quote can then move further while the transaction is pending. A tolerance wide enough to cover the second change does not erase the first.

How should I choose a slippage setting?

Choose a tolerance that covers plausible movement between quote and execution while keeping the minimum output above the lowest result you would accept. There is no universal setting: the appropriate margin depends on the asset, pool liquidity, route, trade size, and how quickly the quote can be included.

Start with a fresh quote and inspect the expected output and minimum output shown by the interface. If the minimum is already below your acceptable result, do not approve the swap at that setting. A smaller trade may reduce its own price impact. A route with deeper liquidity may also produce a more stable quote, if the interface offers alternatives. Neither change guarantees execution: the pool state can still move after quoting.

For an exact-output swap, the corresponding limit is usually a maximum input: the transaction reverts if it needs more input than that cap to deliver the requested output. The direction changes, but the decision is the same. Set the bound from the quote, then check whether the worst permitted result is acceptable.

What should I do when a swap keeps reverting?

First, check the revert reason or transaction simulation result. A slippage failure points to an output below the minimum or input above the maximum, but a revert can also come from an expired deadline, insufficient balance, missing token allowance, or another contract condition. Increasing tolerance only addresses the price-bound failure; it will not fix those other causes.

If the failure is specifically a slippage check, request a new quote and compare its expected output with the earlier one. If the quote has moved materially, decide whether the new price still makes the trade worthwhile. If it has, submit using the refreshed quote and a bound that matches your acceptable execution range. If it has not, wait or change the trade size rather than lowering the output floor until the transaction passes.

A pending transaction can become stale while it waits for inclusion. A deadline limits how long a transaction can execute, but it is not a substitute for a sound minimum-output bound. Check the deadline and the network fee separately: an on-chain revert generally still uses gas, and repeatedly resubmitting stale transactions can add cost without improving the price.

  • Refresh the quote just before signing.
  • Check the minimum output or maximum input, not only the displayed quote.
  • Reduce trade size if the trade itself moves the pool price too far.
  • Widen tolerance only when the new worst-case result remains acceptable.

Does wider slippage prevent every swap revert?

No. Wider tolerance lowers the chance that an ordinary price move crosses the transaction’s limit, but it also permits a worse execution price. It cannot prevent reverts caused by a deadline, balance, allowance, liquidity, or token-specific rule. Setting the bound extremely loose removes much of the price protection while leaving those other failure modes intact.

The confirmed mechanism is the contract’s execution bound: an exact-input trade must meet its minimum output, while an exact-output trade must stay within its maximum input. What remains unverified for any particular failed swap is the cause until its transaction data, route, and revert result are inspected. Use that evidence to distinguish a genuinely tight price bound from a different execution failure.