Raydium swaps move from quote review through wallet approval to confirmed output.
A Raydium swap progresses from a reversible quote to a signed transaction and confirmed output. Review the input, output, route, fees, and minimum received before approval. The transaction record and resulting balance changes then show what the swap actually delivered.
Wallet approval authorizes the swap request, while the transaction record shows whether it produced the expected balance change.
From quote inputs to recorded output
A Raydium swap moves through three distinct states: a quote that can still change, a transaction that the wallet may approve, and an on-chain result. Keeping those states separate prevents an estimate from being mistaken for settled output. It also shows where you can stop, revise the request, or verify completion.
Quote state
The quote starts with an input token, an output token, and an amount. Raydium evaluates eligible liquidity pools and displays an expected output for a selected route. That output reflects the pool state available when the quote was calculated. Changing the amount, token, tolerance, or route creates a different proposal without moving any funds.
Wallet approval
Wallet approval is the first consequential action. In the usual interface flow, approval signs the prepared transaction and allows its submission to Solana. The prompt should describe a specific transaction rather than request a seed phrase or private key. Rejecting the prompt leaves the quote unexecuted and lets you revise any unacceptable term.
Confirmed output
A confirmed swap has an execution record and corresponding token balance changes. The input balance decreases, the output balance increases, and SOL covers the network fee when the connected wallet is the fee payer. The settled output may differ from the earlier estimate. For a Token-2022 output mint, the encoded minimum applies to the pool’s gross output before the token program deducts the transfer fee from the wallet’s net credit.
The transaction record as a verification point
A transaction signature identifies the signed request. After submission, its status can show confirmation or failure, but an absent record may mean the request is still pending, expired, or never landed. Interface notifications are convenient, yet the execution record is the stronger confirmation because it shows the signer, invoked programs, fee, and token balance changes together.
Successful status alone does not explain whether the received asset was the intended one. Reconciliation also compares the output mint, the amount credited, and the wallet account that received it. If a wallet interface has not refreshed or hides an unfamiliar token account, the on-chain balance change can still show whether settlement occurred.
Where does a route come from?
A route comes from comparing the output available through eligible Raydium pools for the requested tokens and amount. It may use one pool, pass through several pools, or divide flow across more than one pool. The selected route matters because every hop has its own liquidity state, pricing curve, and configured fee.
Quotes are snapshots rather than reservations. Another trade can alter pool reserves or move the active price before the transaction lands. A route that looked favorable can therefore become invalid or produce less output within the permitted range. Requesting a fresh quote before approval keeps the decision reversible and shows the current route.
The commitment boundary
The commitment boundary is the wallet action that authorizes submission. Before that point, token choices, the amount, slippage tolerance, and priority fee remain editable. Connecting a wallet or reading a quote does not authorize a token transfer. You can abandon the request without creating an on-chain swap.
After submission, editing the displayed form cannot alter the signed transaction. The network either processes that prepared request or does not. A successful transaction applies its instructions as one atomic unit, so a failed route check does not leave one hop settled while another hop remains incomplete. A processed failure can still consume a network fee.
What protects the expected output?
Slippage tolerance creates a minimum acceptable pool output. For an exact-input swap, Raydium derives this bound from the expected gross pool output before any Token-2022 output transfer fee:
minimum output = expected gross pool output × (1 - slippage tolerance). A wider tolerance permits a larger difference between the estimate and execution, while a narrower tolerance increases the chance that ordinary price movement causes a failure.
For an exact-input Raydium swap, execution fails if the pool’s gross output falls below the encoded minimum output. This limit protects a boundary, not a particular exchange rate. It does not stop the quote from changing before approval, and it does not remove pool fees, transfer fees, price impact, or Solana transaction fees.
Four values to review before approval
Four displayed values connect the quote to execution. Their exact amounts depend on the selected tokens, route, pool state, and network conditions. Together, they show the proposed spend, estimated proceeds, output floor, and priority fee.
| Parameter | How its value is set | Execution boundary |
|---|---|---|
| Input amount | Entered directly or derived for an exact-output request | Cannot exceed the authorized spend and available balance |
| Quoted output | Calculated from the selected route and observed pool state | Remains an estimate until the transaction executes |
| Minimum output | Derived from the quote and selected slippage tolerance | Gross pool output before any Token-2022 output transfer fee must meet or exceed this amount |
| Priority fee | Selected by the user or sized automatically in SOL | Changes scheduling priority, not the quoted token output |
| Commitment test | All four values describe the intended transaction | Approve only when the output limit and fee are acceptable |
The quoted output and minimum output serve different purposes. The quote is the estimate used to judge the route. The minimum is the enforceable floor for pool output before any Token-2022 output transfer fee. The priority fee addresses transaction scheduling during congestion, so raising it may help a transaction land sooner without improving the pool price.
Costs that reach the final balance
The final token amount reflects the route’s pool fees and price impact. Each pool on the route charges its configured trading fee, and price impact comes from moving along that pool’s pricing curve. Price impact is an execution effect rather than a separate fee. A route with more than one hop applies the relevant pool mechanics at each stage before producing the final output.
Solana also charges a transaction fee in SOL. An optional priority component can increase scheduling priority during congestion. Some Token-2022 mints impose a transfer fee under their token configuration, and a supported quote can account for that deduction in the net received amount. These costs have different recipients and should not be combined into a single unexplained percentage.
Pool designs behind a route
Raydium is a decentralized exchange and liquidity protocol whose spot swaps draw from several pool designs. The route can use those designs without requiring you to select a pricing formula manually. Their differences still explain why two pools for the same token pair may return different quotes.
Constant-product pools
CPMM and AMM v4 pools use constant-product pricing based on the relationship
x × y = k. A trade changes the two reserves and moves the implied price along the curve. Available depth, the requested amount, and the pool’s configured fee determine the quoted output. AMM v4 remains relevant for existing liquidity, while CPMM is the newer constant-product design.
Concentrated liquidity
CLMM pools place liquidity within chosen price ranges. Only liquidity active around the current price supports the next part of a swap. This can produce efficient quotes where liquidity is dense, but output can change as a trade crosses ranges. The route therefore depends on the active liquidity encountered during execution, not only the pool’s total deposited value.
Routes across several pools
A multi-hop route sends the output from one pool into the next pool as its input. A split route divides the requested flow across pools and combines the resulting output. Each branch or hop contributes its own fee and price movement. Each swap instruction enforces its configured output bound, and the transaction applies the complete route atomically.
How do you confirm what actually happened?
Confirmation comes from matching the transaction status with the recorded balance changes. A success message without the correct output mint or credited amount is incomplete evidence. The transaction signature provides the common identifier for checking both execution and settlement.
Status and signer
The transaction record should show success and identify the expected wallet as a signer. It should also show the swap and token programs that executed the instructions. An error status means the exchange action did not settle, even if the wallet created a signature or the interface briefly displayed a submitted state.
Token balance changes
Token balance changes show the economic outcome. Compare the input debit with the output credit, then account separately for the SOL network fee. The credited mint address matters because token names and symbols are not unique identifiers. If the wallet display lags, refresh it and compare its accounts with the confirmed record before attempting another swap.
Failures, retries, and final reconciliation
Failures fall on different sides of the commitment boundary. Rejecting a wallet prompt creates no submitted swap. An expired or dropped submission may leave token balances unchanged. A transaction that reaches execution and fails a slippage or account-state check also leaves the token exchange unsettled, although Solana can still charge the network fee for processing the attempt.
A clean retry begins with a fresh quote. Recheck the input, output mint, route, minimum received, and fee before signing again. Raising slippage changes the acceptable output boundary, while raising the priority fee changes scheduling pressure; they solve different problems. Once status, mint identity, and balance changes agree, the confirmed output becomes the starting balance for the next decision.
Common questions about Raydium
Do I need SOL when neither side of the swap is SOL?
For the standard wallet-paid flow, yes. Every Solana transaction needs a fee payer, and the connected wallet normally pays that network fee in SOL. The input token cannot substitute for SOL merely because it has enough market value. Keep enough SOL for the base transaction fee and any selected priority fee. The required amount depends on the prepared transaction and current network conditions rather than the value of the tokens being exchanged.
When should I refresh a quote before signing?
Refresh the quote whenever its underlying conditions may have changed. A delay, edited amount, changed token, updated slippage setting, or different route can make the earlier estimate unsuitable. Pool state also moves as other swaps execute. A new quote restores an accurate comparison before the commitment point. If the refreshed minimum output or fees are no longer acceptable, reject the wallet prompt instead of signing the older request.
Why can a token balance look unchanged after a successful swap?
A wallet interface may need time to refresh or may hide the output token account. Start with the confirmed transaction record and inspect its token balance changes. If the intended output mint received a credit, refresh the wallet, search for the token account, or enable its display. Do not submit the same swap again solely because the portfolio view is stale; reconcile the on-chain record first to avoid creating an unintended second exchange.
Which address identifies the token I intend to receive?
The mint address identifies a Solana token more reliably than its name or ticker. Different tokens can use the same visible label, so matching only the symbol does not establish identity. Compare the selected output mint with the mint credited in the confirmed transaction. This check belongs before approval and after execution: first to prevent selecting an imitation asset, then to prove that reconciliation used the intended token rather than a similarly named one.
Could a failed Raydium swap still charge a network fee?
Yes, a transaction that reaches Solana and fails during execution can still incur its network fee. The network fee covers signature verification and, when a priority fee is selected, scheduling priority rather than successful token output. The failed swap’s token exchange should not partially settle because the transaction is atomic. Distinguish that case from rejecting an unsigned prompt or a request that was never processed, since those situations do not create the same on-chain execution record.
Are Token-2022 transfer fees included in the quoted output?
For a supported Raydium route, the quoted output represents the estimated net amount received after a Token-2022 transfer fee. The displayed costs may separate the pool fee from the fee imposed by the token mint. Compatibility still depends on the pool design and the token’s enabled extensions, so the route itself remains relevant. Recheck the output mint, estimated net amount, and minimum output before signing rather than estimating the transfer fee manually. For an output mint with a transfer fee, the slippage minimum applies to the pool’s gross output before that fee, not to the wallet’s net credit.