Exchange is raydium's Requoting and Wallet Reapproval Workflow

Exchange is raydium's quote-to-settlement workflow on Solana, where a swap is priced from current pool state, converted into a transaction, approved by the wallet, and checked after confirmation. A quote is not a reservation. When its route, minimum output, or recent blockhash becomes stale, Raydium must calculate fresh values, and the wallet must approve the newly built transaction because the original signature covers a different message. This page follows that operational slice: choosing between signing and requoting, understanding exact-input and exact-output quotes, reading transaction states, checking token-balance changes, and recovering from price-limit, account, or expiry failures without confusing a submitted swap with a settled one.

Key takeaway: It is raydium's Solana swap workflow for routing trades, where stale quotes trigger requoting, wallet reapproval, and output checks.

The Sign-Or-Requote Decision Starts With the Quote

The Raydium sign-or-requote decision depends on whether the displayed quote still matches the transaction that the wallet is about to authorize.

Raydium's Trade API separates calculation from construction. The compute step returns the route plan, input amount, expected output, price impact, and slippage threshold. The build step combines that response with the wallet address, transaction format, token accounts, and compute-unit price. A quote older than about 30 seconds is rejected by the Trade API, while the on-chain transaction has its own blockhash lifetime. Those are two clocks: quote freshness protects route assumptions, and blockhash freshness controls whether Solana accepts the message. If either clock runs out, choose requoting before supplying another signature.

Wallet Approval Binds to a Newly Built Transaction

Wallet reapproval is required because every refreshed Raydium swap produces a new Solana transaction message, even when the visible token pair remains unchanged.

What the Wallet Actually Approves

Phantom, Solflare, and other Solana wallets sign a serialized message, not a reusable instruction to trade whenever conditions change. The message fixes the account keys, recent blockhash, compiled instructions, and signer requirements. Solana public keys are 32 bytes, and each Ed25519 signature is 64 bytes before base-58 encoding for display.

The Message

Raydium places pool accounts, source and destination token accounts, Compute Budget Program settings, and swap limits inside that message. Versioned v0 transactions may reference Address Lookup Tables to compress account addresses. Address Lookup Tables store account keys outside the message and let v0 instructions reference them by compact indexes. A transaction packet remains capped at 1232 bytes, while execution allows up to 1,400,000 compute units.

The Signature

Changing one byte changes the signed message, so a signature for the earlier quote does not authorize the replacement. Solana also charges a base fee of 5000 lamports for each required signature. Priority fees sit on top and use a separate compute-unit calculation.

Why a New Quote Demands a New Signature

Requoting changes output thresholds, route accounts, or both. A new recent blockhash may also be inserted when the transaction is rebuilt. The wallet therefore presents another approval request. This is transaction-level authorization; a typical Raydium swap does not rely on an Ethereum-style ERC-20 allowance that stays open across trades.

Quote Inputs Control the Route Before Signing

A Raydium quote starts with two mint addresses, an amount mode, the amount in base units, slippage basis points, and a transaction version.

Exact-input mode fixes what leaves the source account and calculates expected output plus a minimum acceptable output. Exact-output mode fixes the desired receipt and calculates required input plus a maximum acceptable input. One basis point equals 0.01%, and the API represents the full percentage range as 0 through 10,000 basis points. Token precision matters before routing: USDC on Solana uses 6 decimals, while native SOL uses 9. One USDC therefore equals 1,000,000 base units, and one SOL equals 1,000,000,000 lamports. Within this Exchange workflow, changing any mint, amount, mode, tolerance, or transaction version requires a fresh calculation.

Pool Selection Turns Market State Into an Output

The Raydium route selector compares eligible CPMM, CLMM, AMM v4, and stable-pool paths by the net output produced from current state.

A single-pool route contains 1 swap hop. A multi-hop route contains 2 or more, with an intermediate mint connecting pools; a split route divides input across parallel paths. CPMM and AMM v4 apply constant-product mechanics, while CLMM reads concentrated liquidity across initialized ticks. Each pool contributes its configured fee and curve result. Token-2022 adds mint-level extensions, including transfer fees when the mint enables that feature.

Routing output moves with reserves, active CLMM liquidity, fee configuration, transfer-fee settings, and trade size. Raydium selects accounts and instructions for the chosen path, then places the final minimum output or maximum input in the transaction. If updated pool state favors another path, the rebuilt message names different accounts. That account change is enough to require wallet reapproval, even when the displayed estimate barely moves.

Stale Quotes Fail at Price Limits or Blockhash Expiry

A stale Raydium quote fails during construction, simulation, slippage enforcement, or Solana blockhash validation rather than settling at the abandoned terms.

Worked example: the changing inputs are hypothetical - a quoted output of 1.500000 SOL and a selected tolerance of 50 basis points. Fifty basis points equals 0.50%, so the exact-input minimum is 1.500000 × (1 − 0.005), or 1.492500 SOL. If pool calculation returns 1.492499 SOL, the route fails atomically; at 1.492500 SOL or more, the limit passes. The concrete threshold for this quoted case is 1.492500 SOL.

