Jupiter swap is a quote-to-output workflow on Solana

Updated August 2, 2026

Jupiter swap is a Solana token-exchange workflow that collects the input mint, output mint, amount, and wallet address, compares eligible liquidity routes, and prepares one transaction for confirmation. The quoted outAmount is an estimate before price protection, while otherAmountThreshold defines the minimum acceptable output encoded for execution. A route becomes a completed swap only after the wallet signs, Solana processes the transaction, and the receiving token account records the final output.

Key takeaway: It is a Solana token-exchange workflow that compares liquidity routes for quoted output, but that output can change before wallet confirmation.

A displayed output is not a reserved price

A Jupiter swap quote describes executable conditions at the moment the route is assembled. Liquidity changes after that moment, so outAmount remains a quoted quantity rather than a reserved balance. The transaction protects the user through its minimum-output threshold: execution fails when the route cannot produce at least that amount.

Time creates a second boundary. A standard Solana transaction carries a recent blockhash that remains valid for 150 slots, with 151 recent entries accepted because blockhash age starts at zero. An aggregator order exposes lastValidBlockHeight as its hard deadline. JupiterZ request-for-quote routes also carry a market-maker expiry through expireAt, which can arrive sooner. If a wallet request sits open while markets move, cancel it and obtain a newly assembled order.

Meta-Aggregator orders versus Router builds

The Meta-Aggregator and Router are Jupiter's two execution paths, and their route universes differ. A standard Meta-Aggregator order with no optional restrictions lets four engines compete: Metis, JupiterZ, Dflow, and OKX. The response identifies the winner in its router field, then supplies a transaction for wallet signing and managed execution.

The Router build path uses Metis alone and returns raw instructions instead of a managed order. That narrower path serves transactions that must include a memo, transfer, protocol call, or other custom instruction. It also places simulation, transaction assembly, submission, and confirmation under the integrator's control. Choosing between the two paths therefore changes both the available liquidity sources and responsibility for landing the transaction.

The four inputs that anchor a quote

Four required inputs anchor an assembled Jupiter quote: inputMint, outputMint, amount, and taker. Mint addresses identify the two assets, the amount is an integer expressed in the input token's smallest unit, and the taker is the wallet expected to sign. Omitting the taker permits a price check but does not produce a signable transaction.

The response separates expected output from protected output. outAmount is the estimated amount before slippage protection, while otherAmountThreshold is the minimum accepted during execution. Route allocation uses basis points: 10,000 basis points equal 100%, one basis point equals 0.01%, and 50 basis points equal 0.5%. The feeBps and feeMint fields separately show the total quoted fee rate and the token in which it is collected.

Route splits reveal the pools behind the output

A Jupiter route plan records where the input travels and how much each leg contributes. Each routePlan entry identifies an automated market maker or quoting source, its market address, both mint addresses, and the leg's input and output amounts. Multiple entries divide the order in basis points that total 10,000.

Metis evaluates on-chain liquidity from established Solana venues such as Raydium, Orca, and Meteora. A route might move directly between SOL and USDC, split the input across two pools, or pass through an intermediate token when that produces stronger final output. JupiterZ uses signed market-maker quotes rather than a public pool path, while Dflow and OKX provide additional competing routing engines. The final output mint must remain identical across every candidate, even when the internal legs differ.

What the wallet signature actually authorizes

A wallet signature authorizes the complete Solana message, including its accounts, instructions, recent blockhash, and fee payer. Jupiter's managed order returns a versioned v0 transaction. Each signer contributes a 64-byte Ed25519 signature, so changing the amount, recipient, route, or blockhash produces a different message that requires a new approval.

Solana caps a serialized transaction at 1,232 bytes, so route breadth and setup instructions compete for the same message space. The network also enforces 64 account locks per transaction and no more than 12 signatures per packet. Address lookup tables help v0 transactions reference more addresses compactly, but they do not remove the account-lock ceiling.

The compute ceiling is 1,400,000 units per transaction. Solana's base charge is 5,000 lamports per signature, plus any priority fee requested by the message. Wallet confirmation should therefore show enough SOL for network charges and any token-account setup that the transaction includes.

Submitted, confirmed, and finalized are different states

