Raydium

Raydium app is affected by Solana priority fees and blockhash expiry

Raydium app is a Solana swap interface where the priority fee influences when validators schedule a signed transaction, while its recent blockhash sets a hard lifetime. A larger fee bid improves inclusion odds during contention; it does not improve the quoted exchange rate. Once the blockhash expires, resending the same bytes cannot complete the swap. Refresh the quote, obtain a new blockhash, review the new minimum output, and sign the rebuilt transaction.

Last updated 29 July 2026

An expired signature cannot be revived

A Raydium swap becomes unusable after its recent blockhash leaves Solana's validity window, so the app must construct a replacement transaction.

Solana accepts a normal transaction only while its recent blockhash remains within a 150-slot processing window. That lifetime is measured by block height, not by a stopwatch, because skipped slots and RPC timing make wall-clock estimates imprecise. The blockhash occupies 32 bytes in the signed message, and each signer produces a 64-byte Ed25519 signature over that message. Replacing the blockhash therefore changes the message and invalidates every old signature. A wallet must show a new approval request, even when the token pair, input amount, route, and slippage setting look unchanged. This is fundamental to Solana transaction replay protection.

Do not keep broadcasting the old payload. Its bytes identify the expired message, so repeated submission never extends the original window.

A pending label also does not prove expiration. Check the signature in Solscan or Solana Explorer, and compare its status with the wallet's activity record. A confirmed transaction has a ledger result, while an unconfirmed signature can expire without appearing on-chain. RPC endpoints sometimes disagree briefly about visibility, so use the signature itself rather than a spinning interface banner. Before retrying, refresh the Raydium app once and confirm that the first swap did not settle.

If the signature is absent after the original window, rebuild from a new quote and approve one fresh message for a new 150-slot window.

Priority fees change scheduling, not swap price

The Raydium priority fee raises a swap's scheduling bid on Solana, but it does not alter pool reserves or the quoted rate. Solana charges a 5,000-lamport base fee for each signature; 50% is burned, and 50% goes to the validator. One SOL contains 1,000,000,000 lamports. A priority bid remains separate from Raydium's pool charge, price impact, and slippage. The pool-side cost stays visible in the quote, such as the 0.25% AMM v4 fee.

How is the Solana priority fee calculated?

The Solana priority fee equals the requested compute-unit limit multiplied by the compute-unit price, divided by 1,000,000, and rounded up to lamports. The price uses micro-lamports per compute unit, so 1,000,000 micro-lamports equal one lamport. Requested budget, rather than consumed compute, controls the charge.

Worked example: this calculation uses three hypothetical changing inputs: one signature, a 300,000-CU limit, and a price of 10,000 micro-lamports per CU. Multiplication gives 3,000,000,000 micro-lamports; division by 1,000,000 produces a 3,000-lamport priority fee. Adding the fixed 5,000-lamport base fee gives 8,000 lamports, or 0.000008 SOL, for the network charge. The Raydium pool fee, token transfer fees, and any associated-token-account funding sit outside this total. No live SOL price enters this arithmetic, so the result stays denominated in SOL. Here, the priority portion represents 37.5% of the 8,000-lamport total. The concrete network cost for this signed transaction is therefore 8,000 lamports.

Compute units impose a separate ceiling. Without explicit Compute Budget Program instructions, Solana assigns 200,000 compute units to each non-built-in instruction and 3,000 to an eligible built-in instruction. A transaction accepts one SetComputeUnitLimit and one SetComputeUnitPrice instruction; duplicates of either type fail validation. Raydium normally builds these instructions into the prepared swap, so the user adjusts the scheduling bid without editing token amounts. Solana caps the effective transaction limit at 1,400,000 compute units.

Choosing a fee after a timeout

A replacement Raydium swap needs a fee bid derived from recent contention on the route's writable pool accounts, not the expired transaction's bid.

Solana uses local fee markets, so activity around one popular CLMM or CPMM state account matters more than an unrelated network average. The Raydium app's automatic setting reads recent conditions and packages Compute Budget Program instructions with the swap. After a timeout, refresh the route first, then move to a higher displayed priority level only if the same pool remains busy. Helius, Triton, and QuickNode expose account-aware estimates for custom integrations, while Jito serves a separate tip-based path used by specialized transaction senders. None of those services changes the blockhash lifetime.

If congestion outlives the first attempt, build again rather than piling retries onto the same 150-slot blockhash window.

Rebuilding the swap from fresh state

A valid retry starts with a fresh Raydium quote, a fresh recent blockhash, and a new wallet signature over the rebuilt message. A related page goes further into Using Raydium.

Refresh the token pair and input amount before selecting the route again. Raydium selects AMM v4, CPMM, CLMM, or several hops from current liquidity, so compare the new expected output and minimum output with the expired attempt. Keep slippage at the amount you are prepared to accept; raising priority and widening slippage address different conditions. The new message may create an associated token account for the output mint. That instruction requires SOL funding and consumes compute, whether the mint follows SPL Token or Token-2022. A route that wraps native SOL adds wrap and close-account instructions to the same atomic transaction.

Approve only after the wallet displays the intended input asset, output asset, and maximum spend. Phantom, Solflare, and Backpack all approve Solana transactions, although their activity screens use different labels for a signed transaction that has not landed. Keep the approval moving because the validity countdown continues while the wallet screen remains open. If the quote refreshes during review, return to Raydium and compare the replacement minimum output before signing.

Once signed, submit the rebuilt transaction and track its new signature rather than the old identifier. Solana executes transactions atomically: every instruction succeeds, or all state changes roll back. Each signer contributes a 64-byte Ed25519 signature, and a packet carries at most 12 signatures. The execution trace admits at most 64 instructions, including top-level instructions and cross-program invocations. Address Lookup Tables compress referenced account addresses in versioned transactions, but they do not extend Solana's 1,232-byte transaction cap.

Failures that resemble a low priority bid

Raydium swap failures that resemble low priority include exhausted compute, exceeded slippage, insufficient SOL, and stale CLMM account data. A low compute-unit limit stops execution even with an expensive bid, because priority price and compute capacity are independent. Token-2022 transfer-fee extensions also change the net token amount without changing validator fees. Refreshing the route resolves stale state; adding SOL covers base fees and new associated token accounts. Jupiter, Orca, or Meteora quotes reveal whether the issue follows one venue, while Solscan shows the landed program error.

Raydium app: common questions