Solana accepts a recent blockhash for 151 queue entries because the maximum processing age is 150 and counting begins at age zero. Slots target 400 milliseconds and commonly range from 400 to 600 milliseconds, placing wall-clock expiry around 60 to 90 seconds. Quote expiry and blockhash expiry remain separate. Once either limit has passed, rebuilding from fresh pool state and signing the new message is the valid recovery.

Transaction States Separate Submission From Settlement

A Raydium swap moves through local approval, RPC submission, processed, confirmed, and finalized states, and each state answers a different operational question.

Before submission, the wallet prompt exists only on the user's device. After signing, the client sends serialized bytes to a Solana RPC node and receives a base-58 transaction signature. That identifier proves submission only when an RPC node returns it; it does not by itself prove execution. Solana exposes 3 standard commitment levels for reading later status.

Submitted and Processed

A submitted transaction has reached an RPC service. Processed means a validator included it in its current chain view, which provides the earliest on-chain status. The status also contains an error field. A nonempty error means the transaction landed but its instructions did not complete, and the fee still applies. An empty error moves the check toward confirmation (more on this in Main page ).

Confirmed and Finalized

Confirmed means a supermajority of stake has voted on the block, while finalized means the block reached the strongest standard commitment. Raydium may update its interface before a wallet refreshes every token account, so interface timing is not the settlement test. Read the signature status first, then inspect transaction metadata. That sequence distinguishes an expired submission from a successful swap whose balance display lags.

Output Checks Close the Swap Loop

A completed Exchange transaction is verified by its status, program result, token-account deltas, and destination mint rather than by the quote screen alone.

Solana transaction metadata exposes pre-token and post-token balances with account indexes, mint addresses, owners, decimals, and raw amounts. The input token account should decrease by the executed spend, while the destination account should increase by the net receipt. For native SOL, also account for the 5000-lamport base fee per signature, any priority fee, and wrapping or unwrapping instructions. Raydium, Solana Explorer, and Solscan may format those changes differently, but the underlying account deltas agree once they query the same confirmed transaction.

A success status with no visible wallet balance points to display or account selection, not an incomplete swap. Check the destination mint and owner, then look for a newly created Associated Token Account or a hidden token entry in Phantom or Solflare. A failed status leaves swap instructions without committed balance changes, although the network fee remains charged. The next decision follows the on-chain metadata: refresh the view after success, or rebuild after failure.

Priority Fees Affect Inclusion, Not the Quote

A Raydium priority fee changes scheduling probability, not the pool quote, slippage threshold, or number of output tokens defined by the route. Solana calculates the optional charge as the ceiling of compute-unit price multiplied by compute-unit limit, divided by 1,000,000 micro-lamports per lamport. The default allowance is 200,000 compute units per non-builtin instruction, subject to the 1,400,000-unit transaction cap. Raise the bid after expiry only when delayed inclusion caused the missed window, then obtain a fresh quote and signature.

Token Accounts Add Setup and Balance Edge Cases

Raydium output arrives in a token account for the selected mint, so account creation and wrapped SOL handling alter the transaction shape.

The Associated Token Account Program derives an address from 3 inputs: the wallet owner, token-program identifier, and mint. If that account does not exist, setup adds its creation instruction and a rent-exempt SOL deposit. A classic SPL Token mint account stores 82 bytes, and a classic token account stores 165 bytes. Token-2022 extensions increase account space, so the transaction must target the correct Token Program and account layout.

Native SOL uses the System Program, whereas Raydium pool instructions trade its wrapped form, WSOL. A swap involving SOL may create or fund a wrapped account, synchronize its 9-decimal balance, and close it during unwrapping. Those setup actions may enlarge the message or produce an additional transaction for signing. The output check must therefore follow the actual destination account and mint, especially after a requote changes the serialized setup.

Multi-Hop Routes Remain Atomic Across Pools

A Raydium multi-hop route passes each pool's output into the next pool inside 1 atomic Solana transaction, subject to the final limit. A 2-hop path uses one intermediate mint and invokes 2 pool swaps in order. The route may call CPMM first and CLMM second through Cross-Program Invocations, yet partial settlement does not persist when a later hop fails. Each hop reads live pool state, while the final instruction enforces the global minimum output or maximum input. Requote when any hop's accounts or limits change. A dedicated page sets it out in practice.

Recovery Rebuilds From Fresh State

Raydium recovery starts by locating the break before signature, during construction, during simulation, before inclusion, or during on-chain execution.

No wallet prompt after a compute response points to transaction construction, token-account selection, or wallet decoding. An open prompt that outlives the quote should be rejected so Raydium can compute a new route and build a new message. A signed transaction that never appears on-chain requires status checks until its last valid block height passes; after expiry, rebroadcasting the same bytes cannot restore validity. Start again with current pool accounts, a recent blockhash, and a newly reviewed signature.

An on-chain error narrows the next change. A slippage-limit error calls for a fresh quote, a smaller input, or a deliberately revised tolerance. An insufficient-balance result requires enough source tokens and SOL for fees or account setup. Account-data errors call for refreshed pool and token-account state. When status is successful but the wallet view remains unchanged, transaction metadata identifies the destination account and exact balance delta. Each branch returns to one decision: refresh the display after confirmed success, or rebuild from fresh state before approving again.