Raydium

Raydium swaps can fail during quoting, wallet authorization or Solana execution.

A Raydium swap exchanges an input token for an output token through one pool or a routed set of pools in a Solana transaction. It can fail when a live quote no longer matches pool state, the minimum output cannot be met, a token program is incompatible or the transaction cannot land. Diagnose the visible state before trying again: an unsigned proposal was not authorized; a confirmed transaction record with an error means execution failed; a confirmed record with no error and matching balance changes means the swap executed even if a wallet display is stale. Compare the quoted output and slippage boundary first, then inspect route liquidity, transaction status and token-account deltas. This order separates a pricing failure from a submission problem and prevents an uncertain first attempt from becoming an unintended second trade.

Wed, Sep 16, 2026 - updated

Failure Signals Before Submission

Pre-submission signals include a missing quote and a quote that changes while pool or route state updates.

A missing quote can mean that no supported pool path connects the selected input and output mints. It can also reflect stale pool data, unavailable route accounts or an unsupported token-program feature. A quote that returns far less output than expected for the selected pair and amount points elsewhere: the trade may be too large for active liquidity at the quoted price. These states need different responses, so changing every setting at once hides the useful evidence.

A quote that repeatedly changes is not proof of failure; it reflects changing pool state or route selection.

Mint addresses establish token identity when symbols are duplicated or misleading. Confirm the input mint, output mint, amount direction and token program before evaluating the price. Then read the expected output, minimum output and price impact together. An output amount can look plausible while the minimum is already below what the reader intends to accept. Reversing the input and output roles also changes the quote rather than correcting it.

Without compatible support for both mints, changing slippage cannot create a valid route.

How Does Minimum Output Stop a Stale Trade?

For an exact-input swap, slippage tolerance converts the quoted output into the lowest output the transaction may accept. The relationship is minimum output = quoted output × (1 - slippage tolerance). If execution would return less than that floor, the swap fails instead of accepting the worse amount. Raising the tolerance lowers the floor. It does not add liquidity, improve the pool price or repair an incompatible route.

Quoted output remains a live variable because pool reserves, active concentrated-liquidity ranges and routed hops can change before execution. After an exceeded-slippage error, obtain a fresh quote and compare the new expected output with its new minimum. A smaller input may reduce price impact in a shallow pool. Another route helps only when it has usable liquidity and supports the selected mints. A large tolerance increase is a deliberate expansion of the worst acceptable outcome, not a generic retry switch.

Liquidity, Price Impact and Route Drift

Liquidity and route state determine whether the quoted exchange can still execute. Raydium may quote one pool, several sequential pools or a split across pools. Each added pool contributes its own live state and pool fee. A trade that is large relative to active liquidity moves farther along the pricing curve and usually receives a worse marginal rate. If any instruction in the routed swap fails, the atomic transaction does not settle a partial exchange. Refreshing can produce a different route, so compare its output and minimum rather than assuming it recreates the first proposal.

Wallet Authorization, Fees and Expiration

A wallet signature authorizes the transaction message for that signer; it does not prove that Solana accepted or completed the transaction.

The signing view should preserve the intended input and output mints, spending direction and fee payer. Rejecting the request ends that proposal before submission. The transaction’s fee payer needs enough SOL for the network fee. If the transaction also creates an associated token account for the output mint, the payer named in that instruction must provide the account’s rent-exempt funding. Priority fees can improve scheduling during congestion, but they do not change pool liquidity or the quoted exchange rate.

A signed transaction can still expire if its recent blockhash leaves the valid processing window before it lands. Build a new transaction from a current quote rather than modifying or resending stale assumptions. First resolve the old signature’s status. If its state remains uncertain, creating a separately signed swap can expose the same input to two valid transactions.

What Does the Transaction Record Prove?

The transaction record proves whether Solana executed the signed message and whether execution returned an error. A signature by itself proves only that the message was signed. Solana transaction metadata includes pre- and post-transaction token balances for indexed token accounts. A confirmed transaction record with no error establishes execution; the balance entries show what changed for each recorded mint and owner.

Reconciliation should match the signer, fee payer, input mint and output mint before comparing amounts. The input token balance should reflect the debit and the output account should reflect the credit. A separate SOL decrease can represent the transaction fee and, when included, token-account funding. Token-2022 transfer-fee mints can make the credited amount differ from a gross token transfer, so the change between the pre- and post-transaction balances is the useful observed amount. A wallet interface that hides the token does not override that on-chain balance.

View full-size image

Transaction States and the Next Valid Action

A wallet attempt can stop at four materially different states. The next valid action depends on the strongest evidence already available.

Balance Reconciliation and Retry Boundaries

Balance reconciliation compares the expected exchange with recorded account changes. Record the transaction signature when one exists, then match its status, error field, signer and mint-specific balance changes. Check the output account itself when a wallet portfolio view remains unchanged. A confirmed output credit means the asset arrived even when the interface has not surfaced it.

A retry is valid only after the previous attempt has a conclusive state. An unsigned request can be replaced because it never reached the network. A confirmed error permits a new quote after its cause is addressed. An unknown or pending signature requires more status checking or expiry before a separately signed trade is created. A successful transaction should not be retried; any remaining issue is reconciliation or display.

Before closing the investigation, match the intended mint identities, accepted minimum, recorded status and actual token deltas. For a transfer-fee mint, compare the output account’s pre- and post-transaction balances to identify its net credit.

Raydium swaps: the short answers