A Solana transaction failed or disappeared: how to find the cause

Preserve the evidence before trying again

A wallet's pending message can describe several situations: the user has not signed, an RPC response was lost, the network rejected execution or the wallet has not refreshed. Begin by finding the stage rather than immediately repeating the payment.

Record the network, source account, intended recipient and asset. Copy the original signature if one exists. Add the exact wallet or application error and the approximate time. For a token, keep its mint. For a service deposit, save the receiving instructions and its deposit or order ID.

A signature can be known before the network reports a result. If the application signed locally and lost the send response, that signature remains useful. If no signature is available, ask the sending service whether it broadcast a transaction or still has an internal request.

Keep the first attempt in your records even if you later create another. A delayed result can arrive after a user interface has marked the first attempt expired.

Check failures before network execution

If you rejected the approval or the wallet could not produce the required signature, investigate the wallet request and signing setup. An unsupported transaction format, missing hardware support or an unavailable signer can stop the operation before broadcast.

Preflight is a service-side check that can simulate the submitted request. A reported preflight error is different from a transport timeout. Save its program error and logs, and still reconcile the intended transaction identity when there is uncertainty about submission.

Insufficient SOL often concerns the fee payer or account setup. A token balance does not cover a native SOL expense automatically. Compare required costs with the relevant payer's balance, rather than changing the token amount blindly.

A blockhash problem can concern a stale signing delay or different endpoint views. Keep the construction and submission context. The blockhash guide explains the lifetime metadata developers should retain.

Look up the original signature

Use an explorer or RPC for the same cluster. Developers can query getSignatureStatuses and obtain transaction details through getTransaction. Read the execution error and observed commitment separately.

A null result means that source did not return the record under the request's conditions. Recent-status caches, historical coverage, requested commitment and supported transaction versions affect lookup. A service with suitable history can establish a result that a limited endpoint cannot show.

If the transaction is recent, keep observation bounded and allow the service to update. If it is old, use the appropriate historical lookup. Avoid sending repeated status requests without a delay, because throttling can make observation worse.

For current Alpenglow-migrated clusters, follow the Foundation's commitment guidance rather than a Tower-era finality countdown. The practical question is still whether you have an accepted execution result for the original signature.

Unknown and failed are separate outcomes

Use an execution error to find the failing action

Open transaction details and locate the first relevant failed instruction. Read its program ID and logs. The same transaction can have account creation, approval, swap and cleanup instructions, so the failed action may differ from the website button's headline.

Funding or account errors call for checking the payer, token holdings, expected account type and required setup. Authority errors call for comparing the supplied signers with the program's required roles.

Swap-bound errors can mean the route no longer satisfies the accepted output or input condition. Obtain a new quote and decide whether its terms are acceptable. Increasing slippage tolerance does not repair a wrong account or missing authority.

Resource errors concern execution limits and the constructed message. A builder should simulate the relevant transaction and inspect its actual path before changing the budget.

A recorded execution failure can still pay a network fee. Application changes roll back under atomicity, with special runtime handling such as durable nonce advancement requiring its own interpretation.

If execution succeeded, follow the asset

For SOL, find the destination account and amount. For a token, verify the mint and destination holding account, then read the actual credited amount. The displayed token name alone can lead you to inspect the wrong issuance.

If the network receipt is present but a wallet balance is stale, inspect the wallet's selected account, cluster and token discovery. Refreshing or investigating its data source is more relevant than repeating the payment.

If the recipient is an exchange or merchant service, check its deposit or invoice record. A 25 USDC network receipt can exist while the service still needs to match it to a customer or order. Supply the signature and receiving instructions to that service's support.

For a swap, reconcile both assets and the relevant SOL movements. A temporary wrapped-SOL account can close as part of the operation. The explorer guide shows how instructions explain a balance change that initially looks unexpected.

Handle unknown outcomes and replacements deliberately

A transport timeout establishes a communication problem. It does not establish that the network rejected the action. Continue tracking the original signed attempt and any business state it was intended to change.

For recent-blockhash requests, developers should compare the relevant block height with the saved last-valid height. Expiry prevents new inclusion under that validity condition, but does not rule out earlier execution. Durable nonces use their account state instead of that height window.

Creating a fresh signed transfer can pay the same recipient twice. If you must replace a request, link the attempts and apply the product's duplicate-protection or reconciliation design. Merchants should separately enforce one-time fulfilment even when an extra transfer arrives.

A concise support note can say: mainnet; 25 USDC expected; this signature; execution succeeded; this destination token account gained 25; exchange deposit remains pending. That evidence points to a particular stage, rather than an undifferentiated report that Solana lost the money.

Common questions