Raydium Raydium Swap Routing from Token Inputs to Final Balance Checks
Raydium uses the selected input and output mints and trade amount to calculate a live route, then packages that route for wallet approval. A complete swap check follows the same path: confirm token identities and spendable balances, inspect the quote and acceptance limit, sign the transaction, verify its status, and reconcile both token balances.
Updated
Key takeaway: A swap is complete only when the transaction status and token balance changes agree with the exchange that the wallet approved.
Single-pool, multi-hop, and split quotes
Quote construction starts with eligible pools for the selected token mints and specified amount. For an exact-input quote, the router compares projected outputs after pool fees and price impact; for an exact-output quote, it compares required inputs. The selected route can then be encoded into a Solana transaction.
Raydium routing supports single-pool, multi-hop, and split routes across eligible pools. Each participating pool supplies its own pricing calculation, so the router coordinates the path rather than imposing one curve on every hop.
Single-pool quotes
A single-pool quote exchanges the input directly for the output through one pool. Its shorter account and instruction set can simplify execution, but route length alone does not determine value. Available liquidity, the pool fee, and the input amount shape the quoted output.
Multi-hop quotes
A multi-hop quote passes the first pool's output into another pool as an intermediate input. Each hop applies its own curve and fee. The final protected output matters because a reduction at an early hop also reduces the amount available to later hops.
Split quotes
A split quote divides the input among eligible pools and recombines the branch outputs. This can improve aggregate execution when one pool cannot absorb the entire amount efficiently. The split remains one coordinated exchange when every branch is included in the same atomic transaction.
Which inputs make a route usable?
A route becomes usable only when the selected mint addresses, spendable input balance, fee balance, and token rules all fit the transaction that will be signed.
Mint identity
Mint addresses identify the input and output tokens. Symbols and names are display labels and can be duplicated, so they cannot establish token identity by themselves. Both addresses should remain consistent from selection through the wallet approval request.
Spendable funds
The spendable funds must cover the stated token input and the Solana transaction charges. SOL may also be needed when the transaction creates an associated token account for the output. A displayed portfolio total can include funds that the selected token account cannot spend.
Token-program conditions
Token-program conditions can affect whether a mint is routable and how much reaches a pool or recipient. Transfer fees, frozen accounts, and non-transferable extensions are operational constraints. A token appearing in a wallet does not prove that every pool type can exchange it.
Acceptance conditions before approval
An acceptance condition defines the worst exchange the signer is willing to authorize. With an exact-input quote, the input is fixed and a minimum output limits deterioration before execution. With an exact-output quote, the desired output is fixed and a maximum input limits how much the route may spend.
Slippage tolerance creates that boundary; it does not reserve the displayed pool price. Reserves can change between quoting and execution. A narrower tolerance rejects smaller adverse movements, while a wider tolerance permits a larger difference. Pool fees, token transfer fees, price impact, and Solana charges remain separate inputs to the decision.
When should the route be rejected?
The route should be rejected when its live terms no longer satisfy the acceptance condition set before approval. Assume the token identities and spendable balance are correct. Approve only a fresh route whose quoted exchange, charges, and protected amount fit the intended swap, then sign only the matching transaction.
Pool activity can lower the projected output while the chosen input stays unchanged. A refreshed quote that still clears the chosen floor remains eligible for approval. A quote below that floor invalidates the earlier decision. Raising slippage changes the protection itself, so it should not be treated as a mechanical retry.
- Match both mint addresses to the intended tokens.
- Confirm the input balance and required SOL are available.
- Read whether the route is direct, multi-hop, or split.
- Compare the protected amount with the acceptance condition.
- Decline approval if the transaction no longer matches the quote.
After submission, a successful transaction should produce token deltas that match the approved exchange. A failed or expired attempt needs a fresh quote and a new approval before another submission.
Wallet authorization and transaction contents
Wallet authorization applies to the instructions and accounts encoded in the presented transaction. The approval may include pool swaps, creation of a missing associated token account, compute-budget settings, and transfers between the user's token accounts and pool vaults. Signing does not make the earlier screen quote permanent.
The connected wallet should expose a transaction approval request, not a request to reveal a recovery phrase or private key. Those secrets control the wallet itself and are not inputs to a swap instruction. If the approval details differ materially from the selected tokens or amounts, decline the request and inspect a fresh transaction.
Pending, failed, and confirmed states
A pending state means the transaction has been submitted without a settled outcome at the chosen confirmation level. The quote screen is no longer sufficient evidence at that point. The transaction signature provides the durable reference for checking whether the network processed the instructions.
A failed state means the exchange instructions did not complete. Slippage bounds, changed pool state, insufficient funds, or an unsupported token condition can make execution fail. An expired transaction may never be processed. Because routed hops execute atomically within one transaction, a later failing hop does not leave successful earlier hops settled on-chain.
A confirmed success establishes that the transaction executed, although a wallet interface may refresh balances later. Confirmation alone also does not explain every amount. The token balance changes recorded for the transaction show what left the input account and what reached the output account.
How do transfer fees change the balance check?
Transfer fees change the balance check by separating the pool's gross output from the amount credited to the recipient's token account. The wallet-side increase can therefore be smaller than the amount that the pool sends.
A Token-2022 transfer-fee mint can deduct a fee when tokens enter or leave a supported pool. CPMM supports these mints, and CLMM handles them through its Token-2022 swap path; AMM v4 does not support Token-2022. For outbound transfer fees, the slippage check can use the gross pool output while the final wallet check must use the net credited amount.
Final balance reconciliation
Final reconciliation joins the transaction record with the input and output token deltas. A refreshed wallet display is useful, but the on-chain record resolves cached values, hidden token accounts, and changes spread across separate accounts.
Transaction record
The transaction record should show a successful status, the expected wallet signer, and the invoked swap instructions. A signature that cannot be found or remains unresolved does not establish completion, even if the interface previously displayed a submitted message.
Input-side delta
The input-side delta shows how much of the selected token left the source account. It should be evaluated separately from SOL used for network charges or account creation. This distinction prevents a change in the fee payer's SOL balance from being mistaken for the exchange amount.
Output-side delta
The output-side delta shows what reached the destination token account. Wallets may hide an unfamiliar account or delay portfolio totals, so the account-level change is stronger evidence than the visible asset list. Token-2022 transfer fees must be reflected in this net amount.
Verified completion
A completed swap should show a successful transaction and token changes that agree with the approved exchange. The input decrease and output increase need not mirror the headline quote exactly when pool execution, transfer fees, and separately charged Solana costs affect different accounts.
A failed transaction closes only that attempt. An unresolved signature calls for status checking rather than another blind submission, while an incorrect or missing balance delta calls for account-level inspection. Without both transaction and balance evidence, the swap remains unresolved.
Still wondering about Raydium?
Does a higher priority fee improve the quoted output?
No. A higher priority fee pays more for transaction processing and may improve the chance of timely inclusion during congestion. It does not change the pool curves or increase the amount in the route quote. Pool state may still move before execution, so the slippage boundary remains relevant.
Can one routed transaction combine CPMM and CLMM pools?
Yes. A multi-hop or split route can include eligible CPMM and CLMM pools when the transaction can include their required accounts and instructions. Each pool prices its own hop or branch under its curve and fee configuration, and the transaction must enforce the applicable output bounds.
Which token account receives the output when a wallet has several accounts for one mint?
The destination token account encoded in the signed transaction receives the output. A wallet may aggregate several accounts into one displayed balance, which can obscure the individual credit. The transaction's token balance metadata identifies the account whose balance changed.
Does a split route need separate approvals for each branch?
Not when all branches are packaged into one atomic transaction. The wallet approves that transaction once, and every included branch either completes with it or reverts with it. An external integration that deliberately builds several transactions would require approval for each separate transaction.
Can a failed swap still reduce the fee payer's SOL balance?
Yes. Solana can charge transaction and priority fees even when the swap instructions fail and the token exchange reverts. The fee payer's SOL change should therefore be checked separately from the input-token debit and output-token credit when reconciling an unsuccessful attempt.