Raydium setup is SOL Fee Funding and SPL Token Account Readiness

Raydium and Jupiter require the same Solana wallet groundwork

From there, Raydium and Jupiter both require native SOL for Solana fees and any new token accounts.

Raydium builds direct routes across its CPMM, CLMM and AMM v4 pools. Jupiter aggregates liquidity from multiple Solana venues and selects a Raydium pool when that route quotes best. That routing distinction does not change the fee payer, account ownership or receiving-account rules. Both paths settle token movements through Solana programs, and both reuse an existing associated token account when the wallet already has one for the output mint. Connecting the same wallet therefore exposes the same SOL balance and deterministic accounts, even though each interface presents route details differently. A second page unpacks Raydium troubleshooting.

A missing output account is created beside the swap or in a preceding setup transaction. In either interface, the wallet funding the transaction supplies the rent-exempt deposit and network fee. The route determines liquidity execution; the mint and account state determine setup cost.

A low SOL balance is the first setup failure to prevent

Insufficient native SOL prevents the transaction from paying the network or creating its missing accounts.

USDC, RAY and other SPL token balances cannot replace SOL as the Solana fee asset. Even a token-to-token swap needs native SOL in the system account controlled by the signing wallet. A SOL-to-token swap also needs a remainder beyond the input amount because the input, base fee and account deposits draw from the same native balance.

Consider a wallet holding an input token and no SOL. Raydium displays a quote because quoting reads pool state, yet the wallet cannot submit the signed transaction. A second wallet might hold enough for the 5,000-lamport signature fee but lack the 2,039,280 lamports needed for a new classic output account. Solana executes a transaction atomically, so a failed creation instruction prevents the swap from committing and leaves the input balance unchanged. The quote remains informational until a fee-funded transaction reaches the network.

For Raydium setup, fund the signing address with native SOL over the Solana network before requesting the final transaction. The required reserve rises when another associated account, extra signer or separate setup transaction appears.

The fee payer covers signatures, compute priority and account creation

The Solana fee payer funds three separate layers: signatures, optional priority and account storage.

Solana charges a base fee of 5,000 lamports for every signature in a transaction. One SOL equals 1,000,000,000 lamports, while one lamport equals 1,000,000 micro-lamports. A standard user swap carries one wallet signature when the connected wallet is its sole signer. Extra signers increase the base portion in 5,000-lamport steps.

The priority charge equals the requested compute-unit limit multiplied by the CU price, rounded up after division by 1,000,000. Solana assigns 200,000 compute units to each non-builtin instruction by default and caps a transaction at 1,400,000 compute units. Raydium or the connected wallet chooses the price from network conditions. Account creation adds its rent-exempt deposit separately. The serialized transaction must also fit Solana's 1,232-byte limit, which shapes complex routes.

Associated token accounts determine where swap output settles

An associated token account gives one wallet a predictable receiving address for one mint and token program.

The Associated Token Program derives this address from three inputs: the 32-byte wallet owner, token program identifier and mint address. The resulting account stores a token balance rather than native SOL. A classic 165-byte account belongs to the SPL Token Program; an extension-bearing account belongs to Token-2022. Raydium includes the user input and output token accounts as writable accounts in the swap transaction.

Wallet software presents several ancillary token accounts as one displayed balance when it supports aggregation, but Raydium still sends output to the account named in the transaction. When the canonical associated account is absent, the transaction builder inserts its creation before the swap instruction.

A first output mint changes the funding calculation

A newly created classic output account makes the minimum setup amount easy to calculate. The 165-byte account takes 2,039,280 lamports and a one-signature transaction adds 5,000 lamports. Together, those fixed components total 2,044,280 lamports, or 0.00204428 SOL, before the priority fee. The swap input and pool fee sit outside that setup total. An existing output account removes its creation deposit; a Token-2022 account or a route returning multiple setup transactions increases the amount the fee payer must hold.

Native SOL becomes wrapped SOL inside token instructions

Native SOL becomes WSOL because Raydium pool instructions move assets through token accounts.

Wrapping native value for token programs

WSOL uses the native mint So11111111111111111111111111111111111111112 and 9 decimal places. The wrapper preserves value at the base-unit level: 1 SOL corresponds to 1,000,000,000 lamports. Raydium builds the wrapping instructions when SOL is the input and the unwrapping instructions when SOL is the requested output, so the wallet still begins and ends with native SOL.

