Does Zero Slippage Tolerance Guarantee the Quoted Output?

Zero tolerance removes the allowance for an adverse output shortfall in a fixed-input order, but it does not guarantee execution. Market movement can cause the swap to fail its output check. Other requirements, including transaction validity and sufficient funding, still apply. An unchanged quote also does not establish that the network will process the transaction.

Is Minimum Received a Guaranteed Fiat Value?

Minimum received protects an amount of the output token, not its value in a fiat currency. The token's market value can change independently of the swap's output check. A successful trade that satisfies the token floor can therefore have a different fiat valuation from the estimate shown when the quote appeared.

Can Favorable Slippage Deliver More Than the Quote?

A fixed-input minimum-output check allows output above the quote because it sets a lower bound. Favorable execution can therefore deliver more tokens than expected. To identify favorable execution, compare quoted and received amounts with the same fee treatment. A higher wallet valuation caused only by a changing token price does not establish favorable swap execution.

Why Can an API Threshold Have More Digits Than the Wallet Display?

API token amounts can use integer values in the token's smallest units, while wallets display decimal token quantities. Converting a raw threshold to whole-token units requires the output token's decimal precision. The extra digits do not imply a larger slippage allowance. Comparing values before applying the same precision can produce a misleading difference.

Will Changing a Browser Setting Update an Already Signed Swap?

Changing a browser setting does not modify the slippage constraint inside an already signed transaction. A different constraint requires a transaction that encodes the new terms and a corresponding signature. A previously signed transaction may remain valid, and an already submitted transaction can still execute. Replacing the screen's setting does not cancel that earlier authorization.

Does a Pending Transaction Confirm the Minimum Received Amount?

A pending transaction does not establish successful execution or a final token receipt. The minimum-output check matters when the swap executes, and a transaction identifier alone does not prove that it passed. A successful confirmed transaction establishes the executed outcome; its output amounts still need the same accounting scope as the quote for comparison.

Jupiterswap slippage tolerance sets the minimum acceptable output for a fixed-input swap.

Last updated - October 7th, 2026

Jupiterswap slippage is the difference between the quoted output and the amount received from a Jupiter swap. For a fixed-input trade, the tolerance determines how far output may fall before the swap fails its minimum-output check. Minimum received expresses the output boundary that applies if the swap succeeds. Price impact affects the quote itself, while later market movement can change execution.

Fixed Input and Fixed Output Bounds

A fixed-input swap suits a specified spending amount, while a fixed-output swap serves a specified receiving amount where the integration supports that mode. The distinction determines which side carries the slippage allowance.

ExactIn and the Output Floor

Jupiter Swap API V2's managed order path supports ExactIn. The input amount stays specified, and the minimum output protects the receiving side. Expected output is an estimate; minimum output is a lower bound, even when both appear beside the same quote.

ExactOut and the Input Ceiling

The older Metis Swap API V1 supports ExactOut through compatible liquidity venues. That mode targets an output amount and applies slippage to the input token. Its relevant protection is a maximum input allowance. V1 is no longer actively maintained and has been superseded by Swap V2, so its ExactOut support does not establish availability in the V2 managed order path.

What Does Minimum Received Actually Promise?

Minimum received states the lowest acceptable output for a successful fixed-input swap under the transaction's applicable output check. Execution below that bound causes a failure.

The quote estimates output from the selected liquidity and trade size. The tolerance creates an allowance beneath that estimate. A larger allowance lowers the floor for the same quote, admitting worse execution that a tighter setting would reject. The tolerance does not reserve those tokens or require execution at the floor.

Protection depends on the transaction that carries the constraint. An earlier screen estimate can differ from a refreshed order. The quoted amount, tolerance, and minimum output need to belong to the same order for their relationship to make sense.

The floor also has a limited scope: it constrains the swap's output amount. Separately funded network charges can change another balance without violating that output check. This distinction matters when a wallet shows the economic effect of the whole transaction beside the tokens received.

Tolerance Versus Price Impact

Price impact describes how the proposed trade changes the available execution price relative to the market reference that the quote uses. Slippage tolerance controls acceptable deterioration from the quoted output.

