Raydium is a Solana Swap Interface from Preview to On-Chain Balance Verification
Raydium is a Solana swap interface that takes a selected token pair from a live route preview to one signed, atomic transaction. Before approval, it exposes the expected output, minimum received amount, pool sequence, price impact, pool fee and priority fee. After execution, the decisive record is the transaction signature: a successful record shows the input balance falling, the output balance rising and the network fee leaving SOL.
The full cost shown before signing
A Raydium swap has four distinct cost inputs: pool fee, price impact, network fee and any Token-2022 transfer fee.
Pool fees come from the selected pool configuration. CLMM pools publish four trade-fee tiers: 0.01%, 0.05%, 0.25% and 1%. CPMM configurations publish 0.01%, 0.25% and 1%, while Standard AMM v4 uses 0.25%. The route panel identifies each pool and its tier, so a split route can carry two pool fees. A Token-2022 mint with a transfer-fee extension adds its mint-defined charge separately. That transfer fee belongs to the token design, not the liquidity pool. Because fee rates are deducted before curve math, each hop passes a smaller amount into the next pool.
Solana then charges the fee payer in SOL. One signature carries a base fee of 5 000 lamports, while 1 SOL equals 1 000 000 000 lamports. An optional priority charge equals the compute-unit price multiplied by the requested compute-unit limit, divided by 1 000 000 and rounded up to lamports. Solana caps a transaction at 1 400 000 compute units. Raydium offers automatic priority selection: Normal targets the 50th percentile, Fast the 75th and Turbo the 95th.
Price impact is not a posted charge. It is the quote deterioration created by trade size relative to available liquidity. Compare the final expected output across routes, since a lower fee tier can still deliver less after price impact, which is detailed in Raydium alternatives.
Wallet and balance prerequisites
A usable Raydium setup needs a Solana wallet that signs V0 transactions, the input token and enough SOL for execution costs.
Signing capability
The wallet must connect through Solana Wallet Adapter, resolve Address Lookup Tables and support Associated Token Account creation. Connecting reveals the public address and lets the interface prepare transactions; it does not sign a swap. Phantom, Solflare, OKX Wallet and Backpack meet the software-wallet baseline. Ledger and Keystone work as hardware signing options when paired with compatible wallet software.
Recovery belongs to the wallet
Raydium never holds the signing credential or its backup. Phantom, Solflare, OKX Wallet and Backpack create 12-word recovery-phrase wallets, although import support differs. Phantom also offers a Google or Apple recovery path secured by a 4-digit PIN. Ledger creates a 24-word phrase. Keystone generates 24 words by default and imports 12, 18 or 24 words. These recovery methods restore the wallet address; they do not recreate an expired quote.
| Wallet connection option | Backup or recovery standard |
|---|---|
| Phantom | 12-word BIP-39 phrase; Google or Apple plus a 4-digit PIN is an account-based option |
| Solflare | 12-word phrase for a new wallet; 12-word and 24-word phrase import |
| OKX Wallet | 12-word seed phrase or the exported private key |
| Backpack | 12-word seed phrase; 24-word phrase import is supported |
| Ledger through wallet software | 24-word Secret Recovery Phrase generated by the device |
| Keystone through wallet software | 24-word default phrase; 12-word, 18-word and 24-word BIP-39 import |
| Shared rule | Back up the credential controlled by the signing wallet; Raydium stores no recovery material |
A software wallet gives the shortest approval path, while a hardware device separates key storage from the browser or mobile interface.
Building the quote in the swap panel
The swap panel builds a quote from the input mint, output mint, amount and latest eligible Raydium liquidity routes.
Token identity and amount
Select the input and output by mint, not ticker alone. SOL, USDC and RAY are clear display symbols, yet the on-chain mint is the binding identity. The interface also reads each mint’s decimal precision and token program. That distinction matters when one asset follows the original SPL Token Program and another follows the Token-2022 Program.
Exact-in and exact-out
Exact-in mode fixes what leaves the wallet and calculates the expected output; it is the default mode. Exact-out fixes the desired receipt and calculates the required input. The mode changes which side is fixed, but both quotes still carry a minimum or maximum boundary for execution. The confirmation screen labels the chosen mode, so verify which amount remains fixed before opening the wallet prompt.
Quote freshness
The interface refreshes a displayed quote every 10 seconds and flashes when its route changes. Re-read the output, fee tier and minimum received after that update. A newly generated quote is the better decision record than a value left open in an earlier browser state.
Which route should you accept before a Raydium swap?
Accept the route that delivers the strongest net output within your chosen slippage boundary and an understandable sequence of pools.
Next to that, Raydium evaluates eligible CPMM, CLMM and Standard AMM v4 pools after fees. It prefers the highest calculated output, uses deeper liquidity as a tie-breaker and favors one pool over multiple hops. A multi-hop route must improve output by more than 5 basis points before the router prefers it. Large trades can be split across pools when the combined path reduces price impact.
- Expected output after pool charges
- Single-pool, multi-hop or split structure
- Fee tier attached to every pool
- Price impact created by the trade size
- Minimum received after slippage
A single pool is easier to inspect, while a multi-hop or split route earns its complexity only through higher net output.
Slippage as a minimum-output rule
Slippage tolerance converts the preview into an enforceable minimum output rather than granting permission for an unlimited price change.
For an exact-in swap, the transaction carries
minimum output = expected output × (1 − tolerance). The interface default is 0.5%. If execution would return less than that minimum, the swap instructions fail atomically. Raising the tolerance lowers the protected floor; it does not improve the quoted exchange rate or add validator priority.
Price impact and slippage answer different questions. Price impact describes how the quoted trade changes the pool price at its selected size. Slippage sets the further movement accepted between quotation and execution. Reducing the amount directly addresses price impact, while changing tolerance only adjusts the execution boundary.
The wallet approval boundary
The wallet approval prompt is the last decision point before a Raydium transaction receives a signature and reaches Solana validators.
Review the fee payer, input decrease, output increase and program calls in the wallet simulation. A typical SOL-to-token swap contains 2 to 4 instructions: create an output account when needed, wrap native SOL, call a Raydium swap program and close the temporary wrapped-SOL account. A routed swap can add accounts and calls, which is why V0 transaction support and Address Lookup Tables matter.
Approval signs the complete serialized transaction, including its recent blockhash and slippage limit. Changing the amount, route or fee requires a rebuilt transaction and a new signature. Rejecting the prompt returns control to the preview, while signing commits the exact instruction set shown by the wallet.
The on-chain state change after execution
A successful swap atomically debits the input asset, credits the output asset and records every balance change under one transaction signature.
Atomic token movement
The Raydium pool program calculates the exchange, moves tokens through pool vaults and enforces the minimum-output field. Solana applies all instructions as one unit. If any instruction returns an error, token transfers and account creation roll back together. A processed failure still consumes its network fee because validators handled the signed transaction. Successful execution leaves the pool fee inside the protocol’s fee accounting and credits the wallet with the net output. The final output therefore appears only when every account, pool and token instruction accepts the same transaction.
Native SOL and wrapped SOL
Native SOL is temporarily represented as wrapped SOL, or wSOL, when a token-program instruction needs it. The transaction funds a token account, performs the swap and normally closes that temporary account. Closing converts the remaining lamports back to native SOL. This workflow explains why the SOL change includes the swap input, network fee and any temporary account funding before closure.
First receipt of a mint
The Associated Token Program derives one standard account from the wallet owner and output mint. A classic SPL Token account stores 165 bytes and requires a rent-exempt balance; at the standard rent parameter that reserve is 2 039 280 lamports, equal to 0.00203928 SOL. Token-2022 extensions can require more space. If the output account already exists, the route credits it directly. The explorer’s token balance change carries more authority than a delayed wallet display.
Verifying the swap beyond the interface
On-chain verification matches the transaction signature to status, signer, token deltas and the exact programs invoked by the swap.
Open the signature in Solana Explorer, Solscan or SolanaFM. Confirm Success first, then match the signer to the connected public key. Pre- and post-token balances should show the input decreasing and the output increasing by the settled amount. The instruction list should include the relevant Raydium pool or routing program, plus the System Program, SPL Token Program or Token-2022 Program as required. A Solana signature contains 64 bytes, although explorers render it as a longer base58 string. Solana exposes three commitment levels: processed, confirmed and finalized. A confirmed record is stronger than a fresh interface toast, while finalized is the strongest ordinary explorer state.
Recovering from insufficient SOL
Insufficient SOL is resolved by restoring fee headroom in the signing address, refreshing the quote and submitting one newly built transaction.
If SOL is also the swap input, reduce the input amount so the wallet retains the base fee, priority fee and any new-account reserve. When another token is the input, add native SOL over the Solana network to the same public address. A wrapped asset on another chain does not pay Solana fees. Refresh the wallet balance before requesting a new route.
A recent blockhash remains valid for a maximum processing age of 150 slots, so an expired transaction needs a fresh blockhash and signature. Do not resubmit the old serialized transaction after funding the wallet. Adding SOL preserves the intended trade size, while reducing a SOL-input amount is faster when the shortfall is only fee headroom.
Raydium: quick answers
Does Raydium show Token-2022 transfer fees before confirmation?
Raydium includes a Token-2022 transfer fee in the quote when the selected mint has that extension enabled. The interface separates the pool fee from the mint-defined transfer fee, and the quoted output reflects the net amount expected after that charge. Check the wallet simulation as well, because it shows the proposed token balance changes. The mint configuration sets the transfer rate and maximum, not the Raydium pool.
Why can a successful swap appear late in my wallet balance?
A successful on-chain record means the output reached the wallet’s token account even if the wallet interface has not refreshed. Search the transaction signature in Solana Explorer, Solscan or SolanaFM and inspect the post-token balances. If the output mint is hidden, enable its display or refresh the account list. The explorer state is authoritative because it reads the settled account data rather than a cached portfolio view.
When should I refresh the route instead of increasing priority?
Refresh the Raydium route when the quote, pool state or minimum output has become stale; increase priority when transaction inclusion is the problem. A slippage error means the execution boundary no longer matched the pool price, so a fresh quote addresses the cause. An expired or repeatedly delayed transaction points to fee scheduling. Priority changes ordering probability, but it does not repair an outdated route or improve its exchange rate.
Can a split Raydium route settle as separate wallet transactions?
A Raydium split route normally settles as one atomic Solana transaction rather than separate wallet approvals. The transaction contains the required pool calls and passes route amounts between them under one signed message. If any hop fails its checks, the routed token movements roll back together, while the processed network fee remains charged. The explorer therefore shows one signature with multiple instructions, not one final signature for each liquidity pool.