Set Swap Slippage by the Minimum Output Your Trade Can Accept

For frequent token swaps, set slippage tolerance to the smallest value that lets the transaction clear ordinary price movement before it is included on-chain. A swap quote estimates an output amount, while the transaction’s minimum output, often called minOut, sets the lower bound the contract will accept. If execution would deliver less, the swap reverts. A wider tolerance can reduce failed swaps, but it also permits a worse fill.

The displayed tolerance is not a forecast of the price impact or a guarantee of the final fill. It is a limit supplied to the swap call. For a fuller account of how routing, transaction construction and confirmation fit together, see this explanation of paraswap. The useful question for a frequent trader is not “Which percentage is standard?” but “How much deterioration can this trade accept before I would rather it fail?”

What does slippage tolerance control?

Slippage tolerance controls the minimum output accepted by the swap contract, based on the quote used to build the transaction. If a quote estimates 100 units of the output token and the tolerance is 1%, the transaction will generally specify a minimum near 99 units. The exact calculation depends on the protocol and transaction parameters.

Price impact and slippage are related but distinct. Price impact is the effect the trade itself has on the quoted exchange rate, given the liquidity and route. Slippage is the difference between an expected execution and the execution that occurs while the transaction is pending. A thin pool can give a trade high price impact before it is submitted; competing trades or a changing pool state can then move the execution further before inclusion.

For a multi-hop swap, each pool in the route contributes to the final output. The transaction typically enforces a minimum on the total output, rather than asking the user to set an independent tolerance for every hop. The route can also change between quote and submission. A new quote may improve the output, but a transaction already signed usually carries the parameters from the quote used to construct it.

How should frequent traders choose a setting?

Choose the narrowest tolerance that clears the price movement your trade normally encounters while it is pending. Start from the route’s liquidity, the token pair’s volatility, trade size and expected confirmation delay. A recurring swap in a deep market may need little room; a large trade through shallow pools or a fast-moving pair may need more. The same setting will not suit every route or market condition.

Use failed transactions as evidence about execution conditions, not as a reason to keep widening the setting automatically. A revert can mean the minimum output was no longer achievable. It can also result from other contract checks or a route-specific failure. Inspect the failure reason where available, refresh the quote, and compare the new minimum output with the amount you are willing to receive.

• Set a trade-specific floor. Decide the least output that still makes the swap acceptable, then compare it with the quote and tolerance before signing.
• Account for pending time. Congestion can leave a transaction exposed to pool changes for longer. A faster inclusion path may help, but it cannot guarantee the quoted output.
• Check the route and token. Multi-hop routes add pool state changes. Tokens with transfer taxes, rebasing behavior or other nonstandard transfer logic may not behave like ordinary ERC-20 assets.
• Requote when conditions change. A stale quote can make a tight minimum fail or leave an outdated route in the transaction. Review the current output and minimum before resubmitting.

For frequent swaps, a saved default can be convenient, but it should remain a ceiling on acceptable execution loss, not a shortcut around reviewing each trade. If a particular route regularly fails at a narrow setting, compare its liquidity, impact and pending behavior before choosing a wider limit. If the wider minimum would make the trade uneconomic, changing the trade size or waiting for conditions to improve is the cleaner choice.

Why can a wider setting change execution risk?

A wider tolerance lets the swap proceed after a larger adverse change in pool state. In public transaction flows, that can make more execution outcomes valid, including outcomes worsened by transactions that move the price before the swap. The tolerance alone does not prove that such ordering occurred, and a narrow setting does not prevent every form of unfavorable execution. It limits how far the transaction can move below its specified minimum output.

There is a direct trade-off. A tight minimum protects the output floor but raises the chance of a revert when the market moves. A loose minimum lowers that chance but accepts a larger range of outputs. Reverts can cost network fees even when the swap does not complete. Repeatedly resubmitting without refreshing the quote can add fees and leave multiple pending transactions to manage.

Keep the token approval and swap call distinct in your review. An approval grants a contract permission to transfer tokens up to an allowance; it does not set the swap’s minimum output. Verify the spender and allowance when approving, then inspect the swap’s token pair, route and stated minimum before signing. This is especially useful when a token’s transfer behavior or the router’s handling of it differs from standard assumptions.

The confirmed mechanism is that the swap’s minimum-output condition determines whether execution can complete at the resulting output; tolerance changes that bound and therefore the balance between reverts and accepted deterioration. The exact execution path, ordering against other transactions and behavior of a nonstandard token remain unverified until the transaction’s calldata, receipt and relevant on-chain state are examined.