Ray is a Solana Wallet-to-Swap Confirmation Interface

Versioned Transactions Put Wallet Compatibility First

Versioned transaction support is the first gate in Ray's wallet workflow: the signer must accept Solana Wallet Adapter connections and version 0 messages assembled for Raydium routes. Address Lookup Tables compress each 32-byte public key into a 1-byte index and hold up to 256 addresses. This matters because multi-account swap routes still fit beneath Solana's 1,232-byte transaction ceiling. Phantom, Solflare and Backpack meet the workflow; Ledger signs through a compatible software wallet. A legacy-only signer stops before submission, so early compatibility checking prevents a quote from reaching an unusable approval screen.

What Must Be Ready Before Ray Connects?

A usable Ray swap request requires a funded Solana account, a compatible unlocked wallet and enough SOL for the signature fee before route construction begins.

The wallet address becomes the fee payer and the owner of the token accounts used by the swap. One SOL contains exactly 1,000,000,000 lamports, while Solana charges a 5,000-lamport base fee for each signature. A priority fee adds a second component, and creation of a missing Associated Token Account also needs rent-exempt SOL. Because rent is calculated from account size and cluster parameters, Ray displays the built transaction's amount rather than substituting a static estimate. Leave spendable SOL outside the swap amount, or the wallet can have enough tokens yet fail fee checks.

The input token must exist in the connected account, and the output token needs an identifiable mint address. Token symbols don't uniquely identify a mint on Solana.

Phantom, Solflare and Backpack expose the active public key through Wallet Adapter. If a Ledger account sits behind one of them, unlock the device and open the Solana app before requesting a signature. Ray reads public balances and prepares a transaction; connection alone doesn't move tokens. Switching accounts after quote generation changes the signer, so discard the old quote and rebuild it with the newly selected address.

A blank connection modal usually means the browser hasn't detected an unlocked Wallet Adapter provider. Unlock the extension, reload the tab once and reconnect; reinstalling a wallet or importing the seed phrase isn't part of this recovery.

Exact-In and Exact-Out Produce Different Commitments

The amount selector in Ray is a two-mode commitment tool: exact-in fixes the token quantity spent, while exact-out fixes the token quantity received before routing on Solana. The opposite side becomes quote-derived, which changes what the slippage instruction protects. Exact-in encodes a minimum output; exact-out encodes a maximum input. Raydium's interface defaults to exact-in, so most approvals bind the spend amount and a floor for receipt.

Read the mint address, not only the symbol, because an SPL token's mint defines its asset identity and decimal precision. Native SOL uses 9 decimal places, and wrapped SOL follows that 9-decimal unit scale; Solana USDC uses 6. An amount rendered as 1.250000 USDC therefore represents 1,250,000 base units. That conversion doesn't change the economic quote, but it explains the integer balance deltas shown by explorers and helps reconcile the interface's rounded display with the onchain record after execution. The same rule applies after execution. Exact-in is clearer when spend is fixed; exact-out is clearer when receipt must be fixed.

How Does Ray Turn Slippage Into a Minimum?

The slippage control in Ray is an execution boundary, converting quoted output into a minimum amount that the Raydium swap instruction will accept onchain for an exact-in trade. For exact-in, minimum output equals expected output multiplied by one minus tolerance. One basis point equals 0.01%, so 50 basis points equals 0.50%.

Worked example: every changing input is hypothetical: the exact-in amount is 12.000000 USDC, the quoted output is 0.600000000 SOL, slippage is 0.50% and the priority fee is 2,000 lamports. Ray calculates 0.600000000 × (1 − 0.005) = 0.597000000 SOL. The minimum-received field is therefore 0.597 SOL; the 12 USDC spend cap remains fixed, and the priority fee changes scheduling only.

Price impact and slippage aren't interchangeable. Price impact comes from the trade's size relative to available pool liquidity and is already reflected in the quote; slippage permits movement after that quote. Raising tolerance doesn't improve the route or quoted rate. It widens the execution range. Token-2022 mints add another layer when their TransferFeeConfig extension withholds part of a transfer, so Ray's net output must reflect that configured fee before it applies the minimum. A tighter limit protects the receipt amount; a looser limit prioritizes execution across a moving pool.

