Raydium solana

Raydium Solana is ready to Confirm Only With a Funded SOL Balance

Raydium solana is ready for a swap only when the connected wallet holds enough native SOL to pay Solana transaction costs and, if needed, fund an output token account. The quote is not an approval; it describes the proposed input, estimated output, route, minimum received, pool fee, price impact and priority setting. After signature, one atomic transaction either records every included instruction or records none, though the network still charges a processed transaction fee. Keep trade SOL separate from the fee-payer reserve, inspect the wallet message then verify the signature and balance changes. The sections below follow that decision path from quote to recovery.

How Much SOL Must Remain Before You Sign?

A wallet needs native SOL outside the swap amount because the fee payer funds execution before validators process the Raydium transaction.

Base Fee

Solana sets the base fee at 5,000 lamports per signature, with 1,000,000,000 lamports equal to 1 SOL. A one-signature Raydium swap therefore starts with a 0.000005 SOL base charge before optional priority costs. Each additional signature adds another 5,000 lamports. The runtime deducts the total transaction fee before program execution and keeps it when an executed instruction returns an error. Solana burns 50% of the base portion and sends 50% to the block-producing validator, while the validator receives 100% of the priority portion.

Optional Priority Fee

The priority component comes from a Compute Budget Program price in micro-lamports per compute unit. Solana converts 1,000,000 micro-lamports into one lamport and multiplies the selected price by the requested compute-unit limit. The default allowance is 200,000 compute units per non-builtin instruction, while one transaction tops out at 1,400,000. Raydium’s estimate reflects its assembled route and priority bid, so preserve more native SOL than the 5,000-lamport base alone. First-time token-account funding enlarges that reserve, which is discussed in Using Raydium solana.

A Quote Becomes a Wallet Decision

The confirmation view turns a Raydium quote into a decision by exposing the token movement, route limits and SOL cost before signature.

The Raydium solana confirmation view should identify the input mint and exact input amount, then pair its estimated output with a minimum received value. Read the route as a sequence of pools rather than one headline rate; a CLMM or CPMM hop carries its own pool fee and price impact. USDC and RAY tickers help recognition, but the mint address resolves the asset. The wallet preview should also identify the fee payer, estimated network charge and any Associated Token Program instruction. If any field changes after a quote refresh, evaluate the rebuilt message before signing.

Five Checks Before Wallet Approval

Five concrete checks determine whether the prepared Raydium swap still matches the trade that the connected wallet intends to authorize.

Pause until all five conditions are satisfied because changing the amount, route or priority setting creates a different transaction message.

• The connected address is the intended fee payer and holds native SOL.
• The input mint and exact input amount match the planned swap.
• The output mint and minimum received value remain acceptable.
• The displayed route, pool fee and price impact match the refreshed quote.
• The priority charge and any token-account creation appear in the wallet preview.

Phantom, Solflare and Backpack present transaction details differently, while Ledger adds a hardware-signing step through a compatible wallet. The decision remains tied to the serialized message. Returning to Raydium after editing any field requires a new quote and another review.

Quote Freshness and Commitment States

Raydium quotes describe a momentary route, while Solana commitment labels describe how far the signed transaction has progressed after broadcast.

Recent Blockhash

The BlockhashQueue stores 300 blockhashes, while validators accept a transaction only when its recent blockhash remains within the newest 151 entries. Those accepted entries have ages from 0 through 150 because the queue uses zero-based counting. Once the last valid block height passes, the wallet must sign a newly built transaction. A refreshed quote also needs a fresh review because its minimum output, route or priority bid has changed.

Processed, Confirmed and Finalized

Solana exposes 3 commitment states for this verification path: processed means a node handled the transaction, confirmed means a cluster supermajority voted for its block and finalized means the block reached maximum lockout. Raydium may report completion while a wallet or explorer still refreshes its account view. Use the transaction signature to distinguish a display delay from an unconfirmed submission. For ordinary balance verification, wait until the record shows success at confirmed commitment.

