Jupiter swap is decided by quote choices and verified output
Jupiter swap is a Solana exchange workflow where the selected input mint, output mint, amount, and live quote define the transaction a wallet signs. The decisive output is not the token ticker alone. It is the exact mint address, expected received amount, fee treatment, and protected output shown before confirmation. Once Solana confirms the transaction, the input token account loses the settled amount and the output token account receives the verified token units.
Published:
A matching ticker can still select a different mint
Token identity in a Jupiter quote is fixed by the mint address, not the symbol. Two Solana assets can display the same name and ticker while referring to separate mint accounts.
A Solana mint address represents a 32-byte public key, normally rendered as a 32-to-44-character Base58 string. Compare the complete address in the token details, not a shortened beginning or ending. Pasting a known mint into the selector removes ambiguity before the quote exists. Solscan also exposes the mint, decimals, token program, supply controls, and associated market records.
A Jupiter verification label helps with discovery, yet the selected mint remains the binding identifier. A Jupiter swap that points to a different mint settles into that different asset even when its icon, symbol, or displayed name looks familiar.
Prepare the signer and a SOL reserve
A signing wallet is the first prerequisite for execution. Phantom, Solflare, Backpack, and Ledger-connected accounts all provide Solana signatures, but their recovery arrangements differ and should be understood before funds enter the workflow.
Phantom creates a 12-word BIP-39 Secret Recovery Phrase for its phrase-based wallet. Solflare supports recovery-phrase exports containing 12 or 24 words, while a standard Ledger device setup records a 24-word recovery phrase. A connected application needs the public address and a transaction signature; it does not need the recovery material.
| Signing setup | Backup or recovery standard |
|---|---|
| Phantom phrase wallet | BIP-39, 12-word Secret Recovery Phrase created by Phantom |
| Solflare phrase wallet | Exported 12-word or 24-word recovery phrase |
| Backpack wallet | Secret Recovery Phrase for the wallet, or an exported private key for one account |
| Ledger-connected Solana account | Restore the Ledger device from its recovery phrase, then reconnect that device |
The active account must hold the input asset. It also needs SOL when the taker pays network costs. Solana charges a base fee of 5,000 lamports per signature, plus any priority fee included in the transaction. One SOL contains 1,000,000,000 lamports. New output token accounts require a rent-exempt balance unless the quoted transaction assigns that cost to another payer.
Set input, output, and amount in that order
Quote construction uses three binding inputs: the asset being spent, the asset being received, and the spend quantity. Changing any one of them invalidates the decision made from the previous quote.
Select the input by mint, then repeat the address check for the output. Entering an amount fixes the units offered to the route. SOL uses nine decimal places, so 0.1 SOL equals 100,000,000 lamports. USDC on Solana uses six decimals, making one USDC equal to 1,000,000 base units. The interface converts those integers into readable amounts.
In a Jupiter swap, the Max control deserves extra attention when SOL is the input. Spending the entire displayed balance leaves nothing for a user-paid signature fee, priority fee, or output account creation. Enter a smaller amount or use a quote that explicitly identifies a different fee payer. SPL Token and Token-2022 assets also carry mint-defined decimals that must remain consistent from selection through settlement.
Read the quote as a bundle
A Jupiter quote combines expected output, execution protection, routing, price impact, and fee information. The largest displayed output matters only after the output mint and settlement terms match the intended trade.
The expected amount describes the quoted token units before execution. A protected minimum or automatic slippage setting governs how far execution may move before the transaction rejects the swap. One basis point equals 0.01%, while 100 basis points equal 1%. That notation keeps small tolerances precise without using long decimal percentages.
Check which mint pays any displayed fee and whether the quote is gasless. A sponsored network fee does not mean every cost disappears; the quote can recover sponsorship through the token amount. Price impact measures the route's effect relative to available liquidity. It is separate from the minimum-output rule and from a platform fee.
Quote age and the refresh decision
Quote age determines whether the displayed terms still deserve a signature. Aggregator orders expose a last valid block height, while JupiterZ request-for-quote orders use a market-maker expiry time.
A Solana transaction uses a recent blockhash that remains valid for 150 slots. That limit is a processing window, not a guaranteed clock duration. Refresh the quote after changing the pair, amount, wallet, slippage control, fee strategy, or router exclusions. Refresh it as well when the confirmation window has been left open while pool prices moved.
What must the wallet confirmation contain?
Wallet confirmation is the last pre-execution view of the transaction. It should preserve the connected address, spend asset, output asset, amount, fee payer, and estimated balance changes that produced the accepted quote.
The Jupiter swap confirmation carries a Solana versioned transaction marked v0. Each required signer contributes a 64-byte Ed25519 signature. Solana limits a transaction packet to 1,232 bytes and no more than 12 signatures; the active account-lock limit is 64 accounts. Address Lookup Tables let v0 transactions reference route accounts without placing every full address directly in the message.
Several instructions inside one confirmation do not represent several independent trades. A route may set compute limits, create an Associated Token Account, move tokens through liquidity accounts, and close temporary accounts. Confirm only after the wallet's simulated changes agree with the pair and amount shown in Jupiter.
What changes on Solana after execution?
Solana transaction execution is atomic: every included instruction succeeds, or the program state changes are rolled back together. The network fee remains chargeable when an executed transaction fails.
A successful route debits the input token account, passes balances through the chosen liquidity programs, and credits the output account. The Associated Token Account Program creates the standard output account when required. The SPL Token Program or Token-2022 Program then enforces the mint and balance rules. Each token account holds units for one mint, which is why the final mint field proves what arrived.
Execution resources also constrain route construction. A non-builtin instruction receives a default limit of 200,000 compute units, and one transaction cannot request more than 1,400,000 compute units. Cross-program invocation has a maximum stack depth of five, including the top-level instruction. Jupiter builds within those boundaries before presenting the transaction for signature.
Verify output in the token account
Output verification means matching the confirmed token-account change to the selected mint and final received quantity. A portfolio row is convenient, but the transaction signature and account data provide the settlement record.
Jupiter's managed execution response distinguishes quoted output from settled output. The
outAmount
field is the expectation established by the order. After execution,
outputAmountResult
records what the swap route produced before any fee charged in the output mint, while
totalOutputAmount
records the final amount reflected in the wallet. Status
Success
with code 0 signals confirmed execution.
Open the signature in Solscan or Solana Explorer. Match the owner, output mint, and token balance change. Then compare the integer amount after applying the mint's decimals. Wallet portfolio values can refresh later because they require price data, but the confirmed token units and mint address already establish the completed state.
Recover from insufficient SOL
Insufficient SOL is a setup error that stops a Jupiter swap before a valid transaction is built or landed. The fix is to restore a fee reserve, adjust an all-SOL input, and request a new quote.
The minimum network base fee is 5,000 lamports for each signature. The transaction can also include a priority fee, output-account rent, or temporary account costs. In Swap V2 diagnostics, aggregator error code 2 means insufficient SOL for gas. JupiterZ also uses code 2, but there it means a missing Associated Token Account, so the router name and code must be read together.
Add SOL to the active signing address or reduce the SOL input amount. If the order reports
gasless
as true, inspect the displayed token fee and fee payer rather than assuming the wallet pays nothing. Request a fresh quote after changing the balance. The old transaction retains its old blockhash, route, and settlement terms.
Why does a fresh quote pick a different route?
Once that is set, Jupiter routing compares execution paths after the token pair and amount are fixed. Route changes reflect new liquidity and quotation conditions; they do not change the selected output mint.
The Swap V2 meta-aggregator compares four documented engines: Metis, JupiterZ, Dflow, and OKX. Metis builds onchain paths and can split or hop across liquidity sources. Orca, Raydium, and Meteora are established Solana venues that can contribute pools to onchain routing. JupiterZ uses a request-for-quote workflow in which market makers return executable terms, while Dflow and OKX contribute separate routing sources.
The order response also has two behavior labels.
ultra
means no optional routing parameters were supplied;
manual
means settings such as custom slippage, a payer, or router exclusions altered eligibility. That mode field describes configuration, not the winning engine. Compare the refreshed output, fee mint, and expiry before signing again.
The completed swap record
A completed Jupiter swap record should reconcile the signature, confirmation slot, input mint and debit, output mint and credit, and actual fee payer. Those fields explain the balance change without relying on a portfolio valuation.
Keep the quoted amount separate from the received amount. The quote records the pre-signing decision; the confirmed token-account delta records settlement. If the output mint matches, code 0 confirms success, and the final delta agrees with
totalOutputAmount, the exchange is complete. A stale interface history can then be refreshed without creating another transaction.
Common questions about Jupiter swap
Does rejecting the wallet confirmation change any token balance?
Rejecting the wallet confirmation creates no signed transaction and changes no onchain balance. The unsigned quote remains only a proposed message. Jupiter must receive a valid signature before execution proceeds. The displayed quote can continue changing afterward, so reopening confirmation should begin with a refreshed order rather than an assumption that the rejected terms remain available.
Which account receives output when my wallet contains several Solana addresses?
The connected taker address receives the output in the standard interface flow. Selecting another account inside Phantom, Solflare, or Backpack changes the connected public key once the application reconnects to it. Some integrations support a separate receiver parameter, in which case the transaction should identify that receiver explicitly. The output Associated Token Account is derived from the receiver, mint, and token program.
Why does wrapped SOL appear in a swap confirmation?
Wrapped SOL gives native SOL an SPL-compatible token representation during program execution. A route can create or use a wrapped SOL token account, synchronize its lamport balance, perform the swap, and close a temporary account within one atomic transaction. The wallet can therefore display wrapped SOL instructions even though the interface labels the asset as SOL and the final balance returns to native SOL.
Is a simulation result the same as confirmed settlement?
A simulation is not confirmed settlement. It executes the proposed instructions against a recent view of Solana state without committing balance changes. The simulation helps the wallet predict debits, credits, account creation, and program errors. Only a transaction recorded successfully onchain establishes the final token-account state, signature status, slot, and received amount.
How does Token-2022 affect an output check?
Token-2022 can attach extensions that affect transfers and required accounts. A transfer-fee extension, for example, withholds a mint-defined portion during a transfer, while a transfer hook invokes additional program logic. The quote and assembled transaction must support those rules. After confirmation, compare the actual destination-account increase with the exact Token-2022 mint and Jupiter's final output field.
Can a hardware wallet sign the same quote shown in Jupiter?
A Ledger-connected Solana account can sign the assembled transaction through a compatible wallet interface. The hardware device holds the signing key, while Phantom or Solflare provides the connection and transaction presentation. Confirm that the connected Ledger address matches the funded account before requesting the quote. After signing, verify the same mint and final token-account delta used for a software-wallet exchange.