A Solana swap moves through three standard commitment levels: processed, confirmed, and finalized. Processed means a node has observed execution, confirmed adds cluster voting, and finalized places the transaction in a rooted block. Jupiter's managed execution condenses its response to Success or Failed; code 0 represents a confirmed success.

A transaction signature is an identifier, not proof that the swap succeeded, because some failed submissions also return one. Inspect the status and on-chain error together. When a connection ends after signing, resubmitting the same signed bytes preserves the same signature and does not create a second swap. Building a replacement immediately is less precise: check the existing signature or wait for its blockhash to expire before signing a fresh order.

Confirming the token output from account balances

A closer look is available in Jupiter swap walkthrough. The definitive output check is the receiving token account's balance change for the requested mint. Solana identifies assets by mint address rather than ticker alone, which matters when unrelated tokens reuse the same symbol. Selecting JUP, USDC, or any other asset therefore requires the intended Solana mint and the corresponding SPL Token or Token-2022 account.

Atomic units must be converted with the mint's decimals. One SOL equals 1,000,000,000 lamports and uses nine decimal places, while native USDC on Solana uses six decimal places. A raw output of six-digit precision should not be read as whole tokens. Wrapped SOL follows the SPL Token account model even though it represents the same underlying unit as native SOL.

Managed execution exposes four accounting fields. inputAmountResult and outputAmountResult describe the route itself; totalInputAmount and totalOutputAmount describe the wallet-level amounts after the quoted fee treatment. Phantom or Solflare might refresh a displayed balance after the chain has confirmed, so the transaction record in Solscan and its pre- and post-token balances provide the sharper check.

Recovering from no route, stale pricing, and missing accounts

Jupiter swap failures become easier to resolve when the quote stage is separated from the transaction stage. A valid price response does not always include a buildable transaction, and a signed transaction does not guarantee that its threshold, accounts, and blockhash remain valid when a validator evaluates it.

• No route: Request a smaller input or recheck the opposite direction. An amount outside available pool depth prevents Metis from consuming the full order.
• Empty transaction: Keep the pricing information for display, but do not open the wallet. Match the returned router and error code before requesting another order.
• Threshold failure: Refresh the quote. Reducing the trade size changes its price impact without simply widening the accepted output range.
• Missing token account: Include the idempotent associated-token-account setup instruction, or create the receiving account before rebuilding the transaction.
• Unclear submission: Query the existing signature first. If its blockhash expired without execution, discard that message and sign a newly quoted transaction.

Insufficient input balance and insufficient SOL are separate conditions. The wallet must cover the requested token amount, while the selected fee payer covers signature charges, priority fees, and account creation unless a gasless order assigns those costs elsewhere.

Custom account and compute limits reshape routing

A custom Jupiter Router build exposes account and compute constraints that managed orders handle automatically. The maxAccounts parameter accepts values from 1 through 64 and defaults to 64. Lowering it frees transaction space for custom instructions, yet it also removes account-heavy routes from consideration and can reduce quoted output.

Existing associated token accounts create another opportunity to save space. An idempotent creation instruction performs no state change when the account already exists, so an integrator that has checked the account may omit that setup instruction. Instruction order still matters: compute-budget instructions precede setup, the swap instruction follows setup, and cleanup belongs after the swap.

The Router response supplies a compute-unit price instruction but leaves the final unit limit to the builder. Simulation measures consumption before signing. Solana calculates the optional priority charge as the ceiling of compute-unit price multiplied by the requested limit, divided by 1,000,000 micro-lamports per lamport. A needlessly high limit therefore pays for unused scheduling capacity.

Who gains from inspecting every route field?

Route-level review is most valuable when a trade is large relative to pool reserves, a symbol maps to several mints, the receiving account is new, or custom instructions share the transaction. Those conditions directly affect route eligibility, message size, and final token accounting.

A Jupiter swap deserves a fresh comparison whenever the wallet prompt has remained open, the selected router changes, or the protected output no longer matches the intended exchange. Liquid pairs such as SOL and USDC still benefit from checking the two mint addresses, input amount, minimum output, fee payer, and receiver. Those fields connect the displayed quote to the exact state change Solana will attempt.

FAQ