Jupiter swap

Jupiter swap is a Solana wallet trade reviewed before signing

Updated July 29, 2026

Jupiter swap is a connected-wallet trade flow for exchanging Solana assets after reviewing the quoted output, route, price impact, and fees. Select the token you hold, select the token you want, enter an amount, and inspect the preview. Your wallet then signs a Solana transaction. After settlement, the input balance falls, the output token account rises, and the transaction signature records the exact amounts.

It is a Solana trade interface that previews route and quoted output before approval, updates token balances after execution.

What the preview charges before you sign

The swap preview separates the platform fee from Solana network costs. On the default Swap V2 order path, Jupiter expresses its platform fee in basis points. One basis point equals 0.01%. Buying JUP, JLP, or jupSOL with SOL or a stablecoin carries 0 basis points, as do stablecoin-to-stablecoin and liquid-staking-token pairs. SOL-to-stablecoin trades carry 2 basis points, while liquid-staking-token-to-stablecoin trades carry 5.

Other pairs carry 10 basis points, while a token less than 24 hours past its first pool receives a 50-basis-point tier. The quote identifies both the rate and the token used for collection. Solana also charges a base fee of 5,000 lamports per signature. One SOL contains 1,000,000,000 lamports. An optional priority fee follows the requested compute-unit limit and price. Creating a first output token account adds recoverable account funding rather than a Jupiter platform charge.

Prepare the Solana wallet and spendable balances

A connected Solana wallet supplies the public key, input balance, and signature needed for the trade. Phantom, Solflare, and Backpack expose those functions in their browser interfaces. Unlock the intended account and compare its displayed public key with the address that received the tokens. A Jupiter swap cannot read balances owned by another account in the same extension.

Keep enough SOL available for the base fee, priority fee, and any new associated token account. Automatic gasless execution becomes eligible on default orders when the taker holds less than 0.01 SOL. Its minimum trade size changes with the priority-fee market, and the added cost is reflected in the quote. Custom slippage, priority-fee, payer, or router settings disable that automatic path.

SOL is both a tradeable asset and Solana's fee currency. Entering the full displayed SOL balance therefore leaves no ordinary fee reserve unless the interface reduces the spendable maximum or offers gasless execution. The preview should remain actionable before the wallet confirmation opens.

Select token mints before trusting symbols

A token mint address identifies the asset that Jupiter will debit or credit. Solana public keys are 32 bytes and appear as base58 strings. Symbols remain display metadata, so separate assets can share a ticker. Pasting the mint address into token search resolves the intended Solana asset without relying on a name or icon.

Decimals determine how the typed amount becomes an onchain integer. Solana USDC uses 6 decimals, making 1 USDC equal to 1,000,000 base units. SOL uses 9 decimals, making 1 SOL equal to 1,000,000,000 lamports. Jupiter handles that conversion in the interface. It also handles routine wrapping when a route needs wrapped SOL, so the user enters a human-readable amount rather than raw units.

Read expected output and minimum output together

Expected output is the route's quoted result before settlement, while minimum output is the lowest acceptable result encoded by slippage protection. Price impact describes how trade size changes the route's exchange result. It is separate from slippage, which covers movement between quoting and execution. A tolerance of 100 basis points equals 1%.

Worked example with entirely hypothetical changing inputs: suppose the preview shows an expected output of 50.000000 USDC and a hypothetical slippage tolerance of 50 basis points, or 0.50%. The hypothetical minimum is 50.000000 × 0.995, which equals 49.750000 USDC. If the hypothetical executed output is 49.900000 USDC, the wallet receives exactly 49.900000 USDC. That is 0.100000 below the estimate and 0.150000 above the minimum.

The Jupiter swap preview already incorporates its displayed platform charge into the quoted economics. Raising the input amount creates a new quote because pool depth and route composition change. Refreshing the preview also replaces the prior minimum-output calculation.

Route details explain where the quote comes from

