Jupiter swap - Solana token exchange and routing choices

Pool routes and market-maker quotes

Available liquidity determines which exchange mechanism can supply an executable offer. Jupiter compares eligible routes for the requested amount, so changing trade size can change both the output and the route.

Routing through exchange liquidity

Metis, Jupiter’s onchain routing engine, searches decentralized exchanges on Solana. A route can divide the input across liquidity sources or pass through intermediate tokens. Splitting lets the exchange use liquidity in several places, while intermediate hops can connect tokens without a suitable direct market. Neither mechanism creates liquidity where none exists. The quoted output reflects the selected amount and available route, rather than a universal exchange rate.

Competing market-maker offers

JupiterZ uses request for quote, or RFQ: market makers respond with offers for an exchange. These offers compete within Jupiter’s managed aggregation path. They have expiry conditions, and market makers retain execution acceptance rights. A displayed offer therefore doesn’t establish that the exchange has completed. Pool routing and RFQ provide different ways to obtain liquidity, with eligibility determining which offers can compete.

Token identity, spending authority, and receipt evidence

A usable swap requires the intended token identities, sufficient spendable input, and authorization from the wallet controlling that input. A matching ticker alone doesn’t establish that two tokens are the same asset.

The input and receiving token

A mint address identifies a token on Solana. Confirm the selected input and output mints before approving the exchange, especially when names or symbols resemble another token. Liquidity availability doesn’t establish an issuer’s legitimacy. Token restrictions can also prevent trading despite a recognizable name or an apparent balance. The receiving token may need its own token account, which can introduce an account-creation cost.

Wallet approval authorizes the transaction’s instructions. Review the proposed token movements and fee payer before signing; a quote by itself doesn’t grant spending authority.

The recorded exchange

Completion evidence includes a successful transaction record and the actual input and output movements. A transaction signature identifies the record, but signatures can also accompany failures. Jupiter’s managed execution response distinguishes route amounts from the final amounts deducted and received, including applicable swap fees. Compare amounts for the intended token mints, rather than treating an estimated portfolio value as the receipt.

View full-size image

Network costs and conditional gasless execution

Swap costs can include charges within the trading route, a platform or integration fee, and network execution costs. Compare the final quoted output alongside separately funded costs; don’t subtract a fee twice when the quote already includes it.

Solana charges transaction fees in SOL. A priority fee can improve scheduling priority, while account creation may require additional funding. These costs serve different purposes, and a higher priority payment doesn’t improve the exchange rate or supply missing liquidity.

Gasless execution changes who initially pays network costs. Jupiter’s automatic sponsorship can cover eligible swaps when the wallet lacks sufficient SOL, recovering the expense through a higher swap fee and lower output. Eligibility includes a trade-size condition that varies with network costs. Referral settings or a separately supplied fee payer can prevent that sponsorship from applying.

A winning RFQ market maker can instead pay network and priority fees. Output-account rent remains a separate consideration: referral settings can leave that cost with the trader. An integrating application can also supply a fee payer. The order’s payer and fee details establish which arrangement applies; the word gasless alone doesn’t mean every cost disappears.

Output limits and transaction failure

Slippage tolerance bounds acceptable deterioration from a quote; price impact describes how the trade itself affects pricing against available liquidity. An input-fixed swap’s minimum output can prevent execution below its permitted threshold. If an instruction fails within a Solana transaction, the transaction’s instruction changes revert together. Network fees can still apply to a processed failure. Increasing tolerance accepts a worse potential output and doesn’t repair insufficient funds.

View full-size image

---

A funded quote and an insufficient-balance retry

Consider a hypothetical swap preparation in which the selected tokens, amount, balances, quotes, and outcomes are illustrative. The wallet supports the transaction, token identities are correct, and network costs have funding.

In the funded case, the application returns a transaction for the selected amount. After reviewing the output limit and costs, the reader signs and submits it. Suppose execution succeeds. The transaction record confirms success, and its token movements independently establish the amount received. The original estimate no longer serves as the receipt.

In the insufficient-balance case, the application returns pricing but cannot construct an executable transaction. Nothing has been signed or submitted. The reader reduces the entered input to an affordable amount and requests another quote, keeping the same token selection and slippage tolerance.

View full-size image

Suppose the revised request returns a transaction without the balance error. The reader checks its new output and costs before signing. The recovery has produced a usable offer; it hasn’t completed an exchange. Reducing the input resolves this hypothetical balance error without transferring extra funds or loosening slippage protection.

Managed swaps, custom transactions, and deferred orders

The appropriate exchange path depends on whether the task needs an immediate swap, additional transaction instructions, or execution at a later condition. Similar-looking quotes don’t make those capabilities interchangeable.

Managed execution

Jupiter’s Meta-Aggregator path returns an assembled transaction and manages its submission after signing. Eligible routing engines compete, and Jupiter handles confirmation polling. This path suits an immediate exchange that doesn’t require transaction changes. Custom parameters can affect eligibility, so an application’s settings can change the offers available for the same token selection.

Custom transaction construction

The Router path returns swap instructions through Metis. An application can combine them with other instructions and control transaction construction. That flexibility brings responsibility for simulation, compute requirements, submission, and confirmation. It also excludes the RFQ liquidity available through managed aggregation.

Jupiter doesn’t charge its own swap fee on the Router build path, although liquidity-provider charges, integrator fees, and network costs can remain. A lower platform charge alone doesn’t establish a better final exchange. Custom construction is useful when the transaction genuinely needs modification.

Price conditions and recurring exchanges

A deferred order serves a different purpose from accepting an immediate quote. Jupiter’s Trigger V2 supports price-conditioned orders and scheduled exchanges funded through a custodial vault. That deposit arrangement differs from signing a wallet-funded spot swap. A trigger price determines when execution begins; available liquidity and execution conditions determine the delivered output. An immediate swap suits accepting an available offer, while deferred execution suits a specified future condition or schedule.