Jupiter swap is shaped by liquidity routing, price, and execution

The first mistake: reading the quote as one pool price

A Jupiter swap quote is a route proposal, not a guaranteed fill from one pool. Avoid judging it by the displayed exchange rate alone. The proposal may divide the input between several pools, pass through an intermediate token, or use a request-for-quote market maker instead of an automated market maker.

Five details explain what the route proposes:

• The input and output mint addresses identify the actual assets.
• The expected output estimates what the selected route will produce.
• The minimum output defines the transaction's price-protection boundary.
• The route identifies the liquidity programs or quoting engine involved.
• The fee fields separate platform charges from the amount entering the route.

Quoted output already reflects the liquidity available when the route was calculated. It does not reserve that liquidity. A later transaction encounters the pool balances and market conditions present during execution, which is why two quotes requested moments apart may select different paths.

What the quote actually charges

Jupiter swap costs combine a platform fee, fees charged inside selected liquidity venues, and Solana transaction fees. These components reach different recipients and appear in different parts of the quote. Price impact is separate: it describes the trade moving through available liquidity rather than a charge transferred to a fee collector.

The Meta-Aggregator schedule uses basis points, where 1 basis point equals 0.01%. Buying JUP, JLP, or jupSOL from SOL or a stablecoin carries a 0-basis-point platform tier. Pegged LST-to-LST and stablecoin-to-stablecoin pairs also use 0 basis points. SOL-to-stablecoin routes use 2 basis points, LST-to-stablecoin routes use 5, and other established pairs use 10. Tokens within their first 24 hours use 50 basis points, equal to 0.50%.

Pool fees are taken within Raydium, Orca, Meteora, or another venue used by the route. A route with two pool hops encounters two venue-fee events. Solana then charges 5,000 lamports for each signature as its base fee. Since 1 SOL contains 1,000,000,000 lamports, a one-signature base fee equals 0.000005 SOL before any priority fee. The quote identifies whether Jupiter's fee is collected from the input or output token.

Wallet, token accounts, and the first signature

A first Jupiter trade needs a Solana wallet, the correct pair of mint addresses, an input balance, and transaction-fee funding. Phantom, Solflare, and Backpack are established wallet interfaces that support Solana transaction signing. Gasless execution exists for qualifying Meta-Aggregator orders, but the displayed order must explicitly provide it; otherwise, the fee payer needs SOL.

A Solana address represents a 32-byte public key. The wallet has one main address, while each SPL Token balance sits in a token account associated with a particular mint. A classic SPL Token account occupies 165 bytes and requires a rent-exempt deposit near 0.002 SOL when created. Token-2022 extensions can require larger accounts. An eligible account returns that deposit when it is emptied and closed.

The user flow has three actions: request a quote, sign the prepared transaction, and submit it. Amounts travel in smallest units. SOL uses 9 decimal places, so one lamport is 0.000000001 SOL; native USDC on Solana uses 6 decimal places. Wallet interfaces convert those integers into readable balances.

Where split routing earns its place

Split routing allocates one trade across multiple liquidity sources when a single source would produce less output. The mechanism matters most for larger orders, fragmented long-tail markets, and pairs traded across several automated market makers. Each portion follows the venue offering the strongest marginal price for that slice.

Metis searches integrated onchain venues that include Raydium pools, Orca Whirlpools, and Meteora DLMM pools. JupiterZ adds request-for-quote liquidity from market makers. An indirect path may exchange token A for SOL before exchanging SOL for token B. That two-hop structure introduces 2 venue-fee events and additional accounts, so it wins only when its pricing improvement exceeds the added costs and execution burden.

Every route remains atomic on Solana. Either all legs complete under the transaction's limits, or none of the token movements settle. This property prevents a successful first hop from leaving the wallet with an unintended intermediate asset.

Jupiter, Raydium, Orca, or OpenBook?

