Jupiter swap is a pre-sign decision workflow for Solana token trades

Jupiter swap is a pre-sign workflow for checking Solana token mints, the input amount, quoted output, price impact, route, and transaction costs before a wallet authorizes a spot trade. The useful decision is not simply whether to press Swap. It is whether the mint pair, quote limits, execution mode, fee payer, and connected wallet account all match the trade you intend to settle on Solana.

Posted 30 Jul 2026

Complete the six pre-sign passes

The Jupiter swap panel should be read in a fixed sequence from wallet connection to approval. Six passes separate the intended trade from the transaction that reaches the wallet.

1. Connect the intended Solana account through a supported wallet such as Phantom, Backpack, or Ledger through a compatible wallet interface.
2. Select the token being sold and compare its full mint address with the asset you hold.
3. Select the receiving token by mint, then confirm that the symbols have not obscured a different asset.
4. Enter the input amount and wait for a complete quote rather than acting on an unfinished loading state.
5. Open the details and read the quoted output, minimum received, price impact, route, execution mode, and displayed fees.
6. Open the wallet prompt, compare its debit and fee information with the preview, then authorize that transaction.

Changing the wallet account, token mint, input amount, mode, or route settings invalidates the earlier decision. Let the interface build a fresh quote after any such change. A screen showing incomplete route data is not ready for approval, even when the Swap button remains visible.

Which mint must match?

A Solana token's mint address establishes its onchain identity. The underlying public key is 32 bytes, while a name, logo, and ticker remain interface metadata. Compare the complete mint in the token selector, especially when several assets use the same symbol. Circle's USDC, for example, is identified by its Solana mint rather than the letters USDC alone.

The token selector also distinguishes assets governed by the original SPL Token Program from assets using Token-2022. Mint authority, freeze authority, and verification status describe separate properties; none changes the mint itself. Native SOL requires another distinction: wrapped SOL, or wSOL, is an SPL token representation. Jupiter handles wrapping or unwrapping when a route needs it, but the approval still needs to show the intended side of the pair.

Separate quoted output from minimum received

The quoted output is the route's estimated return at quote time. Minimum received is the lowest output the transaction accepts after applying its slippage boundary. Those numbers serve different decisions: one describes the route estimate, while the other defines when the swap instruction must reject execution.

Token decimals explain why wallet and explorer records use larger integers. SOL has 9 decimal places, making 1 SOL equal to 1,000,000,000 lamports. Solana USDC has 6 decimal places, so 1 USDC equals 1,000,000 base units. Jupiter converts those base units into readable amounts, but the transaction carries the integers.

Hypothetical worked example. Suppose the hypothetical quoted output is 500 USDC and the hypothetical Manual Mode tolerance is 0.50%. The threshold equals 500 × (1 − 0.005), producing a minimum of 497.5 USDC. If the hypothetical execution returns 499 USDC, the wallet receives 499 USDC. If it cannot return at least 497.5 USDC, the swap instruction rejects. The applicable result is therefore 497.5 USDC minimum and 499 USDC executed output.

When price impact and slippage disagree

Price impact estimates how the proposed trade changes its own execution price relative to available liquidity. Slippage tolerance defines how far execution may move from the quote before the transaction rejects. A low tolerance does not repair a route with substantial price impact, because the impact is already reflected in that route's quoted output.

Basis points make the boundary easier to audit. One basis point equals exactly 0.01%, 50 basis points equal 0.50%, and 100 basis points equal 1%. In developer quote data, a price-impact value may appear as a decimal from 0 to 1; the user interface converts it to a percentage.

Ultra Mode sets slippage through its Real-Time Slippage Estimator. Manual Mode exposes dynamic or fixed slippage controls. Reducing the input amount requests a new route and reveals whether trade size caused the impact. Treat the new quote as a separate decision rather than carrying approval assumptions forward.

Route details and execution mode

Jupiter route details identify the liquidity sources and allocation behind the quoted output. Route percentages account for 100% of the input, whether one source receives the full trade or the engine divides it across several sources.

Ultra Mode's Juno engine evaluates Jupiter components such as Metis and JupiterZ alongside sources including DFlow, Hashflow, and OKX. Onchain paths also draw from established Solana venues such as Raydium, Orca, and Meteora. An RFQ route from JupiterZ looks different from a path through automated market maker pools, yet both should be judged by the output, impact, costs, and execution conditions shown for that quote.

