Jupiterswap
Jupiterswap connects route quotes, wallet authorization and on-chain verification of Solana swap outcomes
Jupiterswap, used here for Jupiter's token-swap flow on Solana, starts with a route quote. If the transaction is submitted, its outcome can be checked against on-chain records. The quote identifies the intended input, output and minimum acceptable return. A wallet signature authorizes the prepared transaction, but does not prove settlement. A successful swap requires a successful transaction record and the expected account changes. If execution fails or the route becomes stale, reconcile any submission before building a replacement.
Jump to a section
Bottom line: A quote records the proposed trade, while transaction status and account changes show whether the swap settled.
From route selection to a settled record
The normal path moves from a live quote to authorization, submission and confirmation. A bounded recovery path begins when the proposed transaction expires, fails its limits or cannot reach a valid route.
Normal path
Quote and authorization
A quote describes a proposed exchange under the liquidity and routing conditions available when it was created. Its fields identify the input mint, output mint, input amount, expected output, minimum acceptable output and planned route. The wallet should display a transaction that matches those terms before its owner approves it.
Authorization belongs to the wallet, not to the quote. Signing proves that the relevant account approved the exact transaction message presented to it. It does not show that a validator accepted the transaction or that the destination token account received the expected asset.
Submission and settlement
A signed swap must still be submitted and confirmed before its intended on-chain state changes establish settlement. The transaction signature provides an identifier for that submission. Its status, program result and account changes supply the evidence needed to interpret the outcome.
Successful execution should debit the authorized input account and credit the designated destination account, subject to the transaction's encoded limits. Network fees may also change the fee payer's SOL balance. Reading only the wallet's total value can hide these separate movements, particularly when prices or cached balances change at the same time.
Bounded recovery
An expired blockhash, a failed slippage check or a route that is no longer available calls for a fresh quote and a newly built transaction. The replacement must be reviewed again because its output, route, accounts or fee settings may differ. Repeatedly broadcasting an expired payload cannot refresh the state on which it was built.
What does a route quote prove before signing?
A route quote records the router's proposal for specified mints, an input amount and the conditions encoded in the response. It is not evidence that a trade has occurred. Pool balances, competing transactions and network conditions can change before the prepared transaction reaches a validator.
The minimum-output threshold is the lowest output accepted under the quote's slippage setting, not a promise that the quoted output will be delivered. The swap instruction should reject execution below that threshold. The expected output remains useful for comparing routes, while the threshold defines the execution boundary.
Price impact and slippage describe different relationships. Price impact compares the proposed trade with the market state used for the quote. Slippage tolerance controls how far the executed result may move from the quoted basis before the transaction rejects it. Neither value identifies a token or proves that its market is genuine; mint addresses carry that identity.
Prepared transactions and custom instruction paths
A prepared-transaction path packages the route into an unsigned transaction for wallet review. A custom integration can instead request swap instructions and compose them with required setup, compute-budget and cleanup instructions. Both paths still depend on the same authorization and on-chain execution boundary.
Custom composition exposes more moving parts. Instruction order matters because an output account may need to exist before the swap and cleanup cannot run before the exchange. Extra transfers, account creation or memo instructions also broaden what the signature authorizes. The wallet message therefore deserves inspection as a whole, not only as a swap label.
Route controls may restrict eligible liquidity venues, exclude particular venues or require a direct route. Such limits can simplify a route, yet they can also reduce available liquidity or produce no route. A split or multi-hop plan is not inherently evidence of failure; it describes how the router proposes to reach the requested output under the selected constraints.
How can a completed swap be verified?
A completed swap is verified when the transaction status and the relevant account changes agree. The signature is the lookup key, while the execution result establishes whether the programs completed without an error.
Confirmation state matters because a locally submitted transaction may still be pending, dropped or expired. A wallet notification alone can arrive before the durable network record is clear. Read a recorded execution result from the transaction record. If no record appears, use the transaction's validity boundary before treating it as expired.
A failed Solana transaction does not commit its program state changes, although its transaction fee may still be charged. This distinction explains why a fee payer's SOL balance can fall even when the expected output tokens never arrive. It also prevents a fee debit from being mistaken for partial swap settlement.
For SPL token output, match the output mint, token-account owner and credited raw amount, then interpret that amount with the mint's decimals. For native SOL output, reconcile the destination account's lamport change with any fee or rent changes instead. When a new associated token account was created, the output may appear in a different account entry than the wallet previously displayed. The mint address remains the reliable identity field.
Reconciliation joins these records without treating any one display as complete. Keep the transaction signature beside the intended mints, input amount, quoted minimum and observed output. If those records agree with a successful status, the swap's outcome is verified. If they conflict, resolve the discrepancy before authorizing another swap.
Reconciliation when records disagree
A successful status with no visible output calls for an account-level check. For token output, verify the destination, mint, token-account owner and decimals. For native SOL, reconcile the destination's lamport change with any fee or rent changes in the transaction. A failed status with a smaller SOL balance may reflect the transaction fee rather than a token transfer. If the signature is absent or unresolved, check the network record again before retrying. A new quote should replace the old proposal only after the earlier submission has a clear terminal state.
Conditions to check before authorization
Sign only when the transaction matches the intended exchange and its failure boundary is acceptable. Before signing, check each of these conditions:
- Match the input and output mint addresses rather than relying on names or tickers.
- Interpret each raw amount using the correct token decimals.
- Read the expected output and the minimum acceptable output as separate values.
- For token output, confirm that the destination token account has the intended mint and owner.
- Inspect route restrictions and every additional instruction included in the transaction.
- If your account is the fee payer, keep enough SOL in it for the submitted transaction.
If any field changes before signing, discard the previous review and examine the rebuilt transaction. Time sensitivity has no useful universal duration here: quote freshness depends on changing route state, while transaction validity depends on its encoded blockhash. The flow can end with a declined signature, an expired transaction or a reconciled final result.
A clean exit from the swap flow
Before signing, leaving the flow requires no on-chain reversal because a quote has not moved tokens. Declining an unexpected transaction is therefore a complete stop. After submission, the exit depends on the recorded outcome: success leads to output verification, while failure or expiry leads to reconciliation before any replacement is signed.
A successful swap credits the designated destination with the received asset, while the transaction signature identifies its execution record. It does not create proof that the asset is suitable, liquid or correctly identified beyond the mint and route that were authorized. Those questions must be settled before the transaction rather than inferred from successful execution.
Jupiterswap is most useful when route selection across available liquidity matters and the resulting state can be checked on-chain. Trading directly through one chosen pool narrows the route to a known venue, while the aggregator can evaluate broader paths and split execution when its constraints allow.
Frequently asked questions about Jupiterswap
Can a wallet signature show that the swap succeeded?
No, a wallet signature shows authorization of a particular transaction message. Success requires a submitted transaction with a successful network result and account changes that match the intended swap. Use the signature to locate that record, then check the output mint, destination account and credited amount. A signed payload that expired or was never submitted has not settled a trade.
How long does a Jupiterswap quote remain usable?
A quote has no reliable universal lifetime because it describes route state at the moment it was calculated. Liquidity can change before signing, and the built transaction also carries a blockhash validity boundary. If submission is delayed, the route changes or the transaction expires, obtain a new quote and review the replacement rather than assuming that the earlier terms remain executable.
What happens if no route is returned for a token pair?
No route means the router could not produce an executable path under the supplied mints, amount and restrictions. That result does not by itself prove that either token is invalid or that no market exists anywhere. Check the mint addresses and any direct-route or venue restrictions. A later quote may differ if eligible liquidity or routing conditions change.
Can one swap use more than one liquidity pool?
Yes, a route can contain multiple legs or split the input across eligible pools when the router finds that structure suitable. The route plan should expose those components before authorization. Multiple pools can add accounts and internal program calls, so the complete transaction still needs review. Restricting execution to one market may remove that complexity, but it can also reduce available routes or expected output.
Does a failed swap still cost SOL?
Yes, a submitted Solana transaction may charge its transaction fee even when a swap instruction fails and token-state changes are not committed. That fee debit should be reconciled separately from the intended input and output balances. The exact charge comes from the submitted transaction's fee settings and network processing, so a lower SOL balance alone does not prove that the token exchange succeeded.
Updated ยท