Does a Higher Tolerance Increase the Pool's Trading Fee?

Increasing slippage tolerance does not by itself raise the trading fee charged by a given pool. The fee belongs to the selected pool and route; tolerance governs the amount you accept. A newly selected route can use different pools with different fees, so a changed fee estimate requires its own comparison.

Can a Swap Deliver More Than Its Quoted Output?

An ordinary pool-based exact-input swap can return more output than the earlier quote when pool conditions improve before execution. Its minimum-output check establishes a floor, not a cap. The actual output follows the executed swap's calculation. The tolerance percentage does not require execution to land exactly at the floor.

How Does Slippage Protection Change for an Exact-Output Swap?

An exact-output swap fixes the requested output and uses a maximum input amount to bound unfavorable execution. Where the chosen interface and route support this mode, the router rejects execution that requires more input than the encoded maximum. The V3 periphery SwapRouter's single-pool exact-output method can deliver less than requested if a nonzero pool-price limit stops the swap early.

Is Zero Slippage a Guarantee of Successful Execution?

A zero tolerance does not guarantee successful execution. It removes the adverse buffer allowed by the chosen calculation, making execution more sensitive to intervening pool changes. Execution may still succeed if the swap meets its quoted output requirement. Deadline expiry, insufficient spending permission, and token transfer failures remain separate causes of rejection.

Will Changing the Slippage Setting Modify a Pending Swap?

Changing the website's slippage setting does not alter the output floor in an already signed, submitted transaction. That floor is part of the transaction's encoded call data. A replacement is a different transaction subject to wallet and network rules. Until the original or replacement resolves, a settings change alone establishes no execution result.

Are Gas Fees Refunded After a Slippage Revert?

An included EVM transaction that reverts still incurs the gas cost of its execution. Reverting undoes the swap's state changes, while the network charges for transaction processing. A quote request or simulation that fails before on-chain submission does not create that execution charge.

Pancakeswap slippage tolerance sets a minimum output for exact-input swaps

Pancakeswap slippage tolerance limits how far an exact-input automated market maker (AMM) swap can move below its quote in output-token terms. The transaction specifies a minimum output amount, and execution below that amount causes the protected swap to revert. The quote already reflects the selected route and trade size; tolerance controls the additional unfavorable movement that you authorize.

Updated - Wednesday, 7 October 2026

Comparing execution quality requires consistent token units and fee treatment. A displayed tolerance percentage cannot establish how much pool depth or later market movement reduced the output; the encoded floor states which deterioration the swap permits.

Quotes, Price Impact, and the Output Floor

A quote estimates output for a specific input and route at a particular pool state. Its average exchange rate equals quoted output divided by input, using each token's displayed units. Pool liquidity and the fee that the pool charges determine that estimate, while price impact describes the trade's effect on pool pricing. For a size-specific quote, that effect already influences the expected output. The route can involve successive pools or split the input across multiple paths. Slippage compares execution with the earlier quote, while tolerance defines the permitted adverse difference.

Other trades and liquidity changes can alter the available output while the transaction waits. Shallow liquidity can magnify the price response to trading. A wider tolerance permits a lower output floor for the same quote. It does not change the liquidity available in those pools. Route impact can therefore remain expensive even when a swap passes its minimum-output check.

How Is Minimum Swap Output Calculated?

Minimum output is an integer token amount derived from the quote and the selected tolerance, using the swap implementation's calculation. Let Q denote quoted output in the output token's smallest units and s denote tolerance expressed as a nonnegative fraction.

The V3 software development kit (SDK) implements minimumAmountOut as M = floor(Q / (1 + s)) for exact-input trades. Here, M is the minimum output, and floor rounds downward to a whole smallest unit. A larger s lowers M for an unchanged quote.

That convention differs from subtracting a permitted percentage directly from output, which gives M = floor(Q × (1 - s)). Before rounding, the first convention bounds an increase in input per output; the second bounds a decrease in quoted output. The value encoded by the selected swap method governs execution; a percentage label does not replace that amount.

The allowed shortfall from the quote equals Q - M. Dividing that difference by Q expresses it as a fraction of quoted output, provided Q is positive. This comparison uses the same token and units on both sides.

Token decimals convert the raw floor into its displayed token amount, and integer rounding can affect the smallest units. The floor protects a token quantity, so later changes in fiat valuation remain outside that constraint.

Which Records Confirm the Actual Swap Output?

A transaction's successful receipt and final recipient's asset movements establish its realized output on an Ethereum Virtual Machine (EVM) network. For conventional token output, inspect the transfer to the recipient and its decimal scale. Native-currency output requires the native transfer rather than an ERC-20 transfer event. An intermediate pool event may describe an earlier hop. Transfer-tax deductions can make gross amounts differ from the recipient's credited amount. A pending transaction hash does not establish received tokens.