Manual Mode adds Direct Route Only and automated market maker exclusion controls. Direct routing restricts the trade to one pool. A split or multi-hop route may use intermediate token accounts, but atomic execution leaves the wallet with the selected destination asset when every instruction succeeds.

Use the wallet approval as the final boundary

The wallet approval screen is the last independent view of a Jupiter swap transaction. Phantom and Backpack provide decoded summaries where supported, while a Ledger authorizes through its connected Solana wallet. Compare the sell amount, relevant mint addresses, maximum SOL debit, fee payer, and any account-creation instruction with the preview.

Solana caps a serialized transaction at 1,232 bytes and its compute budget at 1,400,000 compute units. Each Ed25519 signature occupies 64 bytes. A recent blockhash remains valid for 150 slots, so an old prompt eventually becomes unusable even when its displayed quote still looks acceptable.

Solana sets the base fee at 5,000 lamports for each transaction signature. The network burns 50% of that base fee and assigns 50% to the validator; an optional priority fee goes entirely to the validator. The wallet authorizes the transaction message, not the surrounding browser display. Close an outdated prompt and request a newly built transaction after any quote refresh.

What changes after execution?

A successful Jupiter swap atomically decreases the input balance and increases the output balance in the wallet's token accounts. Native SOL also pays the network fee when the wallet is the fee payer. The transaction either completes every required instruction or rolls back the token-account changes as one unit.

The Associated Token Account Program derives a token account from the wallet, mint, and governing token program. Jupiter includes an account-creation instruction when the destination account does not exist. A classic SPL Token account has a 165-byte base layout; Token-2022 extensions require additional space. Rent funding for a new account therefore appears separately from the traded token amount.

A standard spot swap leaves no ERC-20-style standing allowance. The signature authorizes that Solana transaction's instructions. Those instructions may call Raydium, Orca, Meteora, the System Program, and token programs through cross-program invocations. Solana's invocation stack allows 5 levels, counting the top-level instruction as level 1.

Verify success from the signature and balance deltas

The Solana transaction signature is the primary receipt for a submitted swap. Verification requires both a successful transaction status and the expected change between pre-transaction and post-transaction token balances. A success label without the destination mint check does not establish that the intended asset arrived.

Solana exposes 3 commitment levels: processed, confirmed, and finalized. Processed is the earliest observation, confirmed carries stronger cluster commitment, and finalized is the strongest of the three. Transaction details also record the slot, fee, account keys, instructions, inner instructions, and any execution error.

Generally, Jupiter Portfolio Activity provides the interface record. Solana Explorer and Solscan expose the onchain transaction and token-balance data. Match the receiving mint, owner address, and balance increase. When the route created a new associated token account, inspect that account rather than relying solely on a wallet's token-list refresh.

Fix an insufficient-SOL setup error

An insufficient-SOL error means the selected transaction lacks enough native SOL from its designated fee payer. Wrapped SOL does not satisfy this requirement because wSOL is held by the Token Program, while network fees debit a native System Program account.

In Manual Mode, reduce a MAX-sized SOL input or add native SOL, then rebuild the quote. The revised amount must leave room for the 5,000-lamport base fee, any priority fee or Jito tip, and rent when a destination account needs creation. Do not reuse the transaction created against the earlier balance.

Ultra checks gasless eligibility when native SOL is below 0.01 SOL, alongside token and trade requirements. A visible gasless label confirms that the displayed quote uses sponsorship. JupiterZ routes cover network and priority fees, although they do not cover new associated token account rent. Without that label, resolve the native balance before approval.

Refresh after rejection, failure, or expiry

A rejected wallet prompt submits no Solana transaction and creates zero onchain state changes. The quoted route remains only interface data. Reopen the swap panel, obtain a fresh quote, and review the newly built message before deciding again.

An expired transaction is different. Its recent blockhash has passed the 150-slot validity window, so the network will not process it. A transaction that reached the network and failed still pays its network fee, while its other instructions roll back atomically. Check the signature before retrying; a fresh quote and blockhash prevent an old execution boundary from carrying into the next attempt.

Record the executed trade, not the preview

The executed trade record should preserve the transaction signature, slot, mint pair, input balance decrease, output balance increase, and paid network fee. Those fields describe what settled. A screenshot of the preview records a quote, not the final account changes.

Use the wallet's Activity view or Jupiter Portfolio Activity for quick review, then compare it with Solana Explorer or Solscan when precision matters. The onchain record resolves differences caused by rounded interface decimals or delayed token discovery. Save the executed token units and mint address before beginning another trade, particularly when several assets share a ticker.