An automated market maker prices a trade using its liquidity and pricing rules. A larger trade relative to available depth can produce a worse rate within the quote itself. Increasing tolerance does not restore that rate or add liquidity. It permits a larger additional output shortfall after the quote. A small slippage setting can therefore coexist with substantial quoted price impact. Trading fees are another input to net output. Keep their treatment consistent when comparing quotes: a fee that the quote already includes should not enter a second deduction.

Quote Movement Before Execution

A quote can become economically stale while its transaction remains valid, because other trades and liquidity changes alter the state that execution will encounter.

The delay includes time spent reviewing the order and time awaiting network processing. A fresh estimate reduces reliance on an older market snapshot, although it cannot freeze liquidity. Transaction validity only answers whether the transaction remains eligible for processing. It does not establish that the available output still meets the minimum.

In Swap V2, aggregator orders use the returned lastValidBlockHeight as their hard transaction expiry. JupiterZ request-for-quote orders use expireAt for the market maker's quote expiry. These are different validity boundaries. Increasing tolerance cannot extend an expired order, and an unexpired order can still fail its output check. A refreshed order also has its own pricing and validity information.

Why Does Increasing Tolerance Not Fix Every Failure?

Increasing tolerance only relaxes the applicable price bound; funding problems, expired orders, missing routes, and account errors require different corrections.

Output Below the Bound

The Jupiter Swap Program identifies a failed slippage check with error 6001, SlippageToleranceExceeded. A fresh quote can reveal the changed output before a new tolerance decision. The recorded error identifies the failing constraint; a general failure message alone does not.

A Solana transaction that fails during execution rolls back its instruction changes. The fee payer can still incur transaction charges. Slippage rejection therefore protects against the prohibited swap outcome without making every processed failure cost-free.

Expiry and Missing Liquidity

An expired transaction needs renewed transaction data. A missing route means the requested exchange lacks an available route under its routing conditions. A wider output allowance resolves neither problem.

Funding and Account Errors

The spending balance, transaction funding, and required accounts must satisfy their own constraints. If the fee payer lacks funds or an account is invalid, lowering the output floor does not supply funds or repair the account.

Calculating the Output Floor

The proportional relationship uses the quoted output Q and a tolerance fraction s: before token-unit rounding, minimum output M = Q × (1 − s).

A percentage tolerance converts to a fraction by dividing by 100. A basis-point value b converts through s = b ÷ 10 000. One basis point equals 0.01%. Those are unit conversions, not a recommended tolerance or a statement about a default setting. The returned minimum amount resolves the exact token-unit rounding for the order.

For comparable output amounts, the realized shortfall percentage equals 100 × (Q − R) ÷ Q, where R is received output and Q is positive. Both amounts must describe the same token and accounting scope. Comparing a gross estimate with a net credit that includes separate deductions can incorrectly label those deductions as slippage.

How Should Automatic and Fixed Tolerance Be Chosen?

Automatic estimation suits a tolerance that follows execution conditions, while a fixed setting suits an explicit acceptance limit that the reader wants to control.

Jupiter's Real-Time Slippage Estimator, or RTSE, considers historical and real-time execution data, token characteristics, and failure rates. Swap V2's managed order path applies it automatically unless a numeric slippageBps override sets a fixed tolerance. The custom Router build path enables RTSE through slippageBps=rtse. Interfaces can expose different controls. RTSE estimates the allowance when the order or build request runs. The resulting transaction carries that allowance; automatic estimation does not continually rewrite a signed transaction. Either choice still needs an acceptable minimum output. A value that improves execution success can also permit a larger shortfall.

Visual outline: How Should Automatic and Fixed Tolerance Be Chosen? (Jupiterswap slippage) — How Should Automatic and Fixed Tolerance Be Chosen?

Open full-size image

Minimum Output and the Final Wallet Credit

The final wallet credit and a swap-level output amount require matching accounting before either can measure slippage. A fee charged in the receiving token can affect that comparison differently from a network charge paid by another account. Jupiter order responses identify fee amounts and fee payers separately from expected output. The relevant question is which deductions the displayed quote and reported receipt already include. Comparing consistent net amounts avoids counting one charge twice or attributing it to market movement.