Syncing the account amount

After lamports enter the WSOL token account, the Token Program's SyncNative instruction updates its recorded token amount. Without that instruction, the token field does not reflect the newly deposited native value.

Closing the temporary account

Closing a WSOL account returns its lamports to the selected destination. Unlike a non-native token account, the Token Program permits a WSOL account to close with a non-zero token amount because the close operation unwraps that value. The setup changes when the route reuses an existing WSOL account instead of creating a temporary one.

Token-2022 changes account size and transfer accounting

Token-2022 mints require extension-aware account sizing and apply configured rules at each transfer.

Extensions change the setup total

A classic token account occupies 165 bytes and needs 2,039,280 lamports for rent exemption. A Token-2022 associated account includes the immutable-owner extension, bringing its minimum to 170 bytes and 2,074,080 lamports. Other enabled extensions increase the data length and deposit further. The transaction builder must inspect the mint's owning program and calculate the correct account size before creating the output account.

A mint with TransferFeeConfig withholds its configured amount on each transfer. The rate uses basis points, where 100 basis points equal 1%, and the mint defines an absolute maximum fee in token base units. This token-level deduction remains separate from Raydium's pool fee, Solana's signature fee and the account deposit.

From a timing perspective, Raydium CPMM supports Token-2022 transfer-fee mints, while CLMM handles them through its SwapV2 instruction. AMM v4 does not support Token-2022. Transfer hooks add required accounts to the transaction, and a default frozen state blocks an immediate transfer until the account state changes. A route pairing one classic mint with one Token-2022 mint passes separate input and output program identifiers to the swap instruction. The mint's extension set therefore determines route eligibility and the final setup requirement.

Wallet compatibility extends beyond showing a SOL balance

A compatible wallet must connect, sign the selected transaction format and expose the correct Solana account.

Phantom, Solflare and Backpack support common Solana application connections, while Ledger signs through a compatible software-wallet interface. Raydium's low-level transaction builder accepts legacy or V0 transactions; complex routes use V0 with Address Lookup Tables. The selected wallet must decode that message, present the requested signature and return it without altering the account list. Choosing the wrong derived Ledger account produces a different fee payer and a different set of associated token accounts.

An Address Lookup Table holds up to 256 public keys. V0 transactions reference each loaded 32-byte address through a 1-byte index, helping routes stay inside the 1,232-byte transaction ceiling. The chosen route and transaction format determine which signing path applies.

Preflight checks reveal account and transaction state

A preflight review confirms the fee payer, token accounts and fixed costs before the wallet signs.

At the other end, Raydium setup reaches a ready state when the quoted transaction matches the wallet's actual onchain accounts. Check these items together rather than treating the displayed swap amount as the complete funding requirement.

• Native SOL remains after subtracting any SOL entered as swap input.
• The input and output mint addresses match the intended SPL tokens.
• The output associated account exists or its creation instruction appears.
• The fee estimate includes every signature, priority charge and rent deposit.
• The preview names the expected Raydium, System Program and Token Program instructions.

Simulation evaluates the instructions without committing account changes. A successful simulation confirms the account list and compute budget worked against the simulated state, while the wallet signature authorizes the actual submission. If the builder emits more than one transaction, preserve its order because an account-creation transaction must settle before a later swap uses that account.

Closing empty accounts and refreshing expired transactions handle edge cases

Account cleanup recovers deposits, while a refreshed transaction replaces an expired recent blockhash.

A non-native SPL token account must hold a zero token balance before its owner closes it. The close instruction sends all remaining lamports to the chosen destination, recovering the rent-exempt deposit. Closing an unused associated account is optional; a later swap into the same mint recreates it and funds the deposit again. Keeping the account avoids that repeated setup when the wallet will receive the mint again.

Validators accept a recent blockhash through age 150; because age begins at zero, 151 blockhashes qualify. Slots target about 400 milliseconds and fluctuate between 400 and 600 milliseconds, giving an ordinary transaction roughly 60 to 90 seconds before expiration. If wallet approval or hardware signing runs beyond that window, request a fresh Raydium transaction. An expired transaction commits no swap or account creation, so the new build should recalculate the fee and recheck account state.