Wallet Confirmation Is the Last Pre-Execution Gate

The confirmation screen in Ray is a transaction-approval boundary where the wallet shows the fee payer, token movements, programs, network costs and requested signature before broadcast to Solana. Solana's base fee is 5,000 lamports per signature, split 50% burned and 50% paid to the validator that processes the transaction. The priority fee equals the ceiling of compute-unit price multiplied by compute-unit limit, divided by 1,000,000; Solana caps one transaction at 1,400,000 compute units. Ray's priority setting changes this scheduling payment, not the token rate. The preview is the final comparison between quote and message.

Execution Changes Token Accounts Atomically

A Ray swap is an atomic Solana transaction whose instructions debit the input token account, invoke Raydium programs and credit the destination token account together. Atomic means every instruction succeeds or all state changes roll back, although network fees remain charged for processing.

The instruction path depends on the route. A direct pool swap invokes one Raydium market path plus the SPL Token Program or Token-2022; a routed swap includes additional pool accounts and cross-program invocations. If the output Associated Token Account doesn't exist, the Associated Token Program creates it inside the same transaction before the credit. Solana caps a transaction at 1,232 serialized bytes, each Ed25519 signature occupies 64 bytes and a recent blockhash occupies 32 bytes. Address Lookup Tables keep the account list compact when a route touches many vaults and program accounts.

After success, the input balance falls, output balance rises and SOL pays network costs. Ray doesn't hold an intermediate user balance; the ledger records one atomic transition.

What Proves That the Swap Succeeded?

A Ray completion record uses a transaction signature whose Solana entry shows success, the expected signer and matching pre-token and post-token balance changes for both mints. Solana exposes 3 commitment states: processed, confirmed and finalized. Ray's completion message gives the signature, which is the transaction identifier.

Open that signature in Solscan, Solana Explorer or SolanaFM and match four fields. Status must read success; the fee payer must equal the connected wallet; the input mint's token balance must decrease; and the output mint's token balance must increase. The program list includes the Raydium route plus the System Program, SPL Token Program or Token-2022 as required. Explorer interfaces differ in labels, yet they all read the same transaction metadata returned by Solana RPC. This record outweighs a stale wallet display.

Processed is the earliest view, while confirmed adds cluster voting and finalized adds the strongest RPC commitment. For ordinary balance reconciliation, confirmed status plus matching deltas supplies the useful proof.

A Stale Wallet Session Requires a Clean Reconnection

A stale Ray wallet session is a setup-state mismatch where the interface retains an old public key after the user switches accounts or unlocks another extension. Disconnect inside Ray, choose the intended provider again and compare the displayed address with the wallet before requesting a new quote.

Reloading once clears a Wallet Adapter state that no longer matches the active Phantom, Solflare or Backpack account. Don't reuse the earlier quote because its transaction message names a specific fee payer and token-account owner. If a Ledger-backed account is selected, unlock the device and reopen its Solana app before reconnecting through the software wallet. This sequence fixes the common blank-balance or wrong-address setup error without changing token accounts, sending funds or recovering the wallet from its mnemonic. It also keeps the next signature tied to the address shown in Ray.

If balances remain blank after the address matches, check that the wallet uses Solana mainnet and then rebuild the request. A fresh session is preferable to repeated approval attempts.

Expired Blockhashes Require a Fresh Quote and Signature

A Ray submission timeout is a transaction-lifetime failure: Solana rejects a message once its recent blockhash ages beyond the runtime's processing window before inclusion in a block. Solana accepts a recent blockhash through a maximum processing age of 150, representing 151 valid hashes because age starts at zero. The BlockhashQueue retains 300 recent hashes, but validators process only the younger window. The adjacent topic is explained in Ray tutorial.

Expiration doesn't create a delayed swap that will settle later. Ray must fetch a new quote and blockhash, rebuild the transaction and request another signature. The old signature remains useful for verification: if Solana RPC returns no landed transaction and the blockhash has expired, it no longer represents pending execution. Raising a priority fee affects scheduling probability during congestion, while extending slippage only changes the acceptable output boundary. For an expired message, neither edit changes the signed bytes; a fully rebuilt transaction is the relevant recovery. A fresh signed message replaces waiting on an expired one.