Ray

Ray is a Solana Ecosystem Token Used in Swap and Fee Contexts

Ray is the Raydium swap interface workflow for checking a quote, signing one Solana transaction, and confirming the resulting token balances. It requires a compatible V0 wallet, the input token, and SOL left outside the swap amount for network and account-creation costs. Before signing, inspect the selected pools, expected output, minimum received, price impact, and priority fee. After submission, use the transaction signature and token-balance changes to separate a successful swap from a display delay or an unfunded fee payer.

Reading the route before approval

Three route shapes - single-pool, multi-hop, and split - show how Raydium intends to produce the quoted output. The route panel identifies every pool, fee tier, and allocation before the wallet receives anything to sign.

Single-pool execution

One pool keeps the path legible: input goes into one CPMM, CLMM, stable, or AMM v4 pool, and output returns directly. Read the expected output after the pool fee, then compare price impact with the size of the order. A shallow pool makes that impact larger even when the displayed fee tier stays unchanged.

Multi-hop execution

Two or more pools introduce an intermediate asset, such as SOL → USDC → another SPL token. Each hop charges the fee that its pool configuration defines, and the first hop's output becomes the second hop's input. Accept the longer path only when its final expected output exceeds the direct path after both fees and price impact.

Split execution

A split route assigns percentages across parallel pools, with all allocations totaling 100%. The split seeks a better combined output when one pool lacks enough depth for the full order. Raydium refreshes its displayed quote every 10 seconds, so a changed allocation means the pool state changed; review the new minimum before proceeding.

The balance check that prevents a dead start

5,000 lamports per signature forms the Solana base fee that Ray's connected wallet must fund. Priority pricing and a new associated token account add separate SOL requirements.

Pre-sign decision checklist

• Confirm that the connected address is the intended Solana mainnet account.
• Keep 0.02 SOL outside the exact-input amount when using Raydium's documented working buffer.
• Match the input-token balance against the amount shown in the wallet simulation.
• Allow extra SOL when the destination mint has no associated token account yet.
• Pause if the simulated token debits differ from the route confirmation.

One SOL contains 1,000,000,000 lamports, while one lamport contains 1,000,000 micro-lamports for priority-fee calculation. Solana computes that optional fee from the requested compute-unit price multiplied by the requested compute-unit limit, then divides by 1,000,000. The fee uses the requested limit rather than actual consumption, so an oversized limit spends more SOL without changing the swap quote.

How much SOL must stay in the wallet?

0.02 SOL above the swap amount is Raydium's documented working buffer for a first swap. It covers more than the single-signature base charge.

The base component for one signature is only 0.000005 SOL, yet that number excludes the priority fee and account creation. Raydium presents 0.02 SOL above the intended swap amount as a working buffer, not a protocol-enforced minimum. If the output mint lacks an associated token account, the transaction funds that new account as well. The rent-exempt amount comes from the account size and the network rent calculation at construction time. Leave the buffer untouched, enter an exact input below the spendable balance, and let the wallet simulation display the final debit clearly before signing.

If SOL is also the input asset, the amount in the swap field and the fee reserve draw from the same native balance. Reduce the input rather than submitting the full displayed balance. Ray then rebuilds the transaction with enough SOL left for execution.

Minimum output as the execution boundary

Two execution modes define Ray's bound: exact-input limits the output floor, while exact-output limits the input ceiling. The interface defaults to exact-input for ordinary swaps.

For exact-input, minimum received equals expected output multiplied by one minus the slippage tolerance. A 0.5% setting therefore accepts no less than 99.5% of the quoted output. Raydium's interface guidance uses 0.1% for stable-to-stable pairs, 0.5% for stable-to-major pairs, 1% for major-to-major pairs, and 3-5% for volatile long-tail pairs. Those settings govern movement after the quote; price impact already reflects the order against the quoted pool state. If actual output crosses the floor, all swap state changes revert while the network fee remains charged.

Signing changes a quote into a transaction

A 64-byte Ed25519 signature turns Ray's unsigned preview into an authorized V0 transaction. Connection alone only lets the interface read the public address and balances.

Read-only wallet connection

Phantom, Solflare, and Backpack expose the selected Solana address through Wallet Adapter without authorizing a transfer. Raydium uses that address to fetch balances, derive associated token accounts, build the route, and assign the fee payer. No state changes until the wallet signs and broadcasts the constructed message.

The wallet simulation

A simulation previews instruction effects without committing them. Match the input debit, output credit, network fee, priority fee, and any account-creation funding against the confirmation screen. Ledger-backed accounts add device approval, but the signed message remains the same V0 transaction that a software signer authorizes.

Atomic authorization

Solana permits at most 12 signatures in one packet, although an ordinary Ray swap uses one wallet signature. Every instruction then succeeds together or all token and pool changes revert together. The base and priority fees still leave the fee payer when an executed transaction fails, because validators processed the signed message.

The 150-slot window after submission

