Raydium
Raydium Makes One Swap Verifiable From Quote to Resulting Balance
A bounded Raydium swap is complete only when the selected input and output are correct, the live quote still meets its execution limit, the connected wallet approves the intended transaction, and Solana records a successful transaction and the resulting token balance. Treat each stage as a pass-fail decision. Stop before signing if the token mint, available balance, route, expected output, slippage bound, or wallet preview does not match the intended exchange.
In short: A swap is complete only when the transaction succeeds and the resulting token balance matches the recorded execution.
Liquidity and token behavior set the quote
One live quote combines the selected amount with available pool liquidity, pool fees, route structure, price impact, and any transfer rules attached to the tokens. Raydium may produce a direct route, a multi-hop route, or a route split across eligible pools. The expected output is an estimate from current pool state, not a reservation that remains fixed while the transaction waits.
An exact-input quote fixes the amount being spent and calculates the expected output. An exact-output quote fixes the amount to receive and calculates the required input. The selected mode determines whether the execution bound protects a minimum output or a maximum input.
A quote passes when the token roles, amount mode, route, fees, and execution limit all match the intended exchange. Changing the slippage setting cannot correct a wrong mint address, a missing balance, or inadequate liquidity.
What must be ready before the quote?
Token identity, spendable balances, and a compatible wallet must be verified before the displayed output becomes useful.
Token identity
A mint address distinguishes the intended token from another asset using the same name or symbol. Compare both the input and output mints before entering an amount. A familiar icon or ticker does not establish that the selected mint is correct.
Spendable balances
The source token account must hold enough of the selected input. The wallet also needs SOL for the transaction fee, any chosen priority fee, and the possible creation of an associated token account for an output mint that the wallet has not received before. A quote can appear even when one of those prerequisites is missing, so quote availability alone is not a readiness check.
Wallet readiness
The connected wallet must support the transaction format that the swap uses and sign for the address holding the input. Its preview should expose the requested token movements and network charges. Connecting a wallet or approving a swap does not require entering a seed phrase or exporting a private key into the exchange page.
From token selection to recorded balance
Each stage compares the visible state with the intended exchange. The attempt advances only when the evidence in that row passes; a missing prerequisite surfaces before the wallet authorizes a transaction.
| Stage | Observable pass evidence | Timing or stop condition |
|---|---|---|
| Select input and output | Both mint addresses and the exchange direction match the intended tokens. | Before requesting a quote; stop if either identity or direction differs. |
| Confirm prerequisites | The connected wallet has the input balance and enough SOL for network charges and any needed token account. | Before relying on the quote; stop until every required balance is available. |
| Read the live quote | The amount mode, expected output or required input, route, fees, and price impact are visible. | While the quote reflects current pool state; refresh it if material fields change. |
| Set slippage and priority fee | The minimum output or maximum input and the selected priority fee are clear. | Before approval; stop if the worst permitted exchange or network charge is unacceptable. |
| Review authorization | The wallet preview names the expected signing account and token movements. | At the wallet prompt; reject an unexplained transfer, account, or instruction. |
| Sign and submit | A transaction signature identifies the signed attempt. | After approval; do not submit a replacement while the first status is unresolved. |
| Reconcile the outcome | The record shows success, the input balance decreased, and the output balance increased. | After status resolution; exit only when the record and balances agree. |
The pass condition is the recorded state transition, not the quote or a success animation. A failed or unresolved record does not establish that the output reached the wallet.
A wallet approval defines the authorization boundary
Wallet approval is the last reversible decision before submission. A Solana signature authorizes a specific transaction message containing its instructions and account references. Review the signing address, token direction, amount bounds, and network charges while rejection is still possible.
A request for a seed phrase or private key falls outside that boundary. Those secrets control the wallet itself, while a swap needs only the wallet's signature for the prepared transaction. Close any page or prompt that asks for the secret instead of requesting a transaction signature inside the wallet.
Submission is not proof of execution. Save the transaction signature when it appears because it separates this attempt from a later retry and provides an independent lookup key.
How do transaction checks distinguish pending, failed, and successful swaps?
A transaction signature and its recorded status distinguish an unresolved submission, an execution error, and a successful swap with a stale wallet display. A transaction signature identifies the signed transaction, while a returned status shows whether Solana processed it successfully or recorded an error.
No visible signature
A rejected wallet request normally ends before submission, but an interface can also lose track of an attempt after sending it. Check the wallet activity before approving another transaction. The absence of a confirmation banner is not enough to prove that nothing was submitted.
A signature without success
A pending status remains unresolved. An execution error means the swap state changes did not complete, although an included failed transaction can still incur a network fee. An expired attempt also needs a new quote and a newly built transaction rather than repeated approval of stale terms.
A successful record with a stale display
A successful record and matching token balance changes pass the check even when the wallet interface has not refreshed. Inspect the output mint and its post-transaction balance, then refresh or reveal the token account. If the recorded change is unexpected, examine the mint and token transfer rules before considering another swap.
Similar quotes can follow different execution paths
Route structure changes what must remain valid between quoting and execution. Compare routes by final bounded output, included fees, and observable completion rather than hop count alone.
Direct pool execution
A direct route exchanges the input through one pool. Its displayed price impact and pool fee belong to that pool, but fewer hops do not automatically make it the better quote. The relevant pass condition is whether the direct route provides acceptable bounded output for the selected amount.
Multi-hop and split execution
A multi-hop route passes one pool's output into the next pool, so each hop contributes its own liquidity conditions and fee. A split route distributes the input across more than one pool. The composed transaction must complete atomically; if an enforced slippage bound fails, the route does not leave a partially completed exchange.
Token transfer behavior
A Token-2022 mint can apply a transfer fee outside the pool's own trading fee. In that case, gross pool output and the amount credited to the wallet may differ. Compatibility also depends on the pool program and the mint's enabled extensions, so support for one token does not establish support for another token with a similar label.
Stop conditions before and after submission
Before signing, reject the transaction when the mint, direction, amount limit, route, fee information, or wallet preview is wrong or incomplete. Refreshing a quote is appropriate when market state changed. It is not a remedy for an unknown token or an unexplained authorization request.
After submission, wait for the attempt's status before rebuilding it. A failed or expired transaction returns the task to quote review. A successful record with the expected input decrease and output increase ends the swap. Close the task at that point instead of repeating it because one interface still shows an old balance.
Before you start with Raydium
Can I cancel a Raydium swap after signing it?
Signing and submission are distinct, even when the interface presents them in one flow. Once the signed swap has been sent to Solana, it cannot be canceled from the wallet. It may still fail or expire before execution, but neither outcome should be assumed. Check the original transaction signature first. Approving a newly built replacement while the first attempt remains unresolved can create a second valid swap if both transactions execute.
When should I request a fresh quote instead of widening slippage?
Request a fresh quote when the route has changed, the displayed output is stale, the transaction expired, or pool conditions moved before signing. Wider slippage only changes the execution boundary. It does not correct a wrong mint, missing token account, insufficient balance, unavailable route, or price impact that already exceeds the amount you are prepared to accept.
Why can a failed Raydium swap still consume SOL?
A swap that reaches Solana and fails during execution can still incur a transaction fee because validators processed the signed transaction. The token exchange remains unsuccessful, so the expected output should not be treated as received. A request that fails locally before submission is different: without an included on-chain transaction, there is no processed transaction fee to reconcile.
Does a priority fee change the token amount in the quote?
A priority fee pays for transaction processing priority and does not improve the pool's exchange price. A higher setting may help a transaction reach execution sooner during congestion, which can reduce the chance of its quote becoming stale. The swap still has to satisfy its slippage boundary, and the priority fee is paid separately in SOL.
Which record should I retain after completing one swap?
Keep the transaction signature that identifies the completed attempt. The corresponding record should show a successful status, the signing wallet, the input and output mints, and the token balance changes. This evidence distinguishes the completed swap from later quotes or retries and remains useful when a wallet interface displays a cached balance.
What happens if the output token needs a new account?
The transaction can include creation of an associated token account for the output mint when the wallet does not already have one. The fee payer needs enough SOL for that account's rent-exempt allocation as well as transaction charges. If the account cannot be created, the swap cannot complete and the expected output balance will not appear.