Token Account Creation Changes the SOL Requirement

A missing output token account raises the native SOL requirement because its creation needs rent-exempt lamports in the same atomic transaction.

A standard SPL Token Program account occupies 165 bytes, and one associated token account exists for each wallet, token program and mint combination. The Associated Token Program derives its address from 3 inputs: the wallet address, Token Program identifier and mint address. Token-2022 extensions enlarge some accounts, so the transaction simulation supplies the applicable rent-exempt amount instead of relying on a universal SOL estimate.

Account funding is separate from Raydium’s pool fee and the Solana transaction fee. Its lamports remain in the token account rather than going to the liquidity pool. Closing an eligible empty account later returns those lamports to the selected destination. If the output account already exists, the transaction omits that creation requirement and preserves more of the native SOL balance.

One Signature Authorizes Atomic Execution

One wallet signature authorizes the complete serialized transaction, including pool calls, support instructions and every writable account named in its message.

Solana caps a legacy or v0 transaction at 1,232 bytes. Each Ed25519 signature occupies 64 bytes, while every uncompressed public key occupies 32 bytes. A v0 message reduces address space by referencing Address Lookup Table entries through 1-byte indexes. One table holds up to 256 addresses, although the runtime loads at most 64 accounts for a transaction. Raydium uses this structure to combine Compute Budget Program instructions, token-account preparation and CPMM or CLMM pool calls without asking for a separate approval for every instruction.

The signature covers the message itself. Changing its recent blockhash, account list, token amount or minimum output produces a different message that needs another signature.

Solana executes the included instructions atomically. The System Program, SPL Token Program, Token-2022 and Raydium programs either complete their combined state changes or roll them back together. Transaction fees remain charged after an on-chain program error because the validator already processed the signed message. Wallet simulation provides the last decision point before submitting.

Reading the Balance Changes After Success

A successful Raydium swap changes the input account, output account and relevant pool vaults within one committed Solana transaction.

Input Token Movement

For an exact-input swap, the user’s input token account decreases by the authorized amount. The selected Raydium vault receives the amount used by the pool after any applicable Token-2022 transfer fee. The pool’s programmed swap fee comes from the traded amount, while the separate Solana fee comes from native SOL held by the fee payer.

Output Token Movement

The output vault decreases and the user’s associated token account increases by the executed output. That amount must meet the minimum received value encoded in the transaction or the atomic swap returns an error. A Token-2022 output mint with a transfer-fee extension credits the net amount after its configured transfer fee. Solscan and Solana Explorer expose pre-token and post-token balances beside the transaction status.

Native SOL and Wrapped SOL

During normal operation, Raydium represents SOL as wrapped SOL when token-program instructions require an SPL-compatible account. Wrapped SOL uses 9 decimal places, matching the 1,000,000,000-lamport unit scale of native SOL. A SyncNative instruction updates the wrapped balance after lamports enter that account, while CloseAccount returns eligible lamports to a destination. When SOL is the input, the final native balance reflects the swap amount, transaction fee, priority fee and any account funding shown in the transaction details.

Repairing an Insufficient SOL Setup Error

An insufficient SOL message means the selected fee payer lacks native lamports for the assembled transaction’s immediate requirements.

Cancel the pending prompt and check the native SOL line in the same connected wallet. A wSOL token balance does not independently pay the standard fee-payer charge. Add native SOL to that address or use the wallet’s supported unwrap flow, then reconnect and request a fresh Raydium quote. Leave room for the 5,000-lamport signature fee, the displayed priority component and any rent-exempt output account. Reducing a SOL input amount also restores fee space when the proposed swap consumes nearly the entire native balance.

Do not resubmit an old serialized message after replenishing the wallet. Raydium should rebuild the transaction with a current blockhash and updated fee estimate. Confirm that the intended address remains the fee payer, review the new minimum output then sign once. The transaction signature should progress from processed to confirmed, after which the token balance changes provide the definitive record. An expired attempt without an on-chain record needs a new message and a new signature.