150 slots define the recent-blockhash validity window for every standard Ray swap transaction on Solana. A pending interface label does not extend that protocol limit.

A Solana transaction is capped at 1,232 bytes, carries 64-byte Ed25519 signatures, and uses a recent blockhash for 150 slots. Raydium uses versioned V0 transactions and Address Lookup Tables because complex routes reference many pool, vault, token, and program accounts. The enforced account limit is 64, and the executed-instruction trace also stops at 64 across top-level instructions and cross-program invocations. Once the blockhash ages out, resubmitting the old signed bytes does not create a fresh attempt. Ray must rebuild the transaction against a recent blockhash, refresh pool state, recalculate minimum output, and request another wallet signature.

The same question is answered in Ray requirements. Check the transaction signature before retrying. A recorded success means settlement already occurred, a recorded failure means the fee was charged without swap state changes, and no record after expiry calls for a fresh quote. That sequence prevents an accidental second swap.

What changes on-chain after execution?

One atomic Solana transaction moves Ray's input, pool state, output, and required account funding together. The exact instruction set follows the selected route.

Account preparation

A standard SOL-to-USDC path contains 2-4 instructions. The transaction creates the USDC associated token account when absent, wraps native SOL into WSOL for SPL Token Program handling, and prepares any compute-budget settings. Existing destination accounts remove the creation step and its rent-exempt funding.

The pool call

The swap instruction invokes a Raydium CPMM, CLMM, stable, or AMM v4 program. The System Program handles native-account work, while the SPL Token Program or Token-2022 moves token units. Multi-hop routing passes each hop's output directly into the next pool within the same transaction.

Settlement or reversion

Successful execution decreases the input balance, increases the output balance, updates the participating pool accounts, and accrues configured pool fees. Residual WSOL is unwrapped when the route requested native SOL. If any instruction misses its balance, account, compute, or minimum-output condition, Solana restores all program state changes together.

A three-part settlement verification

Three records establish Ray settlement: transaction status, signer identity, and pre/post token balance changes. The interface message alone is a convenience signal.

Open the signature in Solscan, Solana Explorer, or SolanaFM, and first read the final status. Next, match the signer with the connected public address; a Solana public key occupies 32 bytes before Base58 display encoding. Then inspect token balance changes rather than scanning every internal transfer. The input owner's token balance should fall by the executed amount, while the destination token account should rise by the actual output. Program logs identify Raydium, the System Program, the SPL Token Program, or Token-2022 calls that produced those changes.

A successful status with the expected balance deltas settles the question even when Phantom or another wallet still shows the old list. Refresh the wallet, confirm the destination mint, and expose a hidden token account. The on-chain balance remains the decisive record.

Recovery from the low-SOL setup error

Three recovery steps fix Ray's low-SOL setup error: fund, refresh, and sign a newly built transaction. Reusing the previous message preserves its stale balances and blockhash.

First, add SOL to the same public address that the interface names as fee payer, or reduce a native-SOL input enough to preserve the 0.02 SOL working buffer. Second, refresh Raydium so it reads the new balance and reruns simulation. Third, inspect the revised fee estimate, minimum output, and token deltas before signing. A simulation rejection never reaches chain execution, whereas a recorded failed transaction consumes its network fee. The new signature should correspond only to the refreshed route.

When a successful swap looks incomplete

One associated token account address is defined for each wallet, mint, and token-program combination. A wallet interface may hide that account even after successful settlement.

Refresh the token list in Phantom, Solflare, or Backpack, then search by the destination mint rather than its display symbol. The Associated Token Program derives a deterministic address from three inputs: wallet address, token program address, and mint address. Token-2022 uses its own program address in that derivation, so its associated account differs from the original SPL Token Program account for the same wallet and mint.

Native SOL adds one more display distinction. Raydium wraps SOL into WSOL for token-program execution and unwraps residual WSOL when native SOL is the requested output. If the route explicitly outputs WSOL, the value remains in its token account. The explorer's mint and owner fields resolve which balance arrived.

Route mechanics behind the confirmation screen

Four pool mechanisms supply Raydium routes: CPMM, CLMM, stable pools, and AMM v4 with OpenBook-aware reserves. Each child program computes its own output.

The router orchestrates calls rather than imposing one pricing curve. CPMM follows constant-product reserves, CLMM walks concentrated-liquidity ticks, stable pools use a like-asset curve, and AMM v4 includes vault and OpenBook liquidity in its effective state. AMM v4 charges a fixed 0.25% pool fee; configurable CPMM and CLMM fees come from the chosen pool settings. A two-hop path therefore applies two pool fees, while the router adds no separate routing fee.

On-chain amounts use unsigned 64-bit integers, with 128-bit intermediates available for curve calculations. The router collects one hop's integer output, passes it to the next hop, and checks the final amount against the user's minimum. Route review matters because every visible hop becomes a concrete program call, fee deduction, and balance change after signing.

Ray: quick answers