Ray is a Solana Swap Interface for Confirmation, Token Balances and Insufficient SOL

Leaving no SOL behind creates the first failure

The first avoidable Ray failure comes from spending the wallet’s visible SOL balance without reserving fees and account deposits.

Fee reserve

Selecting the maximum native-SOL input leaves no room when the transaction adds a priority fee or another instruction. Enter an amount below the displayed balance, allow Ray to rebuild the transaction and review the wallet’s SOL change again. A quote prepared before a fee-setting change no longer describes the same transaction. The rest of that story sits in Ray tutorial.

New destination account reserve

The output token needs an associated token account owned by the connected wallet. A base SPL Token account occupies 165 bytes and its rent-exempt deposit is about 0.00204 SOL under established rent parameters. When that account already exists, the creation instruction and deposit disappear. This difference explains why two swaps of the same size can require different SOL reserves.

The SOL costs behind one confirmation

Ray separates the token quote from Solana costs: a base signature fee, an optional priority fee and possible account rent.

Solana sets the base fee at 5,000 lamports for each signature, and 1 SOL contains 1,000,000,000 lamports. Half of the base fee is burned and half goes to the processing validator. The optional priority fee equals the requested compute-unit price multiplied by the requested limit, rounded up after division by 1,000,000 micro-lamports per lamport.

A nonbuilt-in instruction receives a default limit of 200,000 compute units unless the transaction requests another limit. The transaction-wide ceiling is 1,400,000 compute units. Ray’s fee control affects scheduling cost, while pool fees and any Token-2022 transfer fee affect the token amounts. Account rent remains in the new account and returns to an authorized destination when an empty account is closed.

Prerequisites before Ray builds the quote

Where that applies, Ray needs a connected Solana address, a spendable input balance and native SOL in the same fee-paying wallet before quoting.

Phantom, Solflare and Backpack expose the selected Solana account to the interface. A Ledger-backed account still appears as a normal Solana address, with device approval added to the signing flow. Solana addresses are 32-byte public keys, so selecting the correct account matters even when two wallet profiles show similar labels.

The input and output must resolve to specific mint addresses under one of two common token programs: the original SPL Token Program or Token-2022. Ray also checks whether the wallet already owns the required associated token accounts. A displayed symbol such as USDC or RAY helps recognition, while the mint determines the asset and the token program determines the account rules.

Reading the pre-signature quote

The Ray quote tells the reader what leaves the wallet, what should arrive and which route and constraints govern execution.

Typing the input amount produces an exact-input quote: the spend amount stays fixed and the expected output refreshes with pool state. The minimum-received line applies the selected slippage tolerance to that quoted output. Price impact describes how the trade itself moves along the pool curve; it is separate from slippage tolerance. The route identifies each Raydium CPMM or CLMM hop and shows whether an intermediate token is involved. Pool fees belong to the route. A Token-2022 transfer-fee extension belongs to the mint and its deduction appears separately when supported. Every line answers a different confirmation decision.

Read the wallet preview after the interface quote because it reflects the assembled transaction. The preview should name the same input amount, output mint and fee payer. If Ray refreshes while the wallet remains open, close the old approval and request a new transaction so the quote and signature describe one state.

What does the wallet approval actually authorize?

The wallet approval authorizes one assembled Solana transaction from the connected address, not an open-ended series of future swaps.

Balance deltas

Phantom, Solflare or Backpack simulates the transaction and presents estimated token and SOL changes. Compare the input token decrease, output token increase and fee-payer deduction with Ray’s latest quote. Simulation is a preview of the assembled instructions, while final balances come from the transaction recorded on Solana.

Programs and accounts

A Ray swap references a Raydium pool program plus the relevant token accounts and vaults. The transaction may also call the System Program, Associated Token Program, SPL Token Program or Token-2022 and Compute Budget Program. Solana caps a serialized transaction at 1,232 bytes, and cross-program execution supports five invocation levels when the top-level instruction is counted. Those calls remain constrained to the explicit accounts marked readable or writable in the signed message.

Signature scope

The signature covers the exact message, including account addresses, instructions and recent blockhash. Changing an amount, priority fee or account forces construction of a different message. Closing the wallet prompt without signing leaves Ray with no submitted transaction and no transaction signature to verify.

The state change after execution

A successful Ray swap commits every included instruction atomically, changing wallet token accounts and corresponding Raydium pool vaults in one transaction.

