Ray is shorthand for Raydium: Concentrated Liquidity and Swap Routing on Solana

Following a swap across Raydium liquidity

Raydium builds a swap by comparing its CPMM, CLMM, legacy AMM v4, and stable pools for the requested token pair. It then presents the route with the strongest quoted outcome.

For a SOL-to-RAY request, the interface first treats SOL as wrapped SOL for token-program transfers. A direct wrapped SOL/RAY pool might return the strongest quote. If another path pays better, the route exchanges wrapped SOL for USDC, then USDC for RAY. The intermediate USDC exists only as part of the completed route. Both hops settle atomically in one Solana transaction, so they either complete together or leave token balances unchanged. Each pool contributes its own fee and price movement, while AMM Routing adds a 0% router fee.

The displayed output therefore reflects the chosen pools, their active liquidity, and the trade size. A shorter route uses fewer accounts, yet a two-hop route can still deliver more output when its combined depth offsets the additional pool fee.

Starting with a wallet, SOL, and a token pair

A first Raydium swap requires a Solana wallet, enough SOL for network fees, and confirmed input and output mints. Phantom, Solflare, and Backpack all support Solana transaction signing.

The related steps are listed in Ray requirements. Solana charges a base fee of 5,000 lamports for each signature, and 1 SOL contains 1,000,000,000 lamports. A priority fee is optional and pays for requested compute units during congestion. Its price uses micro-lamports per compute unit, with 1,000,000 micro-lamports equaling 1 lamport. Keep a separate SOL balance for those charges and for any new associated token account. The pool fee comes from the swap amount rather than the wallet's SOL fee balance.

Before signing, use this decision checklist:

• Match each mint address to the intended token, because symbols are not unique identifiers.
• Compare expected output, hop count, pool fees, and price impact on the displayed route.
• Leave enough SOL for the base fee, priority fee, and any associated token account.
• Read the minimum received value and reject terms below your acceptable output.
• Separate any Token-2022 transfer fee from the fee that the liquidity pool charges.

When the input is native SOL, Raydium handles wrapping inside the transaction and returns unused SOL as the route permits. Output tokens settle into an associated token account derived from the wallet and mint. The first interaction with a mint can create one such account, which adds account funding and another instruction. A wallet preview should show these state changes before the signature request. A closer look is available in Ray walkthrough.

Concentrated ranges and capital efficiency

Concentrated liquidity on Raydium places two assets between a lower and upper price, keeping that capital active only while the market remains inside the selected range.

The documented primary Raydium CLMM configurations use four base fee tiers with matching tick spacings: 0.01% uses spacing 1, 0.05% uses 10, 0.25% uses 60, and 1% uses 120. Tighter spacing gives liquidity providers finer control over range boundaries. Each position has exactly 2 boundary ticks, and both boundaries must align with the pool's spacing. Stable or closely correlated pairs fit tighter grids, while volatile pairs need enough width to avoid frequent range exits.

In Raydium CLMM, prices map to ticks from -443636 through 443636, with each adjacent tick representing a 1.0001 price ratio. The program stores square-root price in Q64.64 fixed-point form, using 64 integer bits and 64 fractional bits instead of floating-point arithmetic. Fees accrue to a position only when its liquidity participates in the active tick. Crossing a boundary changes the position's token composition as the pool trades through it.

A narrow range concentrates depth near the chosen price. A wider range sacrifices fee density for longer active coverage and less frequent repositioning.

Pool fees, network fees, and price impact

A Raydium swap pays the pool's trade fee, Solana network fee, optional priority fee, and any Token-2022 transfer fee. The interface combines those costs with price impact in its quote.

For CLMM and CPMM trade fees, the documented allocation sends 84% to liquidity providers, 12% toward RAY buybacks, and 4% to the treasury. The fee denominator is 1,000,000 in CPMM and CLMM configuration accounts. In a hypothetical 1,000-token exact-input swap through a 0.25% pool, with no transfer fee, 2.5 tokens form the gross trade fee. The allocation gives 2.1 tokens to LPs, 0.3 token to buybacks, and 0.1 token to the treasury. Legacy AMM v4 instead assigns 88% of its trade fee to LPs and 12% to buybacks.

Price impact comes from moving along the pool curve, so it rises with trade size relative to active liquidity. A multi-hop quote compounds the pool fees and movement from every hop. Solana gives a non-built-in instruction a default budget of 200,000 compute units and caps a transaction at 1,400,000 compute units. Priority pricing changes transaction scheduling, not the pool's exchange rate.

How does Raydium execute a multi-hop swap?

Day to day, Raydium executes a multi-hop swap by passing one pool's output directly into the next pool as input inside one atomic transaction. The final output must meet the user's minimum.

The routing program orchestrates the calls but delegates pricing to each child program. Its four pool families use their own mechanisms: AMM v4 and CPMM apply constant-product curves, CLMM follows tick-based concentrated-liquidity math, and Stable uses its stable-swap curve. The pools read on-chain reserves and state rather than asking Pyth for an external spot price. Exact-input routing starts from a fixed spend, while exact-output routing works backward from a required receipt.

Routes with 2 or more hops require additional pool accounts, token accounts, and cross-program calls. Solana permits a maximum instruction stack depth of 5, counting the top-level instruction, which constrains deeply nested program composition. Client-built routes can also place separate swap instructions in the same transaction. Raydium's dedicated router is most useful when one coordinated call simplifies those intermediate flows.

Range exposure, token rules, and pool constraints

The main Raydium exposures come from active price ranges, pool depth, token-program rules, and irreversible on-chain execution. Each factor changes either position value or transaction outcome.

A CLMM position stops earning swap fees after the market moves outside its range, although previously accrued fees remain claimable. As trades cross the 2 boundary ticks, the position shifts toward one token and eventually becomes fully single-sided. Its value can trail simply holding both starting assets, which is the usual impermanent-loss exposure. CPMM liquidity stays active across the constant-product curve, yet it gives up the targeted capital efficiency of a narrow range.

Both Raydium CPMM and CLMM support classic SPL Token mints and gated Token-2022 mints. The default Token-2022 creation allow-list recognizes 5 extensions: TransferFeeConfig, MetadataPointer, TokenMetadata, InterestBearingConfig, and ScaledUiAmount. AMM v4 accepts classic SPL Token mints rather than Token-2022. A mint-level transfer fee applies on token transfers in addition to the pool fee, so the quoted net receipt matters.

Pool depth also changes from one pair and fee tier to another. An LP who does not want to monitor boundaries has a simpler position in CPMM, while CLMM rewards deliberate range management.

Jupiter, Orca, and Meteora as Solana alternatives

Jupiter suits traders who want aggregation across many venues, while Orca and Meteora offer different liquidity designs on Solana. Jupiter can route through Raydium and other sources, so it is a routing layer rather than one pool family. Orca Whirlpools uses concentrated liquidity with its own tick and fee configuration. Meteora DLMM organizes liquidity into discrete price bins. The decision turns on whether the task needs Raydium-native pools, cross-venue routing, Whirlpool positions, or bin-based liquidity.