Raydium swap tracking shows when to adjust an attempt and how to confirm the resulting balances

Raydium lets you follow a swap from a live quote to a transaction signature, then verify its recorded status and resulting balances. If the attempt stalls or fails, refresh the quote and change only the control that matches the cause, such as slippage tolerance or a priority fee.

Bottom line: Track the original signature before retrying, then change only the setting that matches the recorded failure.

The inputs that make the first exchange traceable

A traceable swap starts with the exact input and output token mints, the amount and a quote that hasn't gone stale. Token symbols alone aren't enough because unrelated mints can share similar names. The wallet must be connected to Solana, hold the intended input and retain enough SOL for network fees. It also needs to support the transaction format presented for signing.

Before approval, review the expected output, route, price impact, pool fees and minimum received amount. These fields describe the proposed exchange and its limits. They don't prove that anything has reached the network. If the minimum received amount isn't acceptable, stop at the quote. Nothing needs to be reversed because no transaction has been authorized.

Once a transaction is submitted, save its signature. That identifier connects the interface status, wallet history and on-chain record. Without it, a disappearing notification can leave an otherwise ordinary delay looking like a failed swap.

Status fields before and after submission

Each status answers a different question: whether a quote exists, whether the wallet authorized it, whether the network received it and whether execution succeeded.

Before a signature exists

A quote is calculated from available pool state and selected limits. It can change before signing as liquidity or prices move. A wallet prompt means the transaction has been assembled, but rejection or closure at that point leaves no submitted swap to track. Requesting another quote is safe because the earlier one never became an on-chain instruction.

Once the wallet has signed

Signing authorizes a specific transaction. Submission then sends that signed request to the network, and its signature is the lookup key. The two steps are close together in most interfaces, yet a signature alone doesn't establish successful execution.

Pending or unknown

A pending transaction may still be waiting for inclusion. An unknown status can also mean that a status service or wallet hasn't refreshed. Treat either state as unresolved until the signature shows success or failure. Expiration requires the network's block height to pass the transaction's last valid block height. Building a separately signed retry too early can create another valid exchange request.

Successful or failed execution

A successful record shows that the transaction executed. A failed record means its state changes didn't complete, although the network may still charge a transaction fee. Capture the reported error before changing any setting. Its category determines whether the next step is a new quote, a fee adjustment or a stop.

What should change after a slippage failure?

Start with a fresh quote because the old limit describes pool conditions that have already moved. For an exact-input swap, slippage tolerance sets the lowest output amount the transaction may accept. An exceeded-slippage failure means execution couldn't satisfy that limit when the transaction ran.

Increasing tolerance is valid only when the new minimum received amount remains acceptable. It doesn't restore the earlier price. A smaller input amount or another available route may produce less price impact without widening the limit as far. Compare the refreshed output and fees before choosing between those options.

Repeatedly raising tolerance can authorize a worse output without addressing why the transaction exceeded its limit. Stop if the available minimum falls outside the intended exchange. A priority fee also won't repair a slippage rejection because inclusion speed and acceptable output are separate controls.

Priority fees belong to congestion failures

Adjust the priority fee when the evidence points to delayed inclusion or expiration during congestion, not when the program returned a deterministic error. A priority fee raises the bid paid for transaction processing. It can improve the chance of timely inclusion, but it doesn't improve the quoted rate or guarantee confirmation.

Check the original signature before rebuilding anything. If that transaction has succeeded, the exchange is complete. If it has failed or expired, obtain a fresh quote and review its minimum received amount before signing again. Changing the fee after signing isn't possible; a different fee requires a newly assembled transaction.

A higher bid can't fix an unsupported transaction, an unavailable route or insufficient liquidity. Those conditions need their own response, even when congestion is happening at the same time.

Why can a successful swap still look incomplete?

A successful swap can look incomplete when the wallet's token list or cached balance hasn't refreshed. The transaction record remains the stronger indicator because it shows whether execution succeeded and how token balances changed.

Match the signature to the signing wallet, then compare the input and output mint balance changes. Refresh the wallet and reveal hidden token accounts if the recorded output isn't visible. Checking the mint matters because a familiar symbol can point to a different token than the one used in the transaction.

Don't submit the swap again merely to make the interface update. If the chain record shows success, another signed transaction is a new exchange. Reconcile the recorded balance change with the quoted minimum before deciding that any discrepancy remains.

Failures that slippage and priority fees can't repair

Some failures occur before price tolerance or transaction ordering matters. Their messages point to route data, available liquidity, fee funding or signing compatibility.

Stale route or pool data

A route can become unusable after its quote was prepared. Refreshing creates a new quote against newer pool state. If the interface offers another route, review it as a separate proposal rather than assuming it preserves the previous output and fees.

Insufficient liquidity for the amount

A route may exist yet fail to support the requested size within acceptable limits. Reducing the amount can change price impact and available routing. Widening slippage isn't an automatic solution because it may merely authorize an output you wouldn't otherwise accept.

Not enough SOL for transaction costs

The wallet needs SOL for network charges even when another token supplies the swap input. Creating a required output token account can add to that need. Make sure the wallet has enough SOL for these costs before assembling another attempt; raising the priority fee increases the amount required.

View full-size image

Wallet or transaction compatibility

A wallet that can't sign the presented transaction format won't produce a usable submission. Resolve the connection or use a compatible signing path before returning to the quote. Slippage and priority changes have no effect when authorization itself can't be completed.

Costs that remain after a failed attempt

A quote has no network cost, and declining a wallet prompt doesn't execute a transaction. Costs begin when a signed request reaches network processing.

A failed transaction that reached on-chain execution can still charge its network fee even though the swap itself did not occur. The rejected swap doesn't produce the intended token exchange. That fee can reduce the fee payer's SOL balance even though the intended exchange didn't occur.

Slippage tolerance isn't a network fee, but widening it changes the range of outputs that can pass. A priority fee is part of the newly signed transaction's cost if the network processes it. On a retry, increase either setting only when the recorded outcome supports that change.

Evidence and stopping points after submission

Use the transaction record and resulting token balances to confirm completion, not one interface label. The signature should belong to the expected wallet, show successful execution and contain the intended input and output mint changes. The wallet display can then be refreshed to match that record.

If a transaction fails or expires without exchange balance changes, you can review a fresh quote or stop. An unresolved signature doesn't offer that certainty. Preserve it and avoid authorizing another attempt until its validity and status are clear.

After success, the swap can't be canceled through a retry or browser action. Any further submission requests another exchange. The practical limit is therefore simple: stop once the successful record and balance changes agree, and don't use a second swap to correct a display delay.

Last updated · 16 Sep, 2026