Raydium
Raydium pool swaps allow changes before signing and become irreversible after successful finalization.
Raydium allows changes to an unsigned swap, while a successfully finalized trade cannot be canceled or edited through the swap interface. Before approval, token selection, amounts and execution bounds remain adjustable. After submission, the transaction may succeed, fail or expire. Its execution record and credited output establish which action remains possible.
Unsigned quotes and wallet approval
A swap quote connects the selected spending token and amount to estimated output, which Raydium uses to prepare transaction instructions and execution bounds. Execution requires the spending balance and a funded fee payer; network fees and any funding needed to create a receiving token account use SOL. Before approval, changing the tokens or amount calls for a fresh quote and matching transaction. Authorization covers the prepared message; successful execution records its actual transfers. Rejecting an unsigned request avoids authorizing that proposed swap.
Slippage bounds and pool conditions
Slippage tolerance sets an execution bound around the quote, while price impact comes from trading against pool liquidity. Fixed-input swaps set a spending amount and minimum output; where supported, fixed-output swaps specify the desired output and cap the input. Availability depends on the interface and route. Pool reserves, active concentrated liquidity and swap fees influence the quote, along with applicable token transfer fees. A wider tolerance permits worse execution within that bound without creating any cancellation right after a successful swap.
Can a pending pool swap still be canceled?
A broadcast pool swap has no ordinary cancellation control that recalls it from the network. The signed transaction can still execute while it remains valid, even after someone closes the panel or changes its displayed quote. A pending notification describes the interface’s current view and can outlast the underlying submission attempt.
Signing and sending are separate operations, even when a wallet combines them into one approval flow. The signature authorizes a specific message, so changing an amount, destination account or output bound requires a changed message and fresh signatures. A transaction identifier supplies a handle for lookup without proving validators executed the swap successfully or finalized its block.
For recent-blockhash transactions, expiry follows the blockhash’s validity boundary, not a timer in the browser. The blockhash preparation response includes a last valid block height. Once the chain passes that boundary, an unlanded transaction cannot execute using that blockhash. Status still needs checking because the transaction could have landed before expiry. A missing record from one service does not by itself establish safe replacement.
A failed execution has a different meaning from an absent record. When a transaction instruction fails, Solana rolls back the token balance changes made by that transaction’s instructions. A transaction that reaches execution can still incur network fees. Failure therefore stops that transaction’s token exchange without promising an unchanged total SOL balance. The execution error can distinguish unmet amount bounds from problems with funding or token accounts.
The original execution outcome determines whether another swap is a retry or an additional exchange. Success leads to reconciliation; a finalized failure or verified expiry without execution permits a newly reviewed attempt. If the earlier transaction remains valid and unresolved, a new signature can create a second executable trade.
Swap exits before and after submission
An unsigned quote leaves room to reconsider the exchange without moving tokens. Submission changes the available choices because a signed copy may already have reached validators.
| Option | What changes | Original swap limits and conditions |
|---|---|---|
| Revise the quote | Token choices, amount or execution bounds | Only the unsigned proposal changes |
| Reject the unsigned request | Withholds wallet authorization | Does not recall an earlier signed copy |
| Start a fresh attempt | New quote and transaction authorization | Appropriate after finalized failure or verified expiry without execution |
| Swap received tokens back | Available output becomes input to a new trade | The successful original trade remains finalized |
Priority fees affect scheduling incentives, while slippage bounds govern acceptable execution. Adjusting either setting requires fresh authorization for a changed message.
What can change after a swap is finalized?
A successfully finalized swap fixes its executed transfers; subsequent transactions can change your remaining token holdings. Exchanging the received token back is a new trade against the liquidity available then. A reverse swap requires a usable route and token accounts that permit the necessary transfers. Its quote may differ because the earlier swap changed pool reserves, other trades occurred or available liquidity changed. Swap fees and any applicable token transfer fees also affect the new exchange. The reverse trade can return less than the original spending amount. The new trade needs its own reviewed bounds and authorization.
A reverse-direction swap does not refund the original trade’s execution costs.
Transaction records and balance reconciliation
A finalized transaction record preserves the authorized message and execution outcome, even when a wallet later changes its display. For reconciliation, identify the spending and receiving token mints and the actual destination account. Compare that transaction’s token balances before and after execution. For routes that wrap or unwrap SOL, also inspect the instructions and SOL balance changes. Network fees and token-account funding or refunds can affect the net SOL change. A later wallet balance may include unrelated transfers or further trades, so it cannot alone reconstruct an earlier swap’s output. A screenshot of the quote preserves the preview without establishing what the chain executed. You can correct local notes or unit conversions while the executed mints and amounts stay unchanged.
A finalized label alone does not prove a swap succeeded, because failed transactions can finalize with execution errors and unchanged token balances.
Solana’s processed commitment level reports a node’s latest execution view, which can still include a fork that the network drops. Confirmed means a supermajority of stake voted for the block; finalized marks the strongest confirmation state. Execution success remains a separate property at every level. When the wallet display and execution record disagree, check the destination account and token mint; delayed displays cannot alter finalized transfers.
Raydium’s constant-product market maker (CPMM) program rejects a fixed-input swap if its output, after applicable output transfer fees, falls below the minimum amount. The gross pool transfer can therefore exceed the amount credited to the receiving token account. Token decimals determine the units used to display that account’s balance. Where token balance metadata is available, the relevant fields are preTokenBalances and postTokenBalances.
Raydium: questions and answers
Will rebroadcasting the same signed swap execute it twice?
Rebroadcasting identical signed transaction data does not create a second execution of that transaction. Solana checks for previously processed transactions. A newly built message with a different blockhash requires new signatures and constitutes a different transaction, even if its token amounts match.
Can a successful simulation reserve the quoted output for my swap?
A successful simulation does not reserve pool liquidity or guarantee the quote’s output. It evaluates transaction instructions against the state that an RPC node uses for that simulation. Other trades can change the pool before actual execution. The bounds in the signed transaction govern the eventual attempt; a changed pool can cause a rejection.
Does a successful Trade API response mean my swap has executed?
A successful Trade API response does not establish on-chain execution. A quote response reports the quote request’s outcome; a build response can provide prepared transaction data. Neither response substitutes for the execution result that belongs to a submitted transaction signature. A quote identifier and a transaction signature describe different objects.
What happens to completed account setup if the swap fails in a later transaction?
Completed account setup remains in place if a separate, later swap transaction fails. Atomic rollback applies within the failing transaction. If setup and the swap share one transaction, failure rolls back their instruction-driven changes together. The transaction boundaries determine what survives, so check the individual records when an integration returns multiple transactions.
Should I share my recovery phrase when asking someone to investigate a swap?
A recovery phrase is unnecessary for investigating a swap and gives access to the wallet’s keys. A transaction signature lets someone look up the transaction’s status without granting control of those keys. Sharing the phrase cannot reverse finalized token transfers and can expose other wallet assets. Keep recovery phrases and private keys out of support messages and screenshots.
Last updated