Slippage Exposure and Transaction Delivery

A wider tolerance gives adverse execution more room to pass, including price deterioration caused by transactions that trade around the same liquidity.

Open full-size image

A sandwich attack places trades around another swap to extract value from its price movement. The minimum-output condition constrains the amount that the protected swap can accept, but it does not establish that the transaction was private or free from extraction. Delivery infrastructure and slippage limits address different parts of that exposure. Faster landing can shorten the interval for market movement; it cannot ensure that available liquidity remains unchanged.

Reviewing the Output Bound Before Signing

An unsigned fixed-input order allows comparison without authorizing a swap. Hold the token pair, input amount, and quoted output constant while considering a tighter tolerance and a wider tolerance.

Confirm that ExactIn governs the order, so the amount under review is an output floor.
With the tighter setting, compare the higher minimum output against the amount that would make the exchange acceptable.
With the wider setting, compare the lower minimum output against that same acceptance condition.
Keep price impact and quoted fees unchanged in the comparison; widening tolerance does not reduce those cost inputs.
Stop before signing if minimum output falls below the acceptable receipt or separately funded transaction charges exceed the accepted budget.

The tighter choice rejects more adverse price movement and can produce more failures that incur network charges. The wider choice admits more movement and exposes the trade to a larger output shortfall. A changed route or quote requires a fresh comparison of its output floor and charges. Neither setting commits an unsigned order. Signing authorizes the transaction, and submission makes execution possible, even when a wallet combines these actions.

Liquidity Choices Before a Wider Allowance

Changing trade size or available routing can alter the quoted execution rate, while widening tolerance changes which deterioration the transaction will accept.

A smaller input may reduce price impact relative to the available liquidity, although it also purchases a smaller quantity. Restricting routing can remove useful liquidity and worsen pricing. These choices affect the quote before its slippage allowance applies.

Eligible JupiterZ RFQ routes use a market maker's firm quote, with the fill committed at its quoted price. Availability and quote expiry still matter. A pool-based route faces changing liquidity between quote and execution; a firm RFQ quote addresses that price uncertainty differently. Comparing the returned route and minimum output provides a clearer choice than widening tolerance against an already unacceptable quote.

Jupiterswap slippage questions worth asking

Does Zero Slippage Tolerance Guarantee the Quoted Output?: Zero tolerance removes the allowance for an adverse output shortfall in a fixed-input order, but it does not guarantee execution. Market movement can cause the swap to fail its output check. Other requirements, including transaction validity and sufficient funding, still apply. An unchanged quote also does not establish that the network will process the transaction.
Is Minimum Received a Guaranteed Fiat Value?: Minimum received protects an amount of the output token, not its value in a fiat currency. The token's market value can change independently of the swap's output check. A successful trade that satisfies the token floor can therefore have a different fiat valuation from the estimate shown when the quote appeared.
Can Favorable Slippage Deliver More Than the Quote?: A fixed-input minimum-output check allows output above the quote because it sets a lower bound. Favorable execution can therefore deliver more tokens than expected. To identify favorable execution, compare quoted and received amounts with the same fee treatment. A higher wallet valuation caused only by a changing token price does not establish favorable swap execution.
Why Can an API Threshold Have More Digits Than the Wallet Display?: API token amounts can use integer values in the token's smallest units, while wallets display decimal token quantities. Converting a raw threshold to whole-token units requires the output token's decimal precision. The extra digits do not imply a larger slippage allowance. Comparing values before applying the same precision can produce a misleading difference.
Will Changing a Browser Setting Update an Already Signed Swap?: Changing a browser setting does not modify the slippage constraint inside an already signed transaction. A different constraint requires a transaction that encodes the new terms and a corresponding signature. A previously signed transaction may remain valid, and an already submitted transaction can still execute. Replacing the screen's setting does not cancel that earlier authorization.
Does a Pending Transaction Confirm the Minimum Received Amount?: A pending transaction does not establish successful execution or a final token receipt. The minimum-output check matters when the swap executes, and a transaction identifier alone does not prove that it passed. A successful confirmed transaction establishes the executed outcome; its output amounts still need the same accounting scope as the quote for comparison.