Jupiter swap slippage - Minimum output, quote changes, and failed transactions
Jupiter swap slippage measures the difference between quoted and executed output, while slippage tolerance sets the permitted adverse movement for a swap. For an exact-input transaction, execution fails if the output cannot meet its minimum received requirement. Diagnosing that failure starts with the affected quote, its age, the route’s liquidity, and the actual transaction error.
Receiving fewer tokens than quoted and having a transaction rejected require different explanations. A successful transaction record confirms that the exchange completed; a slippage rejection shows that an output condition failed. Keep the original quote and transaction details together before changing any settings.
The short version: A slippage failure means the transaction rejected unacceptable output; widening the tolerance permits a worse fill without repairing the underlying price change.
A quoted amount followed by a rejected swap
A displayed quote can remain visible even after market movement makes its minimum output unattainable. The expected amount describes pricing when the quote was prepared; it doesn’t reserve pool liquidity until execution. Other swaps and liquidity changes can alter what the route delivers during that interval.
A successful swap may deliver less than its quoted amount while still satisfying its output floor. A failed minimum-output check produces no completed exchange within that transaction. These outcomes point to different questions: whether execution stayed within the approved limit, or whether changing conditions pushed the route beyond it.
Evidence from the affected attempt
The affected attempt’s token identities, input amount, quoted output, minimum received, and error message provide the starting evidence. Keep the quote time and submission time when available. A replacement quote describes another pricing state, so it cannot establish the limit that governed an earlier attempt.
For a submitted transaction, the signature identifies the record to inspect. Execution status and instruction logs distinguish a slippage rejection from an unrelated error. Token balance records identify the receiving mint and account, with decimal information for interpreting the amount. Wallet-wide totals can include other activity, which makes them a weaker basis for measuring one swap’s output.
A missing receipt leaves the outcome unresolved. It doesn’t establish a slippage failure.
Minimum received and the permitted output range
Minimum received is the output floor for an exact-input swap, expressed in the receiving token’s units. The quoted output and tolerance determine that boundary under the transaction’s applicable calculation. A percentage alone doesn’t tell you the smallest amount that the transaction permits.
An exact-input swap fails its slippage check when execution cannot satisfy the transaction’s minimum output requirement. Passing that check means the output met the encoded condition. It doesn’t mean execution matched the original estimate exactly.
Holding the quote constant, a wider adverse-slippage tolerance lowers the output floor. A tighter tolerance raises it. This explains the trade-off: accepting more variation can allow execution that a stricter limit would reject, at the cost of permitting fewer receiving tokens.
The tolerance isn’t a charge that every successful swap pays. Actual execution determines the amount received within the permitted conditions. Treating the full tolerance as an automatic deduction confuses permission with the outcome.
A refreshed quote changes the comparison. Even with the same percentage, a lower quoted output produces a lower floor. Evaluate the receiving amount alongside the percentage, and use the threshold associated with the transaction awaiting approval. An older screen value cannot override the limit inside that transaction.
Quote age and transaction expiry
A quote can become economically stale before its transaction expires, because validity and acceptable pricing measure different things. The transaction may still be eligible for submission while the route can no longer satisfy its output limit. Faster submission shortens that exposure without freezing the market.
Jupiter’s Swap V2 order responses distinguish expiry conditions by route. Aggregator routes provide a last valid block height, while market-maker quotes provide an expiry timestamp. Those boundaries aren’t a universal countdown for every swap. Price movement can cause a slippage failure within the validity window; expiry can prevent execution even when the displayed price appears acceptable.
A fresh quote replaces the earlier pricing assumptions. It cannot extend an expired transaction or revise one that has already executed.
Price impact and route liquidity
Price impact reflects how the requested trade size affects available pricing, while execution slippage measures the difference from the quote. A route can already quote an unfavorable rate because the input is large relative to usable liquidity. Increasing tolerance doesn’t repair that starting rate.
Route depth means the liquidity available to absorb the trade across its selected markets. It differs from the number of intermediate swaps. A short path can have thin liquidity, while a path through several markets can provide a better output. Counting hops alone doesn’t establish which route handles the amount more effectively.
Comparisons between trade sizes need an output-per-input basis. A smaller input can produce fewer total receiving tokens even when its exchange rate improves. Reducing size may lessen price impact, but it doesn’t guarantee a better rate under changing conditions. Repeated smaller swaps also encounter new market states; their combined outcome isn’t fixed by the first small quote.
Fixed tolerance and automatic estimation
A fixed tolerance supplies an explicit limit, while Jupiter’s Real-Time Slippage Estimator, or RTSE, estimates tolerance using execution data and market conditions. Neither approach guarantees that a changing route will remain executable.
Jupiter’s RTSE sets the estimated tolerance when it creates the order or build, embedding that estimate in the transaction. It doesn’t continuously revise the limit inside an already signed transaction. This distinction matters when a wallet approval remains open while pricing changes.
In Swap V2, the Meta-Aggregator order path applies RTSE automatically unless a fixed tolerance overrides it. The Router build path supports RTSE as an explicit option. These integration choices explain why separate applications using Jupiter can handle tolerance differently. Diagnose the behavior of the actual swap path instead of assuming that an automatic label means identical settings everywhere.
What does Jupiter error 6001 mean?
Error 6001 identifies SlippageToleranceExceeded when Jupiter’s applicable Swap Program emits it. The code establishes that execution exceeded the permitted slippage condition, without identifying quote age, liquidity movement, or another underlying cause by itself. Program identity matters because error numbers belong to the program that returns them. A routed exchange can also return its own error, so the failing instruction and program provide context that a wallet’s shortened message may omit.
Transaction delay versus price failure
A delayed transaction can encounter changed liquidity, but delay alone doesn’t prove that a slippage check failed. Expiry, insufficient funds, and invalid accounts require different corrections. Transaction prioritization concerns landing; tolerance concerns permitted price deterioration. Increasing tolerance cannot fix a missing account or revive an expired transaction. A pending display therefore calls for status evidence before any conclusion about the output floor.
A fresh quote or a smaller input
A rejected swap was expected to exchange the chosen input, yet its record shows an output-limit failure. Two possible adjustments address different causes: refresh pricing for the same amount, or reduce the input when the quote shows excessive price impact. Their shared test is an acceptable receiving amount under the proposed transaction’s actual limit.
Resolve the previous attempt before signing a replacement. Then compare a fresh quote for the same tokens and input amount. Keep any fixed tolerance unchanged; with automatic estimation, check whether the tolerance also changed. A size change comes afterward if the amount itself appears to strain liquidity.
- If the previous transaction’s outcome remains unresolved, wait for reliable status evidence before authorizing a replacement.
- If failure is confirmed and the quote aged before submission, compare a fresh quote for the same input.
- If fresh pricing still shows excessive price impact, compare a smaller input using output per input and its new minimum received.
- If either proposal permits less output than you accept, stop rather than widen tolerance merely to clear the error.
- If a revised swap completes, confirm successful execution and reconcile its receiving amount against that attempt’s output condition.
Once the earlier failure is confirmed, you can approve a replacement whose minimum received is acceptable. After execution, check its status and received amount against that minimum. If the earlier attempt’s status is still unknown, wait: a new quote doesn’t establish whether it executed.
Unexpected output after successful execution
A successful receipt with an unexpected amount requires comparison against the quote that produced that transaction, using the same token units. The first number seen on screen may differ from the final proposal approved in the wallet. Comparing the receipt with that earlier display can exaggerate or misidentify execution slippage.
Solana transaction metadata can include token balances before and after execution, together with the mint, account index, and decimals. Those fields help isolate the receiving account’s change. Raw token amounts require their decimal scale; comparing a raw integer with a wallet’s decimal display creates an apparent discrepancy without any price movement.
Disclosed deductions also need consistent treatment. Compare quoted and received amounts on the same basis before attributing their difference entirely to slippage. A lower portfolio valuation adds another variable because the wallet’s valuation price can change after the exchange.
Repeated failures and the stopping boundary
Repeated slippage failures indicate that the attempted routes aren’t meeting their encoded output conditions under the observed execution conditions. They don’t establish a universally correct higher percentage. Changing input size, tolerance, and route settings simultaneously also makes it harder to identify which dependency caused the failure.
Preserve the error, transaction signature, quote details, and relevant timestamps when a consistent problem needs investigation. A route-specific account or liquidity error may require a newly constructed route rather than additional tolerance. If fresh pricing remains unacceptable, successful execution would still fail the intended economic requirement.
For a failed Solana transaction, the network rolls back the swap’s state changes; a processed failure can still incur a network fee. That distinction explains why a rejected swap can leave no receiving tokens yet affect the fee balance. Stop retrying when the only apparent remedy permits an output that you would reject before approval.
Details worth knowing about Jupiter swap slippage
How do basis points translate into a Jupiter slippage percentage?
One basis point equals 0.01 percentage points, so 100 basis points equal 1%. This conversion describes the unit, not a recommended setting. An integration that accepts slippageBps expects basis points rather than the percentage number shown in many interfaces; confusing those units changes the intended tolerance.
Can my Jupiter swap receive more tokens than the quote?
A swap can receive more than quoted when execution improves relative to the estimate, an outcome called positive slippage. The actual receiving amount establishes whether that happened. A minimum-output condition protects the lower boundary; it doesn’t promise improvement or make the quoted amount a universal upper limit.
Does slippage tolerance protect the token’s value after the swap?
Slippage tolerance constrains execution relative to the swap’s pricing conditions, not the token’s later market value. After the exchange completes, the received tokens can rise or fall in value. A successful minimum-output check therefore doesn’t establish a continuing value floor for the resulting balance.
Is older Dynamic Slippage the same feature as RTSE?
Dynamic Slippage and RTSE are distinct Jupiter mechanisms. The legacy swap transaction API describes Dynamic Slippage as no longer maintained, while Swap V2 supports RTSE. An older integration’s dynamicSlippage option shouldn’t be treated as an interchangeable name for RTSE or evidence of how another application’s automatic setting behaves.
Do I need to share my recovery phrase to diagnose a slippage error?
A recovery phrase or private key isn’t needed to inspect a swap’s public transaction record and error. A transaction signature, error text, and relevant quote details provide diagnostic context. Sharing a signature can reveal associated public wallet activity, so remove unrelated personal information from screenshots and never include wallet secrets.
Does an ExactOut swap use the same output-floor calculation?
ExactOut applies slippage to the required input amount, whereas ExactIn applies it to output. The legacy Jupiter quote API distinguishes these modes and limits ExactOut support to particular markets. That API distinction doesn’t mean the swap interface exposes ExactOut, and its input ceiling shouldn’t be interpreted as an ExactIn minimum received.