Jupiter swap

Jupiter swap is a routed quote, signature, and output-verification workflow

Jupiter swap is a Solana execution sequence that converts a token pair and amount into a routed quote, an exact transaction for the wallet to sign, and a verifiable onchain balance change. The quote identifies expected output and applicable fees; the signature authorizes only the assembled message; the resulting transaction signature lets the user distinguish pending, confirmed, expired, and failed execution before checking the received token mint and amount.

Posted 5 Aug 2026

In short: A fresh blockhash lasts 150 slots, so a delayed signature should be replaced with a newly quoted transaction.

Costs attached to the signed swap

Generally, Jupiter swap costs combine the Solana network fee, any priority fee, the managed-order platform fee, and trading fees embedded in the selected liquidity route. Solana charges a base fee of 5,000 lamports for each required signature, while 1 SOL contains 1,000,000,000 lamports. An optional priority fee equals the requested compute-unit limit multiplied by its compute-unit price; 1,000,000 micro-lamports equal 1 lamport.

Swap API V2 expresses its platform schedule in basis points, where 1 basis point equals 0.01%. The managed /order path defines 0-basis-point tiers for specified Jupiter-token purchases and pegged-asset pairs, 2 basis points for SOL-stablecoin pairs, 5 for liquid-staking-token-to-stablecoin pairs, 10 for other established pairs, and 50 for tokens within their first 24 hours. The quote's feeBps, feeMint, and expected output reveal the applicable combination before signing.

From mint inputs to a route plan

A Jupiter quote begins with an input mint, output mint, raw input amount, and the wallet address that will authorize the transaction. Every Solana account address represents a 32-byte public key, so mint addresses - not symbols - identify the assets. Amounts use each mint's smallest units: wrapped SOL has 9 decimal places, while USDC on Solana has 6. This precision determines how the displayed amount becomes the integer sent to the routing engine.

The meta-aggregator lets Metis, JupiterZ, DFlow, and OKX compete for the order. Metis searches onchain liquidity that includes venues such as Orca, Raydium, Meteora, and Phoenix, while JupiterZ supplies request-for-quote pricing from market makers. A route may use one venue or split the order across several legs. In a V2 routePlan, 10,000 basis points represent 100% of the input allocation, making each split independently auditable.

The wallet confirmation boundary

Wallet confirmation applies an Ed25519 signature to the exact Jupiter swap transaction assembled for the quoted order. The version-0 message fixes its instructions, account list, recent blockhash, fee payer, and route protections; Address Lookup Tables compress additional account addresses when a route needs them. Changing the amount, receiver, route, or serialized message after signing invalidates that authorization and requires a newly assembled transaction.

Each Ed25519 signature occupies 64 bytes, and a serialized Solana transaction is limited to 1,232 bytes. Runtime execution has a maximum budget of 1.4 million compute units per transaction. Phantom and Solflare may summarize or simulate the instructions, but the signed message remains the authoritative authorization. Solana then executes its instructions atomically: every state change succeeds together, or the token-state changes are rolled back together.

Reading transaction states without double-submitting

Solana transaction state has three commitment levels: processed, confirmed, and finalized. Processed means a node has handled the transaction on its selected fork, confirmed adds cluster voting confidence, and finalized refers to a rooted block. Jupiter's managed execution response has two terminal status strings, Success and Failed, with code 0 identifying success.

A recent blockhash remains valid for 150 slots, after which a fresh transaction is required. The transaction signature is the durable lookup key for Solscan, Solana Explorer, or an RPC getTransaction request; a null RPC result means the signature was not found at the requested commitment. Managed execution permits the same signed transaction and request ID to be submitted again for up to 2 minutes, and the unchanged signature prevents a second execution.

Output verification by mint and balance delta

Jupiter swap output verification compares the execution response with Solana's recorded token balances. The managed response exposes inputAmountResult and outputAmountResult, while transaction metadata supplies preTokenBalances, postTokenBalances, the network fee, and meta.err. A successful onchain execution records meta.err as null; the output account's post-transaction balance minus its prior balance shows the credited quantity.

Mint identity matters throughout this check because the SPL Token Program and Token-2022 maintain separate token accounts for each mint. Raw amounts must be interpreted through the mint's decimal setting: wrapped SOL uses 9 decimal places and USDC uses 6. If execution created the recipient's first associated token account, its missing pre-balance is treated as zero. The transaction metadata reports the Solana fee in lamports, separately from the token output and any fee collected in another mint.

Recovery path for expired quotes and failed transactions

Swap recovery starts with three concrete records: the transaction signature, Jupiter request ID, and returned error code. Their presence identifies whether the wallet stopped before submission, the cached order expired, the signed bytes were rejected, or a transaction reached Solana and returned a program error. Use the following decision checklist before producing another signature:

• No signature is shown: treat the order as unsubmitted and request a fresh quote.
• A signature remains unresolved: query that same signature at confirmed commitment before signing another transaction.
• Code -1 or -2003: replace the expired cached order or RFQ quote with a new order.
• Code -2 or -3: sign a new, untouched assembled message because the submitted payload is invalid.
• Code -1000 or -1004: obtain a fresh blockhash and quote before another landing attempt.

An onchain program failure carries a signature and transaction logs, so its instruction index and meta.err should drive the next action. Jupiter Aggregator V6 code 6001, for example, identifies an exceeded slippage threshold and calls for a fresh quote rather than repeated submission of the old route. Atomic execution restores the token-state changes, although the 5,000-lamport base charge for each processed signature remains paid.

Managed execution and custom transaction builds

Managed Jupiter execution uses a three-stage sequence: /order returns a quote and assembled version-0 transaction, the wallet signs it, and /execute broadcasts and polls the result. Swap API V2 exposes three core endpoints - /order, /execute, and /build - but only the first two form the managed path. That path lets four router families compete and returns final input and output result fields directly.

The custom /build path serves applications that need raw instructions, additional transfers, memos, or cross-program composition. It uses Metis routing, defaults to 50 basis points of slippage tolerance unless overridden, and leaves broadcasting and confirmation logic to the integrator. Ultra and earlier Metis endpoints remain available during migration, while V2 unifies managed and custom construction. Recognizing which path produced the transaction explains why two Jupiter-powered interfaces may expose different route details, settings, and recovery controls.