Across most deployments, Jupiter, Raydium, Orca, and OpenBook expose different ways to reach Solana liquidity. Jupiter searches across routing engines and integrated venues. The other three provide direct interaction with a particular market mechanism, making the execution source more explicit.

Aggregation fits a market conversion where route discovery matters more than choosing one pool. Direct Raydium or Orca interaction is useful when the trader wants a known pool or is also examining a liquidity position. OpenBook suits posted-order behavior, where bids and asks replace an automated curve.

All four models keep transaction authority with the wallet during ordinary use. Their main distinction is control over construction and pricing. Jupiter chooses the route; a direct venue choice fixes the primary program before the quote is prepared.

Slippage, price impact, and transaction expiry

Slippage tolerance sets the minimum acceptable output, while price impact estimates how the trade itself changes a pool's marginal price. A tolerance of 100 basis points represents 1%. If execution would return less than the minimum, the atomic swap rejects its token movements. A processed transaction still pays its Solana fee even when program execution fails.

Time creates another boundary. A standard Solana transaction carries a recent blockhash. Validators accept the most recent 151 blockhashes, derived from a maximum processing age of 150 because age starts at zero. The blockhash queue stores 300 entries, but older entries are not valid for ordinary transaction processing.

Slots are configured around 400 milliseconds and may stretch toward 600 milliseconds. That places a typical blockhash validity period around 60 to 90 seconds. A JupiterZ request-for-quote order has its own explicit expiry. Signing promptly reduces both blockhash expiry and quote movement without weakening the minimum-output rule.

What non-custodial control means during execution

During normal operation, Jupiter's non-custodial model leaves key control with the connected wallet. The interface does not create a hosted balance or receive the private key. Instead, the wallet signs a prepared Solana transaction that names the accounts, programs, amounts, and execution constraints.

An Ed25519 transaction signature occupies 64 bytes. The signature authorizes that exact message; modifying the message invalidates it. During execution, token programs and liquidity programs update the relevant accounts under Solana's atomic transaction rules. The output returns to an associated token account controlled by the wallet.

Asset identity deserves equal attention. Solana distinguishes tokens by mint address, and identical tickers do not combine into one asset. The wallet prompt should show the intended input mint, output mint, quantities, and fee asset before approval. Once confirmed, an onchain conversion cannot be reversed through the aggregator.

How four routing engines become one transaction

After the first pass, Jupiter's routing stack has two execution paths. The Meta-Aggregator makes 4 engines - Metis, JupiterZ, Dflow, and OKX - compete, then returns an assembled version-0 transaction with managed submission. The Router path uses Metis alone and returns raw instructions, giving an application control over additional instructions, cross-program invocation, and transaction broadcasting.

Metis constructs multi-hop and multi-split routes through onchain liquidity. JupiterZ requests prices from market makers. Dflow and OKX contribute separate routing sources. The winning proposal determines the swap programs, account list, token flow, minimum-output protection, compute-budget settings, and recent blockhash placed in the transaction.

A Solana transaction is capped at 1,232 bytes and 1,400,000 compute units. A non-builtin instruction receives a default limit of 200,000 compute units unless the transaction sets another budget. Priority fees use the requested compute-unit limit, not the amount ultimately consumed, with 1,000,000 micro-lamports equaling one lamport. These limits explain why complex routes need compact account handling and deliberate compute estimates.

A disciplined next step for the first trade

A first Jupiter trade should establish familiarity with the quote and signature rather than test maximum route complexity. Select the intended Solana mints, request a fresh quote, and read the exact input beside the minimum output and fee asset. Submit the signed transaction promptly, then compare the confirmed wallet balance change with the quoted fields.

After that baseline, the aggregator supports straightforward SOL-to-USDC conversions, long-tail SPL Token exchanges, and swaps embedded inside other applications. Route choice becomes the next decision boundary. Managed aggregation handles search and landing, while the Metis Router or a direct protocol offers more construction control. Neither model removes market exposure; it changes who selects the path and who manages submission.