How do basis points translate into a Jupiter slippage percentage?

One basis point equals 0.01%, so divide a basis-point value by 100 to express it as a percentage. Jupiter API parameters named slippageBps use basis points. A percentage input and a basis-point input therefore require different numeric values for the same tolerance. Check the unit before entering a number, especially when moving between an interface and an API.

Why can Jupiter price-impact fields show different numbers for the same percentage?

Jupiter API fields can express price impact in different units. In the Swap V2 order response, priceImpact uses percentage points, while the deprecated priceImpactPct field uses a decimal ratio. The build response also describes priceImpactPct as a decimal ratio. Compare the field definitions before interpreting a numerical difference as a change in execution quality.

Can favorable price movement produce more output tokens than the quote?

Execution can deliver more output than quoted when conditions improve and the route passes that improvement through. This is favorable, or positive, slippage. The minimum-output threshold sets a lower bound for an exact-input swap; it isn't a promise of favorable movement. Compare the actual token output with the quote associated with that transaction.

Does slippage tolerance protect a token's value after the swap?

Slippage tolerance constrains swap execution, not the token's later market value. Once the exchange completes, price changes can increase or decrease the value of the received tokens without changing their quantity. A later drop in the wallet's currency valuation therefore doesn't, by itself, show that the swap exceeded its slippage bound.

What happens to network fees when a swap exceeds its slippage limit?

An on-chain transaction that fails its slippage check can still incur network fees. Solana reverts the failed transaction's swap instructions, but charges fees for processed execution attempts. A quote error or simulation rejection before submission is different from an on-chain failure. The transaction record identifies which outcome occurred and the fee charged to its payer.

Jupiter swap slippage limits and execution trade-offs

Jupiter swap slippage measures the difference between quoted and received output for an executed token exchange. A tighter tolerance limits adverse movement, while a wider tolerance allows execution at a lower output. Neither setting improves the liquidity available for your trade. The useful starting point is the minimum amount you're prepared to receive, compared with the transaction's minimum output. Trade size, price impact and delays help explain whether changing tolerance addresses the problem. A slippage error can mean the protection worked. Raising the limit makes sense only when the newly permitted output remains acceptable.

Updated on 2026 September 15

Quoted output and the amount execution delivers

For a swap with a fixed input amount, Jupiter quotes output for the selected tokens and available route. The transaction applies a slippage bound to that quote. Execution then encounters the liquidity and prices available when the transaction runs. Those conditions can differ from the conditions behind the preview.

The expected output, minimum output and received amount answer different questions. Expected output describes the quote; minimum output expresses the permitted downside relative to it. The execution result records what the swap delivered. Compare amounts for the same output token and input quantity, with fees treated consistently. If a fee comes out of the output token, distinguish the route's output from the amount credited to your wallet. A wallet's changing currency valuation doesn't measure token slippage, because market prices can change after receipt.

Minimum output and price-impact warnings

The minimum-output field defines the execution bound, while the price-impact warning helps you assess the quoted price.

Output floor

For an exact-input swap, the output floor is approximately the quoted output multiplied by one minus the tolerance expressed as a fraction. Token precision and transaction construction determine the exact integer threshold. Jupiter API responses use otherAmountThreshold for the minimum output after slippage. Read the returned threshold rather than treating a rounded percentage calculation as the transaction's exact terms.

View full-size image

Price-impact warning

Price impact describes how the proposed trade affects its execution price through available liquidity. That effect can already appear in the quote before any later movement occurs. A low slippage tolerance therefore doesn't make a high-impact quote attractive. Inspect the warning alongside the quoted exchange rate and amount. Increasing tolerance changes how much further deterioration you permit; it doesn't remove the impact already embedded in the proposed trade.

When does a tighter slippage limit help?

A tighter limit helps when preserving minimum output matters more than completing the swap through adverse price movement. For a fixed exact-input quote, reducing slippage tolerance raises the minimum permitted output. Execution has less room to absorb changes between quoting and processing. Even modest movement can then cause a slippage failure.

Choosing a narrow bound means accepting that some attempts won't execute. That can be the intended outcome when a lower fill would defeat the exchange's purpose. There isn't one percentage suitable for every token pair and amount. The relevant comparison is between the transaction's output floor and your acceptable output, with the quote's existing price impact considered separately.

Trade size against available liquidity

A larger trade relative to usable liquidity can consume progressively less favorable prices along its route. The same token pair can therefore produce different exchange rates at different sizes. Liquidity near the prices your trade reaches matters more directly than a token's popularity or aggregate trading volume.

Reducing the proposed amount can lower its price impact. A fresh quote shows whether that improvement exists for the available route.

Trade size against available liquidity: A larger trade relative to usable liquidity can consume progressively less favorable prices along its route. The same token pair can therefore produce different exchange rates at different sizes.; Liquidity near the prices your trade reaches matters more directly than a token's popularity or aggregate trading volume.

View full-size image

Compare output per input token when assessing different sizes, alongside the impact estimate and applicable charges. Comparing total output alone says little because a smaller input naturally buys fewer tokens. Route selection can also change with size, so don't assume a proportional result. This quote comparison can happen before signing and doesn't require paying for a test swap.

Splitting a trade doesn't guarantee a better combined result. Earlier fills can move the same liquidity, while separate transactions add costs and market exposure.

Automatic estimation and fixed tolerance

Jupiter's automatic estimation and a manually fixed tolerance express the output constraint in different ways. Their availability depends on the integration.

