Raydium troubleshooting is about slippage limits in failed swap execution

Raydium troubleshooting is the process of separating a slippage-bound rejection from a Solana submission or confirmation failure. When a swap fails with an exceeded-slippage message, refresh the quote, compare the quoted output with the minimum received value and either reduce the amount or widen tolerance by a small deliberate increment. A higher priority fee addresses delayed inclusion; it does not change the pool price or relax the minimum output. The sections below follow the swap from quote to confirmation, explain basis-point arithmetic, show how CPMM and CLMM liquidity changes the bound and identify when Token-2022 fees, route changes or stale blockhashes - not the chosen tolerance - cause the failure.

Bottom line: It is the process of resolving failed Solana swaps by adjusting slippage limits when pool price movement pushes output below the minimum.

Rebuilding a failed swap from a fresh quote

A failed Raydium swap needs a fresh quote before any slippage setting changes.

1. Check recent wallet activity first. If a transaction signature exists, read its status before resubmitting.
2. Refresh Raydium and reselect the exact token mints. Confirm the direction and input amount.
3. Record the new expected output, price impact, route and minimum received value.
4. Sign promptly when the minimum remains acceptable. Otherwise, reduce the amount or adjust tolerance by one deliberate step.
5. Inspect the new signature after submission and compare the recorded token balance changes.

Approval delay matters. A quote is a snapshot of pool accounts, and a long pause in Phantom, Solflare or a connected Ledger lets other swaps change those accounts before submission. Refresh immediately before opening the approval prompt when signing takes time. After sending, inspect the same signature in the wallet, Solscan or SolanaFM. A recorded failure needs diagnosis from its log; an absent signature calls for a new quote and blockhash. A successful signature means the swap already settled, even when the wallet hides the newly created token account.

Decision check before signing

• Raise tolerance only when the refreshed minimum received value remains acceptable.
• Reduce size when a smaller quote shows materially lower price impact.
• Raise the priority fee when a transaction expires or remains unseen.
• Rebuild the route when the selected pool or token account changes.

Fees that do and do not change execution

Swap costs and execution limits are separate: pool fees affect the quote while network fees affect submission and ordering.

Solana charges a base fee of 5,000 lamports per signature, equal to 0.000005 SOL because 1 SOL contains 1,000,000,000 lamports. Raydium already includes each pool's trade fee in the quoted output. Under standard AMM v4 parameters, the input-side fee is 25 units per 10,000, or 0.25%. Of the traded amount, 0.22% remains with liquidity providers and 0.03% accrues to the protocol. Those deductions lower the quote before the slippage buffer applies.

A priority fee equals the requested compute-unit limit multiplied by the micro-lamport price and divided by 1,000,000. One million micro-lamports equal 1 lamport. Raising this bid improves transaction ordering during congestion, but it neither raises the pool's output nor changes minimumAmountOut. A processed transaction that fails its amount check still consumes its network fee because Solana executed the instructions far enough to return the failure.

Minimum-output arithmetic and basis points

Raydium expresses slippage as a percentage or basis-point value and converts it into an on-chain amount bound.

One basis point equals 0.01%, so 50 basis points equal 0.5% and 100 basis points equal 1%. The percentage measures permitted deterioration from the quoted output, not from the pre-trade market price. Raydium encodes token amounts as integer base units. USDC uses six decimal places, making one base unit equal to 0.000001 USDC.

Bound direction

The chosen swap mode determines whether the transaction protects output or limits input (also covered in practice ).

Exact-input swaps

For an exact-input swap, Raydium calculates minimum output as quoted output multiplied by one minus the slippage fraction. The following hypothetical arithmetic uses round amounts to expose the boundary rather than model a live market. A quote for 1,000 USDC at 50 basis points creates a 995 USDC minimum. Execution at 994.99 USDC fails, while execution at 995 USDC satisfies the bound.

Exact-output swaps

An exact-output swap reverses the protection: the user fixes the amount received and Raydium calculates maximumAmountIn. A quote requiring 10 SOL with 1% tolerance caps input at 10.1 SOL. If the live pool requires more, the transaction returns without exchanging either asset. Widening tolerance therefore raises maximum spend rather than lowering minimum receipt.

