Raydium swap is a route from quote to confirmed output
Raydium swap is a Solana token-exchange workflow that turns a selected input into a quoted route, a wallet-authorized transaction, and a confirmed output balance. The quote names both mint addresses, estimates the received units, and embeds an execution threshold. Raydium then selects one or more liquidity pools, while the wallet approves the assembled instructions. Completion requires three separate checks: successful execution, the expected token-account change, and an actual received amount that satisfies the signed threshold.
Stale quotes are the first avoidable mistake
The most common Raydium swap mistake is signing an old quote after the amount, pool state, destination account, or transaction format has changed.
A valid quote binds four practical inputs: the input mint, output mint, raw amount, and slippage tolerance. Raydium exposes two amount modes. Exact-input fixes what leaves the source account; exact-output fixes what must arrive and calculates the allowed spend. Its Trade API accepts slippage from 0 to 10,000 basis points. One basis point equals 0.01%, while 100 basis points equal 1%. Those constants define the execution boundary, not a suggested setting. Refresh the quote whenever the token pair, amount mode, amount, wallet, or transaction format changes.
Compare the displayed symbols with the 32-byte mint addresses before signing. Phantom and Backpack abbreviate addresses, so expand the details and confirm the source amount, destination mint, and threshold.
Once those fields match, the next decision concerns the pool path beneath the displayed exchange pair.
How does Raydium choose a swap route?
Raydium chooses the route that yields the strongest quoted output after each eligible pool applies its own curve and configured fee.
The routing program orchestrates four Raydium pool models: AMM v4, CPMM, CLMM, and stable pools. Each hop performs its own pricing, while the router passes output forward and checks the final threshold. It doesn't reprice a hop after execution starts.
Direct, multi-hop, and split paths
A single-pool route touches 1 pool and has the simplest account set. A multi-hop route chains 2 or more swaps through an intermediate mint. A split route allocates input across 2 or more pool legs, then combines their outputs atomically. Jupiter takes a broader aggregator approach across multiple venues, including Raydium. Direct swaps on Orca or Meteora stay within those protocols, while OpenBook and Phoenix use order-book execution.
Quote and message choices
The workflow separates amount selection, route shape, and Solana message format into distinct choices.
| Option | Fixed element | Standard count |
|---|---|---|
| Exact-input quote | Source spend | 1 input amount |
| Exact-output quote | Destination receipt | 1 output amount |
| Single-pool route | One pricing curve | 1 pool |
| Multi-hop route | Sequential token path | 2 or more hops |
| Split route | Parallel input allocation | 2 or more pool legs |
| V0 message | Lookup tables permitted | 1 versioned format |
| Legacy message | Addresses stored inline | 1 legacy format |
| Summary | Quote, path, and message choices remain separate | 7 compared options |
On-chain Raydium amounts use unsigned 64-bit integers, and pool calculations use 128-bit intermediates where needed. Visible decimal placement comes from each mint's metadata rather than the router.
Route selection changes when reserves, active CLMM ticks, pool configuration, or the chosen amount mode produces a different output.
Wallet confirmation is the execution boundary
Wallet confirmation authorizes the exact Solana message that Raydium assembled; changing any field afterward invalidates the wallet's Ed25519 signature.
Amounts and accounts
The confirmation view should expose five concrete elements:
- The input mint and exact or maximum debit
- The output mint and minimum or exact receipt
- The Raydium pool programs used by the route
- The fee payer and compute-budget settings
- Any token-account creation or SOL wrapping instructions
Signature and compute budget
A Solana public key is 32 bytes, and an Ed25519 signature is 64 bytes. The base network fee is 5,000 lamports per signature. An optional priority fee multiplies the compute-unit price by the requested limit, then divides by 1,000,000 and rounds up. One lamport contains 1,000,000 micro-lamports. The default allocation is 200,000 compute units per non-builtin instruction, while one transaction has a 1,400,000-unit ceiling.
Message format
Solana v0 and legacy transactions are capped at 1,232 bytes, including signatures and the serialized message. V0 messages support address lookup tables, each holding up to 256 addresses through 1-byte indexes. The runtime loads no more than 64 accounts for a transaction. Legacy messages keep their addresses inline, so complex routes reach the size boundary sooner.
A builder may return several transactions when account setup or SOL wrapping is required. Each message needs its own authorization and must be submitted in sequence.
V0 becomes more useful as pool legs, token accounts, and setup instructions increase the route's account count.
From signature to final status
A Raydium swap signature identifies a submitted Solana transaction, while confirmation status shows whether its instructions entered the ledger successfully.
Solana exposes 3 commitment labels: processed, confirmed, and finalized. Processed means a validator handled the transaction; confirmed adds cluster voting; finalized represents the strongest standard commitment. Those labels don't replace the execution result. Inspect the metadata error field, since a confirmed transaction can contain a failed program instruction. Raydium tracks the sequence, while Solscan and SolanaFM expose the signature, slot, fee, programs, and balance changes. A wallet's sent message proves submission, not receipt of the output token.
Solana's BlockhashQueue stores up to 300 recent hashes, but the runtime accepts only the 151 newest for normal transaction processing. The maximum processing age is 150 because the queue is zero-indexed. With slots configured for 400 to 600 milliseconds, the usable window lands around 60 to 90 seconds. Record the transaction's last valid block height instead of relying on a wall-clock timer.
The next action changes when the status becomes successful, explicitly failed, or definitively expired by block height.
Output checks across token accounts
On the same footing, Raydium output verification compares confirmed token-balance changes with the quote's output mint and signed execution threshold.
Solana transaction metadata exposes preTokenBalances and postTokenBalances for accounts touched by the message. Match entries by owner, mint, and account index, then subtract the pre-swap amount from the post-swap amount. An owner, mint, and token-program tuple has one canonical associated token account, although the owner can hold additional token accounts for the same mint. Inspect both the original SPL Token Program and Token-2022 because their account owners differ. A newly created account may hold the full output even when a wallet balance cache still shows zero.
Native SOL follows another ledger path. One SOL contains 1,000,000,000 lamports. Wrapping transfers lamports into a token account and synchronizes its WSOL amount; unwrapping closes the WSOL account and returns lamports to the system account. Read token output and SOL fee deltas separately.
For a Token-2022 mint with a transfer-fee extension, Raydium quotes the net output received after that transfer fee. Compare the owner's balance increase with the net quote threshold, not the gross amount that moved from a pool vault.
This balance method spans Raydium's AMM v4, CPMM, and CLMM generations. The account location changes when the output is native SOL, WSOL, or another SPL token.
When should a failed transaction be quoted again?
A failed Raydium swap should be quoted again after slippage rejection, blockhash expiry, stale pool data, or any changed input.
No signature or a canceled prompt
A canceled wallet prompt creates no on-chain transaction. The same quote remains informational, but refresh it before another confirmation if pool state or any selected field has changed.
Expired submission
Keep polling the existing signature until it succeeds, returns an explicit error, or its last valid block height passes. Don't sign a replacement while the first message remains eligible, because the replacement is a separate transaction. After expiry, request a new quote, build a message with a fresh blockhash, and sign again. A further page states it in practice.
Executed program error
ExceededSlippage means the threshold rejected the swap atomically. Input and output changes roll back, while Solana still charges the base and requested priority fees. InvalidAccountData or missing pool data calls for refreshed pool state and a new quote. If the proposed output is zero or extremely small, reduce the input or select a route with sufficient liquidity before signing.
Recovery follows the observed state: canceled prompts need confirmation, expired messages need rebuilding, and executed errors need corrected inputs or a fresh route.
Worth knowing
-
Is SOL required when swapping two SPL tokens on Raydium?
- Yes, the transaction's fee payer needs SOL unless another signer sponsors the network and account-creation costs. Solana charges a base fee of 5,000 lamports per signature, plus any requested priority fee. Creating a missing associated token account also requires a rent-exempt SOL balance. Holding only the two SPL tokens doesn't cover those native network charges.
-
Why does Phantom show several instructions before one Raydium signature?
- Phantom shows several instructions because one atomic Solana transaction can perform multiple operations. A Raydium message may set the compute budget, create an associated token account, wrap SOL, execute one or more pool hops, and close a temporary WSOL account. One signature authorizes the complete serialized message. If the builder returns multiple transactions instead, Phantom requests a separate signature for each message.
-
Where does native SOL appear when Raydium unwraps WSOL?
- Native SOL returns to the wallet's system account when Raydium closes the temporary WSOL token account. One SOL equals 1,000,000,000 lamports, and the unwrapped amount appears as a lamport-balance increase rather than an SPL token-account increase. The final SOL delta also includes network fees and any reclaimed account balance, so it shouldn't be compared directly with a token-only output field.
-
Does Token-2022 change the amount shown after a Raydium swap?
- A Token-2022 mint with an active transfer-fee extension changes the net amount credited to the destination account. Raydium's quoted output represents the amount received after that transfer fee, while the interface distinguishes it from the pool fee. Verify the destination owner, mint, and post-transaction balance delta. A Token-2022 extension without transfer fees doesn't create this particular difference.
-
Can the same signed Raydium transaction be broadcast twice?
- Rebroadcasting identical signed bytes doesn't create a second independent swap because the message retains the same signature and recent blockhash. Resubmission helps an eligible transaction reach another RPC node, but it remains the same transaction identity. Once its last valid block height passes, rebuild with a fresh quote and blockhash. That replacement receives a new signature and represents a separate execution attempt.
-
Why is a Solana network fee charged after a rejected Raydium instruction?
- Solana deducts the transaction fee before executing the Raydium program instructions, so the fee remains charged when execution returns an error. The base component is 5,000 lamports per signature, and the requested priority component also applies. Atomic execution rolls back the attempted token changes, leaving the input and output balances unchanged. Review the recorded error before requesting a corrected quote and signing another transaction.