The route panel identifies the routing engine and, for onchain liquidity, the venues supplying the trade. Swap V2 allows Metis, JupiterZ, Dflow, and OKX routing to compete. A Metis result might cross Raydium, Orca, or Meteora. Split-route percentages add to 100%, even when several pools contribute to the final output.

JupiterZ is a request-for-quote route from a market maker, so it does not resemble a visible chain of automated-market-maker pools. Custom slippage, priority-fee, payer, receiver, or router controls narrow the eligible routing set and shift execution into manual mode. Changing one of those controls demands a fresh decision because the output, fee payer, and route can all change.

Your wallet authorizes one bounded state change

A wallet confirmation authorizes the exact Solana transaction shown for the trade. The message binds its account list, instructions, recent blockhash, and fee payer. Each Ed25519 signature occupies 64 bytes. A Solana transaction has a maximum serialized size of 1,232 bytes, and a packet supports no more than 12 signatures.

The Jupiter swap transaction commonly uses the version-0 format with address lookup tables, which compress repeated account addresses. Gasless or request-for-quote routes can add another signer for the fee payer or market maker. Your wallet still signs only its own required authorization. Altering the amount, destination, route, or blockhash changes the message and requires a new signature.

Settlement rewrites token-account balances atomically

Solana settlement applies every instruction in the transaction as one atomic operation. The transaction debits the selected input account, executes the chosen route, and credits the output account. If the output associated token account does not exist, a setup instruction creates it first. Either every required instruction succeeds or all balance changes revert; the network fee remains charged after a failed execution.

A transaction currently addresses up to 64 accounts and records no more than 64 executed top-level and cross-program instructions. Cross-program invocation depth reaches 5 levels, including the initial instruction. Those limits explain why Jupiter uses address lookup tables and sometimes selects a route with fewer accounts. When native SOL needs wrapping, a temporary wrapped-SOL account can be created and closed inside the same transaction, returning its unused account funding.

Verify the signature and the net token movement

A transaction signature is the durable identifier for a completed Jupiter swap. Search it in Solana Explorer or Solscan, then check the execution status, connected owner, input mint, output mint, token balance changes, and SOL fee. The received amount is the positive output-token delta recorded for the wallet, not the earlier estimate.

Solana exposes 3 familiar commitment labels: processed, confirmed, and finalized. Processed means a node observed the transaction, while confirmed and finalized provide stronger settlement evidence. Wallet balances sometimes refresh after the explorer already shows confirmation. Reloading the wallet's asset view changes only its display; it does not produce another onchain state change.

Quote age, slippage, and account limits explain failures

A failed Jupiter swap does not produce a partial exchange. Price movement below the encoded minimum makes a route instruction return an error, so Solana reverses every attempted token change. A transaction's recent blockhash remains valid for 150 slots; after that window, Solana rejects the message as stale. Requesting and signing a fresh quote supplies a new blockhash and recalculated output floor.

Compute limits form another boundary. A non-builtin instruction receives a default budget of 200,000 compute units, while one transaction is capped at 1,400,000. Priority fees are calculated from the requested limit rather than the units ultimately consumed. Liquidity movement, account locks, or a route that exceeds transaction constraints can therefore invalidate an otherwise readable preview. Requoting lets Jupiter rebuild against the available route and network state.

Fix a connected wallet that shows a zero input balance

A zero input balance after connection commonly means the wrong wallet account is active. Jupiter reads Solana token accounts owned by the public key displayed in its interface. Compare the full connected address with the withdrawal or transfer destination. Disconnect, select the account that actually received the asset, reconnect, and then search using the asset's mint address.

A balance held on Ethereum, Base, or BNB Smart Chain is not a Solana token balance, even if the wallet shows the same ticker. That asset must first reach the selected Solana address through an appropriate transfer or bridging flow outside the swap screen. Once the correct public key and mint align, refresh the balance and request a new quote. Increasing slippage does not correct an account or chain mismatch.

Details worth knowing about Jupiter swap