Price impact before the slippage buffer

Price impact changes the quote before Raydium applies the user's separate slippage buffer.

CPMM and AMM v4 pools follow the constant-product relation x × y = k, so a larger order moves farther along the reserve curve. For a small CPMM trade, the spot-price impact approximates twice the input amount divided by the input reserve. CLMM liquidity sits inside tick ranges instead. Crossing a tick boundary changes active liquidity and produces a sharper marginal-price move than a smooth constant-product estimate suggests.

If a quote already reflects 2% price impact, adding 0.5% tolerance places the amount bound about 2.49% below the pre-trade reference after multiplication. The two percentages describe different stages. A two-hop USDC-to-SOL-to-RAY route also contains two mutable pools and two pool-fee deductions. Raydium Routing adds no separate router fee, but every intermediate output becomes the next hop's input. A single SOL-to-USDC CLMM path exposes fewer pool states before execution.

Why does a fresh quote still fail?

A fresh Raydium quote still fails when pool state changes before the signed transaction reaches execution.

Refreshing updates the selected route, reserves and CLMM tick accounts, but signing does not reserve them. Another swap may move a CPMM reserve ratio or push a CLMM price into a different tick range. A route optimizer may also replace one pool with a stronger route while the wallet still holds the older versioned transaction. On a two-hop path, movement in either pool changes the final output. Reduce signing delay, rebuild after a route change and lower the trade size when the same liquid path repeatedly crosses its minimum.

Re-quote after any wallet rejection, amount edit or route switch; the replacement needs refreshed accounts, thresholds and a recent blockhash.

Blockhash age, priority fees and compute limits

Solana transaction age, priority fees and compute limits determine whether a valid Raydium swap reaches and completes execution.

Solana accepts a recent blockhash within a maximum processing age of 150 slots, representing 151 usable ages when zero is counted. At roughly 400 to 600 milliseconds per slot, the practical signing and submission window commonly spans about 60 to 90 seconds. A stale blockhash prevents processing before the Raydium program evaluates slippage, so increasing tolerance does nothing for that failure.

Compute is another independent gate. Solana assigns 200,000 compute units to each non-builtin instruction by default and caps a transaction at 1,400,000 compute units. Raydium's builders add explicit compute-budget instructions for pool routes. Versioned V0 transactions also use address lookup tables to fit multi-account paths within Solana's 1,232-byte transaction limit. A compute-exhaustion log points to the requested limit or route complexity rather than the output threshold.

A higher priority bid helps the transaction reach a leader sooner. It does not extend blockhash validity, alter CLMM ticks or change CPMM reserves.

Matching the repair to the pool path

A Raydium repair should match the pool type and the specific movement shown by the refreshed route.

For a CPMM path, reducing order size lowers movement along the x × y = k curve and produces a less demanding quote. For a CLMM path, a smaller order may avoid crossing a tick boundary; each tick array contains 60 ticks, though usable liquidity still depends on initialized positions. AMM v4 follows constant-product pricing and supports the original SPL Token program rather than Token-2022. CPMM and CLMM SwapV2 support Token-2022 transfer-fee mints. Those mint fees use basis points over a 10,000-unit denominator plus a mint-defined maximum, so the quote must account for them separately from slippage.

Confirming execution and avoiding duplicate swaps

A transaction signature and on-chain status determine whether a Raydium swap needs verification or a fresh attempt.

Solana executes a transaction atomically: every instruction succeeds or all state changes roll back. A successful record should show the input token decrease and output token increase, including any associated token account created during the transaction. A processed failure shows an error and a charged network fee but no completed swap. An expired or never-recorded submission shows no settled token movement. Read the signature before reacting to a stale balance in Phantom or Solflare.

In those conditions, Raydium troubleshooting ends when the explorer status, wallet activity and token-account changes agree. If the transaction succeeded, refresh displayed balances instead of sending another swap. If it failed, rebuild from a fresh quote and change only the control connected to the recorded cause. That sequence prevents a delayed interface update from becoming a duplicate SOL, USDC or RAY exchange.