Automatic estimation

Jupiter's Real-Time Slippage Estimator, or RTSE, uses execution data and market conditions to estimate tolerance. RTSE sets the estimated tolerance when Jupiter creates the order or builds the transaction. The estimate becomes part of the transaction. It doesn't continuously revise an already signed transaction as prices change. An automatically chosen bound still needs to fit the output you're willing to accept.

Fixed tolerance

In Swap V2, the managed order flow applies RTSE automatically unless a fixed slippage value overrides it. The custom transaction builder supports RTSE as an explicit option. A fixed value provides a chosen bound without relying on automatic estimation. Neither method guarantees execution, and settings from an older tutorial may describe a different API or interface.

Does wider tolerance increase the cost of every swap?

A wider tolerance permits a worse fill, but it doesn't automatically deduct the entire tolerance from every swap. Actual slippage depends on execution. When the trade fills close to its quote, the unused allowance doesn't become a separate slippage charge. Swap fees and network charges remain separate cost components with their own calculation rules.

The larger allowance still increases the adverse movement a transaction can accept. Where transaction ordering enables a sandwich attack, an attacker trades around the victim's swap to worsen its price. A wider bound can leave more room for that deterioration. Routing and transaction delivery affect exposure, so a tolerance percentage alone doesn't establish protection against transaction-ordering attacks.

Quote age and delays before execution

A quote becomes less representative when liquidity changes before execution, even if the selected input remains unchanged. Other trades can alter pool balances during wallet review or transaction delivery. Avoidable delays increase the interval in which that movement can happen. Faster delivery can reduce exposure to changing conditions, although speed doesn't guarantee a particular fill.

Refreshing a quote updates the reference amount used to assess tolerance. It can also reveal a worse starting price. Keeping the same percentage after that refresh doesn't preserve the minimum output from the previous quote. Compare the new token amount directly with your acceptable floor. A fresh quote improves the information available for a decision; it doesn't restore earlier market conditions.

A minimum-output decision after a slippage error

Consider a hypothetical exact-input swap with a confirmed slippage failure. A refreshed quote offers 842 output tokens, and the intended exchange requires at least 836. Assume the output token supports the decimal precision shown and no additional fee comes out of these output amounts. These amounts and tolerances illustrate the boundary; they aren't recommended settings.

View full-size image

Confirm the earlier attempt failed with a slippage error. An unresolved submission requires a status check before another approval.
Refresh the quote without signing and inspect its price impact. If impact is unacceptable, compare a smaller input before changing tolerance.
At 0.5% tolerance, the calculated floor is 842 × 0.995 = 837.79 tokens. That remains above the required 836.
At 1% tolerance, the floor falls to 842 × 0.99 = 833.58 tokens. That would permit an output below the requirement, so decline those terms.
If an acceptable quote and threshold support another attempt, review them before signing. After successful execution, reconcile the actual output with the approved threshold.

The narrower option meets this output requirement but can still fail during adverse movement. If no available quote provides an acceptable floor, wait or compare quotes for a different input amount before signing. Changing the amount also requires reconsidering the output requirement because it represents a different exchange.

Slippage failures and errors tolerance cannot fix

A slippage failure identifies a pricing constraint, whereas missing liquidity and insufficient funds require different responses. Jupiter's swap program uses SlippageToleranceExceeded for an exceeded slippage bound. Widening that bound may address this particular constraint if the lower permitted output remains acceptable.

A no-route message means the requested exchange lacks an available route under its conditions. A wider tolerance doesn't create liquidity or make an unsupported token tradable. Insufficient funds can concern the input amount, transaction charges or account funding. Read the actual error before changing settings. Even a successfully executed swap only establishes that execution satisfied its programmed conditions; it doesn't establish that the accepted price suited your objective.

Everyday questions about Jupiter swap slippage

How do basis points translate into a Jupiter slippage percentage?: One basis point equals 0.01%, so divide a basis-point value by 100 to express it as a percentage. Jupiter API parameters named slippageBps use basis points. A percentage input and a basis-point input therefore require different numeric values for the same tolerance. Check the unit before entering a number, especially when moving between an interface and an API.
Why can Jupiter price-impact fields show different numbers for the same percentage?: Jupiter API fields can express price impact in different units. In the Swap V2 order response, priceImpact uses percentage points, while the deprecated priceImpactPct field uses a decimal ratio. The build response also describes priceImpactPct as a decimal ratio. Compare the field definitions before interpreting a numerical difference as a change in execution quality.
Can favorable price movement produce more output tokens than the quote?: Execution can deliver more output than quoted when conditions improve and the route passes that improvement through. This is favorable, or positive, slippage. The minimum-output threshold sets a lower bound for an exact-input swap; it isn't a promise of favorable movement. Compare the actual token output with the quote associated with that transaction.
Does slippage tolerance protect a token's value after the swap?: Slippage tolerance constrains swap execution, not the token's later market value. Once the exchange completes, price changes can increase or decrease the value of the received tokens without changing their quantity. A later drop in the wallet's currency valuation therefore doesn't, by itself, show that the swap exceeded its slippage bound.
What happens to network fees when a swap exceeds its slippage limit?: An on-chain transaction that fails its slippage check can still incur network fees. Solana reverts the failed transaction's swap instructions, but charges fees for processed execution attempts. A quote error or simulation rejection before submission is different from an on-chain failure. The transaction record identifies which outcome occurred and the fee charged to its payer.