Swap Fields That Carry the Limits

The EVM V3 periphery SwapRouter's exactInputSingle method accepts explicit fields for the output floor, destination, and expiry.

Swap Fields That Carry the Limits
Parameter	Value Carried	Purpose	Control
`amountIn`	Specified input amount in smallest units	Sets the input budget	Caller supplies the amount
`amountOutMinimum`	Integer output-token floor	Bounds acceptable output	Router enforces the caller's minimum
`tokenIn`	Selected input-token contract address	Identifies the spending asset	Caller chooses the asset
`tokenOut`	Selected output-token contract address	Identifies the output asset	Caller chooses the asset
`recipient`	Encoded receiving address	Selects the output destination	Caller sets the recipient
`deadline`	Unix timestamp in seconds	Sets the expiry boundary	Router enforces the caller's expiry

V2 names its output floor amountOutMin and carries the token path as an address array. The V3 single-pool method also accepts a pool fee tier and a pool-price limit. Reaching that price limit can leave part of the specified input unspent; the minimum-output check still applies. Its deadline constrains when execution may occur; it does not hold the original pool state unchanged. A wallet's token allowance is a separate spending permission, and widening slippage does not grant that allowance.

When Does a Swap Fail Its Minimum-Output Check?

A protected exact-input swap fails its minimum-output check when execution produces less output than the transaction's encoded floor. The V3 exact-input router enforces amountOut >= amountOutMinimum. A revert rolls back that swap's token exchange, although the error wording varies across router implementations.

An output-floor rejection, an expired deadline, and a token transfer failure require different corrections. A simulation error can prevent submission; a mined revert records unsuccessful execution. Before a retry, inspect the failed call's floor, timestamp condition, and transfer error. Quote freshness matters because pool state can change between a failed attempt and a new transaction.

If excess price impact caused the poor rate, a smaller input or another supported route changes the liquidity demand. Raising tolerance changes the acceptance boundary instead. Compare each proposed swap by its minimum output per unit of input, using the same output token. Token transfer fees require a compatible method. For V2 fee-on-transfer swaps ending in an ERC-20-compatible token, the output-floor check uses the recipient's output-token balance increase. A wider tolerance cannot remove a token's transfer restriction.

Tolerance Choices and Transaction Exposure

Manual tolerance applies the percentage chosen for a quote; Auto Slippage calculates a setting on supported Layer 1 (L1) networks from estimated gas cost and the output's value, so it can change across quotes. On Layer 2 (L2) networks, your previous setting applies, or the default if you have not set one. A wider setting lowers the floor without improving the quoted route. A sandwich attack places trades before and after a victim's swap to profit from the resulting price movement. Public pending transactions can expose the swap's acceptable boundary to that activity. Tightening the floor limits acceptable deterioration, but it does not make transaction submission private.

View image file

Pancakeswap slippage: quick answers

Does a Higher Tolerance Increase the Pool's Trading Fee?: Increasing slippage tolerance does not by itself raise the trading fee charged by a given pool. The fee belongs to the selected pool and route; tolerance governs the amount you accept. A newly selected route can use different pools with different fees, so a changed fee estimate requires its own comparison.
Can a Swap Deliver More Than Its Quoted Output?: An ordinary pool-based exact-input swap can return more output than the earlier quote when pool conditions improve before execution. Its minimum-output check establishes a floor, not a cap. The actual output follows the executed swap's calculation. The tolerance percentage does not require execution to land exactly at the floor.
How Does Slippage Protection Change for an Exact-Output Swap?: An exact-output swap fixes the requested output and uses a maximum input amount to bound unfavorable execution. Where the chosen interface and route support this mode, the router rejects execution that requires more input than the encoded maximum. The V3 periphery SwapRouter's single-pool exact-output method can deliver less than requested if a nonzero pool-price limit stops the swap early.
Is Zero Slippage a Guarantee of Successful Execution?: A zero tolerance does not guarantee successful execution. It removes the adverse buffer allowed by the chosen calculation, making execution more sensitive to intervening pool changes. Execution may still succeed if the swap meets its quoted output requirement. Deadline expiry, insufficient spending permission, and token transfer failures remain separate causes of rejection.
Will Changing the Slippage Setting Modify a Pending Swap?: Changing the website's slippage setting does not alter the output floor in an already signed, submitted transaction. That floor is part of the transaction's encoded call data. A replacement is a different transaction subject to wallet and network rules. Until the original or replacement resolves, a settings change alone establishes no execution result.
Are Gas Fees Refunded After a Slippage Revert?: An included EVM transaction that reverts still incurs the gas cost of its execution. Reverting undoes the swap's state changes, while the network charges for transaction processing. A quote request or simulation that fails before on-chain submission does not create that execution charge.