Jupiter swap
Jupiter swap: Slippage Settings and Execution Details
Jupiter swap lets you set manual slippage to limit how far execution can move against the quoted output. Review the resulting minimum receipt before signing, then match the completed transaction to the destination token balance. Increasing tolerance permits a worse execution price; it doesn't improve the quote.
Bottom line: A slippage setting limits acceptable execution deterioration; the completed transaction shows whether the exchange succeeded and how many tokens arrived.
Liquidity and token restrictions behind the quote
Available liquidity and the selected trade amount shape the output that Jupiter quotes before slippage tolerance applies. A larger trade relative to pool liquidity can produce greater price impact. Token trading restrictions can also prevent a usable exchange. These conditions require different responses: a wider tolerance permits more execution movement, while changing the amount requests different terms. Neither adjustment removes a token restriction. Check the selected token's mint address and any displayed warnings before interpreting its quoted output.
How should I choose manual slippage?
Choose manual slippage by evaluating the minimum output you're willing to accept for the quoted input. A tighter tolerance gives less room for adverse movement and can cause execution to fail when prices change.
The minimum receipt
For a swap with a fixed input, slippage tolerance applies to the output amount. The expected output describes the quote; the minimum output describes the execution boundary. Review both together. A quote can already include substantial price impact before the tolerance allows any further deterioration. Selecting a small tolerance doesn't make that initial quote favorable, and choosing a larger tolerance doesn't promise that execution will consume the entire allowance.
The minimum receipt is a token quantity. It doesn't establish the token's future market value.
The trade-off when tolerance changes
With the same quoted output, raising tolerance lowers the acceptable minimum; lowering tolerance raises it. Volatility, liquidity, and the delay before execution affect whether the transaction can satisfy the limit. When the interface refreshes the quote, evaluate its new minimum receipt. The same percentage can apply to a different token quantity because the underlying quote has changed.
Automatic estimates and other swap controls
Automatic slippage estimation chooses a tolerance using market information, while manual slippage lets you supply a fixed value. Priority fee settings and routing exclusions address separate parts of the exchange.
Automatic slippage estimation
Jupiter's Real-Time Slippage Estimator calculates tolerance when it creates the order and embeds that tolerance in the transaction. Automatic estimation considers token characteristics, historical and live slippage data, and transaction failure rates. It doesn't continuously rewrite a transaction after signing. Compare the estimated allowance with the minimum output you accept before authorizing the swap.
Priority fees and routing exclusions
A priority fee affects transaction scheduling, while routing exclusions remove selected execution options from consideration. Neither control replaces the output limit. Where the interface exposes these settings, compare the refreshed quote after changing them. Excluding a router can change the available pricing; increasing the priority fee doesn't create liquidity or remove a token restriction. Manual settings describe your configuration, not proof that a particular router executed the trade.
| Parameter | Configured value | Effect on the exchange |
|---|---|---|
| Slippage tolerance | A manually selected percentage or an automatic estimate | Sets the acceptable output deterioration for the transaction |
| Priority fee strategy | The selected fee strategy or amount, where exposed | Affects transaction scheduling, without changing the slippage limit |
| Routing exclusions | The selected routers or venues to exclude, where exposed | Restricts which execution options can compete for the quote |
| Use the values attached to the proposed swap; none of these controls establishes the actual tokens received. | ||
Change a control for the specific condition it addresses. An execution error and an unfavorable quote don't necessarily call for the same adjustment.
Terms to inspect before signing
The proposed transaction must match the intended input token, input amount, output token, and acceptable minimum receipt. Token names alone don't establish identity. The selected mint address identifies the asset, while the destination account determines where the output belongs. Inspect these details before authorization, especially when multiple tokens share a ticker.
Keep enough balance for any fees or account creation costs that the proposed transaction assigns to your wallet. Fee sponsorship can change who pays, so the displayed transaction requirements matter more than a blanket balance assumption. A quote that shows an output amount also doesn't prove that Jupiter successfully built a transaction. If the interface reports a construction or simulation error, resolve that condition before signing. Increasing slippage won't correct every preparation failure.
Which transaction details verify the tokens received?
The transaction's execution status and destination token balance changes verify whether the swap succeeded and what arrived. A signature identifies the transaction, but its presence alone doesn't prove successful execution.
The execution status
Use the transaction associated with the signed swap, rather than a previous trade involving the same tokens. Its status distinguishes successful execution from an error. A pending display leaves the outcome unresolved. Repeating the exchange while that outcome remains uncertain can produce another purchase or sale if both transactions eventually succeed.
The destination balance change
Solana transaction metadata can include token balances from before and after execution. Match those entries to the output mint and receiving account, then interpret amounts using the token's decimal precision. An account created during execution may lack a corresponding earlier token balance entry. Transfers within the route can involve intermediate accounts, so an arbitrary transfer amount doesn't necessarily equal the wallet's receipt.
Compare the resulting output with the minimum attached to that transaction, using the same token and units. A later wallet balance can include other transfers, while its displayed currency valuation reflects pricing information. Neither substitutes for the balance change caused by this particular swap. If the output arrives as native SOL, inspect the receiving account's SOL balance change rather than looking only for token balance entries. When reconciling the wallet's balance movement, separate the swap receipt from network fees, account creation costs, rent refunds, and any other transfers within the transaction.
Failure reasons that justify a settings change
A slippage error identifies an output constraint that execution couldn't satisfy. A fresh quote may show different terms, but widening tolerance deliberately permits a lower receipt. Insufficient funds, token restrictions, and transaction construction errors require their own corrections. Preserve the failed transaction's details so an adjustment answers the reported problem rather than changing unrelated controls.
Solana's optional priority fee increases the likelihood that a leader schedules a transaction ahead of competing transactions. It doesn't guarantee successful execution. Choose between a fee adjustment and a slippage adjustment by identifying whether scheduling or the output constraint caused the difficulty. A successful transaction must still satisfy its swap instructions. The final comparison remains the same token quantity: actual receipt against the transaction's minimum output.
Still wondering about Jupiter swap?
Does slippage tolerance count as an extra Jupiter swap fee?
Slippage tolerance is an execution allowance, not a separate fee charged at the selected percentage. Actual execution can use less than that allowance. Fees have their own amounts and calculation bases, so adding the tolerance percentage to the displayed fee percentage doesn't establish the swap's actual cost.
What does a basis-point slippage value mean?
One basis point equals 0.01 percentage points, so divide a basis-point value by 100 to express the same tolerance as a percentage. This unit conversion matters when comparing a transaction or integration field with an interface percentage; it doesn't establish a recommended setting or a default.
Can changing slippage affect a transaction I've already signed?
Changing an interface setting doesn't alter the transaction you've already signed. The signature authorizes that transaction's message, including its instructions. Different execution terms require a newly prepared transaction and authorization. Establish the original transaction's outcome before submitting another exchange, since an interface change doesn't cancel the original.
Why did a failed swap still incur a network fee?
A transaction that reaches execution can incur a network fee even when its swap instructions fail. The fee pays for transaction processing rather than successful token delivery. A rejected wallet request or an unsubmitted transaction is a different state, so inspect the execution record before attributing a balance reduction to a failed swap.
Is minimum output a way to buy an exact token amount?
Minimum output is a lower execution bound, not a request for an exact receipt. Jupiter's swap interface removed its previous exact-output option. A fixed-input swap determines the amount spent and quotes the expected receipt, with slippage defining the acceptable downside. The completed output can therefore differ from the minimum.
Which settings help when Jupiter says some routes failed to load?
An RPC connection problem can prevent Jupiter from refreshing route pricing and cause that message. The interface blocks the swap to avoid using stale pricing. Try changing the RPC endpoint, the server connection used to access network data, through Jupiter's settings, then refresh the page. Once route pricing loads, review the refreshed quote and minimum output before retrying. Widening slippage doesn't repair that connection. This condition differs from a quote that loads successfully but fails its output limit.