Raydium
Raydium Swap Validation Before and After Signing
Raydium swaps should be approved only when the selected token mints, input and output amounts, route, price impact and the applicable minimum-output or maximum-input boundary match the intended exchange. After signing, the transaction signature identifies the submission but does not prove settlement. A successful status and the corresponding input debit and output credit show whether the swap reached the wallet’s on-chain balances.
- updated
The preview and the settled record answer different questions. The preview defines what may execute, while the record shows what did execute and where the tokens moved.
Exact-Input and Exact-Output Quote Modes
Exact-input mode fixes how much of the selected input token will be spent and calculates an expected output. It suits a trade with a firm spending amount. Exact-output mode starts with the desired output and calculates the required input. That distinction changes the execution boundary: exact-input mode sets a minimum output, while exact-output mode sets a maximum input.
A route may use one pool, several consecutive pools or a split across available liquidity. Route complexity does not remove the need to compare the selected mints and amounts. Pool fees affect the quoted output, while price impact describes how the trade itself moves through available liquidity. Neither figure replaces minimum received, which sets the execution boundary for an exact-input swap.
What Should Match Before a Wallet Signature?
The signing boundary should match the intended token identities, amount direction and spending authority. The wallet request authorizes transaction instructions rather than the screen’s descriptive labels. If the origin, account access or requested amount is unexpected, rejecting the request keeps that proposal from reaching the network.
Mint Identity and Amount Direction
Mint identity resolves ambiguity that a token symbol cannot. Different mints can display similar names, so the input and output addresses must represent the intended assets. Direction matters as well: reversing the two sides changes which token leaves the wallet and which token should appear afterward.
Input-Side Authorization
The input side defines the token account that supplies the trade and the amount placed at risk. For an exact-input quote, the requested spend should remain consistent with the reviewed amount. Any separate token approval or unfamiliar authority deserves inspection before the wallet releases a signature.
Output-Side Protection
The output side contains two different values. Expected output reflects the current quote, while an exact-input transaction carries a slippage bound. Without an output transfer fee, that bound is the lowest acceptable amount the wallet receives. With a Token-2022 output transfer fee, the bound applies to gross output and the wallet receives the net amount after the fee. Execution may fall below the estimate without violating the bound, but the transaction should fail below its enforced gross-output minimum.
Route Economics at the Commitment Boundary
Route review connects the quote to its liquidity path. Price impact belongs to the selected amount and available liquidity, while slippage tolerance covers adverse movement between quoting and execution. Pool charges, token transfer fees and network costs can affect different parts of the exchange. Reading them as one combined percentage can hide why the final balance differs from the headline estimate.
When Does a Quote Stop Being Reliable?
A quote remains reliable only while its pool state, route and transaction inputs stay usable. It is a snapshot, not a reserved price. For the exact-input example below, where neither mint charges a transfer fee, minimum received equals expected output × (1 - slippage tolerance). A refreshed quote can change that boundary as liquidity or fees change. A stale-route or slippage failure calls for a new quote, not repeated submission of the old transaction.
A Hypothetical Preflight and Settlement Match
This worked case uses hypothetical token roles, amounts, percentages, statuses and balance changes. Neither hypothetical mint charges a transfer fee. A reader starts with an exact-input swap and requires a route that supports both selected mints and their token programs.
The quote spends 17.42 input units, estimates 83.52 output units and applies a hypothetical 0.72% slippage tolerance. The resulting minimum is 82.918656 output units. If the application cannot build a compatible transaction for both mints, the process stops before the authorization boundary.
Once a transaction is available, the reader compares its accounts with the selected mint addresses and confirms the 17.42-unit input. The expected output remains an estimate, but the calculated minimum stays as the stop condition. The reader signs once after those details agree.
The resulting signature resolves to a successful record. The input balance falls by 17.42 units and the output balance rises by 83.31 units. The actual credit exceeds the minimum by 0.391344 units, so the balances and transaction status establish a valid end state. Any network fee is reconciled separately from the two token amounts.
How Do You Prove the Swap Actually Settled?
The transaction record proves settlement when it reports success, identifies the expected signer and shows the intended token balance changes. The signature alone does not provide that proof because failed and expired submissions can also have identifiers. The output increase must belong to the selected mint and the wallet’s token account.
Pre-transaction and post-transaction balances provide the clearest reconciliation. The input decrease should reflect the executed exchange, while the output increase should remain at or above the applicable minimum. Program instructions and logs can explain the route in more detail, but a wallet notification without matching on-chain balances is not enough to close the check.
Successful Record, Missing Wallet Balance
A successful record with no visible wallet increase usually points to a display or token-account reconciliation issue.
The transaction’s token balance changes can reveal the output mint and destination account even when the wallet hides that asset. Matching the destination owner with the signing wallet separates a hidden token account from a transfer to an unintended account.
A wallet or application refresh may load the new account and balance. Some interfaces also require the user to unhide an unfamiliar token before showing it in the main asset list.
Do not submit the swap again merely because the visible balance has not refreshed. A second signed transaction is a separate exchange and may execute against a different quote.
If the successful record lacks the expected output-token increase, inspect the actual mint, destination and executed instructions. That mismatch is not a display delay. The transaction record defines where the value moved and narrows the problem before another action is authorized.
Quote Preview Versus Settlement Evidence
The preview supports a decision before funds move: it presents the route, estimated output, price impact and execution boundary. Settlement evidence serves a different purpose after authorization. It records success or failure and the resulting token-account changes. When the two views disagree, the transaction record and resulting balances, rather than a cached preview, describe the completed exchange.
Raydium: common questions
Does a Higher Priority Fee Improve the Quoted Exchange Rate?
No. A priority fee pays for transaction-processing priority and does not improve the pool’s quoted exchange rate. A higher setting may give the transaction greater processing priority during congestion, but pool state can still change before execution. Review any refreshed quote before signing a replacement transaction.
Does a Higher Slippage Setting Guarantee That the Swap Will Confirm?
No. Slippage tolerance widens the minimum-output boundary for an exact-input swap or the maximum-input boundary for an exact-output swap. It does not correct an insufficient balance, an incompatible token account, an unavailable route or a transaction that expires before landing. A wider setting permits lower output in exact-input mode or higher spending in exact-output mode, so it should not be treated as a general failure fix.
Can a Split Route Settle Only Some of Its Swap Legs?
A split or multi-hop route packaged inside one Solana transaction is atomic, so a failed swap instruction prevents that transaction from leaving only part of the route settled; the transaction record should show either successful execution of the assembled route or failure.
Why Can a Swap Signing Request Contain Several Instructions?
One swap transaction may include compute-budget settings, creation of an output token account, more than one pool hop or native-token handling. Those supporting instructions can make the prompt longer than the visible quote. The selected mint addresses, spending account and authorized amount should still agree with the intended exchange.
What Does a Successful Transaction Prove About the Output Token?
A successful transaction proves that the recorded instructions executed and produced the listed account changes. It does not establish the token issuer’s identity, economic value, future liquidity or legitimacy. Asset identity must come from the mint address reviewed before signing, not from transaction success or a familiar display symbol.
What Changes When the Signing Request Is Rejected?
Rejecting the request withholds the wallet signature, so that proposed transaction is not submitted and cannot perform the swap. The unsent request does not create an on-chain network fee or token balance change. If the exchange is attempted later, obtain a fresh quote because the earlier route and output estimate may be stale.
Where May a Token-2022 Transfer Fee Appear During Reconciliation?
A Token-2022 transfer fee can affect the input reaching a pool, the output reaching the wallet or both, depending on the mints involved. When the quote identifies such a fee, compare the wallet’s net balance changes with the displayed net amounts. Do not automatically classify the fee-related difference as price impact or ordinary slippage.