For a token-to-token swap, the wallet’s input token account decreases and its output token account increases. The pool vaults record the inverse movement, adjusted for the pool’s fee rules. Native SOL follows an extra conversion step because Raydium pools use WSOL with the SPL Token Program. The transaction wraps SOL, synchronizes the wrapped balance and closes the temporary account when the route calls for native SOL handling. Separately, the fee payer’s native SOL balance covers network fees and any new account deposit. A Token-2022 transfer fee is withheld under the mint’s configured extension rather than paid as network SOL.

Atomic execution keeps the route coherent. A multi-hop swap either records all its token movements or records none of them. Once Solana reports success, the signature identifies the definitive set of pre-transaction and post-transaction balances.

Balance verification across three views

Three views - Ray, Phantom and Solscan - answer different verification questions, so matching their transaction signature gives a complete post-swap check.

Start with Ray’s signature, then open the same signature in Solscan and confirm a successful status. The token-balance records should show the connected owner, input mint and output mint. Finally, refresh Phantom on that same account. Solflare or Backpack provides the equivalent wallet-level check when either wallet supplied the signature.

When a confirmed swap seems absent

A successful Solana record with an apparently unchanged wallet balance points to display state, account selection or token-account visibility.

First match the connected owner address with the owner shown in Solscan. Then inspect the input and output mint addresses in the transaction’s token-balance changes. A newly created associated token account may not appear immediately in a wallet’s cached asset list, and some wallets hide accounts with unfamiliar metadata. Refresh the wallet, switch away from the account and back and search by mint when the wallet supports it. Symbols are presentation metadata; the owner, mint and raw amount establish the balance.

If the explorer shows the output token increase, repeating the swap would create another trade rather than reveal the first one. If the signature belongs to a different wallet profile, switch to that address. A failed signature belongs to the recovery path, while a successful signature calls for a display refresh or token-account inspection.

Resolving insufficient SOL without changing the trade

An insufficient-SOL message means the designated fee payer lacks native SOL for the assembled transaction, even when the input token balance is adequate.

When SOL is the input, lower the swap amount so native SOL remains available for the 5,000-lamport base fee, any priority fee and possible account creation. When USDC, RAY or another token is the input, adding more of that token does not fund Solana fees; add native SOL to the connected fee-paying address.

Account creation is the overlooked branch. A missing base SPL Token destination account requires the 165-byte account’s rent-exempt deposit, about 0.00204 SOL, in addition to processing fees. Token-2022 extensions can require a larger account and deposit because the mint defines extra account data. After funding or lowering the input, rebuild the quote. Ray’s new simulation then reflects the current balance, account existence and priority setting.

Transaction failure and confirmation delay are different states

Either way, Ray treats an unsubmitted approval, a pending signature and a recorded program failure as three different states requiring different actions.

Before submission

No signature means the wallet did not submit the transaction. Reopen Ray, refresh the quote and approve the newly assembled message. Repeatedly refreshing an old wallet prompt does not create a network record.

Pending signature

A submitted signature should be checked in Solscan before another swap is prepared. A standard recent-blockhash transaction remains valid only while its blockhash sits within the 151-hash processing window, roughly 60 to 90 seconds. During that interval, a pending status calls for observation rather than a duplicate submission.

Recorded failure

A processed failure records the transaction and charges its network fee, but the atomic swap state changes roll back. Read the program error, rebuild the quote and correct the stated input, account or slippage condition. This state calls for a new transaction rather than continued waiting.

A disciplined confirmation sequence

A reliable Ray confirmation follows the transaction’s decision order, from wallet identity and token mints through signature and recorded balances.

Begin with the connected Solana address, then confirm the input mint, output mint and spend amount. Leave native SOL for the network and a possible destination account. Read expected output, minimum received, price impact, pool route and fee lines before opening the wallet. In the wallet, compare balance changes and invoked programs with the fresh Ray quote. Approve once. Record the signature, wait for Solana status and use Solscan to match the owner and token-balance changes. Refresh the signing wallet only after the on-chain state is known. Keep the wallet open until it displays the signature.

This order separates quotation, authorization, execution and display into distinct checks. Insufficient SOL is corrected before signing, a pending signature is observed before retrying and a successful signature is verified before any second trade. Each action follows evidence from the previous stage.