Ray requirements are SOL Fees and SPL Token Account Setup

SOL reserves cover network, priority, and account costs

A RAY swap needs SOL for the base network fee, any selected priority fee, and each missing token account deposit.

Solana denominates fees in lamports, and 1 SOL contains 1,000,000,000 lamports. The base fee is 5,000 lamports for each required signature. That equals 0.000005 SOL for a one-signature transaction. An optional priority fee multiplies the requested compute-unit limit by the chosen price in micro-lamports, divides by 1,000,000, and rounds upward to whole lamports. The priority calculation uses the requested limit, not the units actually consumed. The runtime assigns 200,000 compute units to a standard non-built-in instruction by default and caps a transaction at 1,400,000 units, although Raydium routes normally carry an explicit compute budget.

A classic RAY associated token account stores 165 bytes and holds a rent-exempt balance of 2,039,280 lamports, or 0.00203928 SOL. Those lamports stay in the account rather than going to Raydium, and closing the empty account returns them to the chosen recipient. Published Raydium CLMM configurations use 0.01%, 0.05%, 0.25%, and 1.00% pool-fee tiers. A pool's onchain configuration fixes the rate for its quote, so this trading charge reduces token value while the network and account charges consume SOL, and the chosen route may apply that configured rate across more than one pool. Together, these Ray requirements separate trade capital from transaction overhead.

How much SOL should remain after the swap?

Keep enough SOL for every displayed overhead item after separating the amount that the trade itself will spend.

Read the transaction preview as a budget before approving it. Separate the swap input, base fee, priority fee, and new-account funding. When USDC supplies the input, the USDC amount does not pay Solana charges; the wallet still needs SOL. When SOL supplies the input, subtract every overhead item before entering the trade amount, because the fee payer must fund the complete transaction. The preview might group them under a single approval, yet the funding sources remain distinct.

One worked example uses five hypothetical changing inputs: a USDC-to-RAY swap, one required signature, a 300,000-unit compute limit, a price of 10,000 micro-lamports per unit, and no existing RAY account for the destination wallet. The base fee is 5,000 lamports. The priority formula produces 3,000 lamports: 300,000 × 10,000 ÷ 1,000,000. Adding the 2,039,280-lamport account deposit gives 2,047,280 lamports, or 0.00204728 SOL, required beyond the USDC trade amount. A larger compute limit or price raises only the priority component, while an existing RAY account removes the deposit.

Leave more than the computed total because a refreshed route may request a different compute limit or another temporary account.

The RAY mint determines the associated token account

The RAY mint fixes the destination account that Raydium uses for a particular wallet.

RAY is an SPL token on Solana with the canonical mint address 4k3Dyjzvzp8eMZWUXbBCjEvwSkkk59S5iCNLY3QrkX6R and six decimals. One whole RAY equals 1,000,000 base units. The Associated Token Account Program derives the canonical account from three inputs: the owner public key, the SPL Token Program ID, and the RAY mint. Each public key occupies 32 bytes. Because derivation is deterministic, Phantom, Solflare, and Backpack show the same RAY address for the same owner. Raydium can include an idempotent creation instruction when that account is absent. The SPL Token Program owns the account data, while the wallet retains authority over its tokens.

v0 signing keeps Raydium routes within Solana limits

From a cost perspective, Raydium routes require a wallet that can decode, display, and sign Solana version 0 transactions.

Solana supports two message formats: legacy and version 0, commonly written as v0. Raydium uses v0 messages with Address Lookup Tables when a route needs many accounts. A lookup table stores up to 256 public keys, and a transaction references each selected key through a 1-byte index instead of its full 32-byte value inside the versioned message that validators receive. That substitution saves 31 bytes per resolved address, helping the route remain within Solana's 1,232-byte transaction cap and 64-account runtime limit.

Additional context appears in Ray walkthrough. Wallet Adapter establishes the connection between Raydium and a wallet interface; it does not sign the transaction itself. Phantom, Solflare, and Backpack are established Solana interfaces that support the required transaction format. The approval screen should expose the fee payer, token movements, network, and requested programs. Confirm that it names Solana mainnet and the RAY mint before signing. The connected public key must match the owner used to derive the output account; switching wallet accounts after the quote changes the required address list. A legacy-only signer cannot parse and sign the v0 message, so it cannot approve the built route.

Why does a valid quote still fail at signing?

A Raydium quote still fails when the signer, SOL reserve, account state, or recent blockhash no longer matches the built transaction.

Insufficient SOL stops simulation or execution before the swap can create the RAY account, even when the quoted token amounts remain valid.

The recent blockhash is another hard precondition. Validators accept a recent blockhash through a maximum processing age of 150, which yields 151 valid ages when age zero is included. The BlockhashQueue stores 300 entries, but older entries do not qualify for ordinary transaction processing. Delayed approval crosses that boundary, so Raydium must rebuild the message with a fresh quote, blockhash, account list, and compute budget rather than resend the same signed bytes.

Solana executes the instruction list atomically: every instruction succeeds, or all state changes roll back. The network still charges the transaction fee after execution starts, including when a pool instruction rejects stale slippage limits. An unsupported v0 message fails earlier at the wallet, while a changed account or expired blockhash fails during preflight or submission. Idempotent creation makes a newly appeared canonical token account harmless; the other route accounts still have to match. Rebuilding aligns the RAY destination, route accounts, and fee calculation with the next signature.

Onchain records confirm setup and preserve the account

The confirmed transaction record shows whether the fee payer, token accounts, and RAY balance change matched the signed instructions.

Open the signature in Solana Explorer or Solscan and locate the success status, signer, fee, and token balance changes. The invoked programs should match the route and its setup work, including Raydium, the System Program, the Associated Token Account Program, and the SPL Token Program where applicable for account setup. The post-transaction RAY balance must sit under the canonical mint and the derived owner account. The fee field reports consumed lamports, while account balance differences show deposit movement separately. This comparison distinguishes the recoverable account deposit from the consumed network fee and the pool's trading charge.

Solana exposes three commitment labels - processed, confirmed, and finalized - and the transaction metadata provides two balance snapshots, before and after execution. Keep the same associated token account for later RAY swaps, because reuse requires no new storage deposit. Close it only after its token balance reaches exactly zero; the close instruction then recovers the 2,039,280 lamports held by that 165-byte account.