A Solana wallet saying “sent” only proves that an RPC node accepted your submission. It does not prove that the cluster processed, confirmed, or finalized the transaction. Start with the transaction signature, verify the cluster, then check its status and any execution error before retrying. If a send timed out, do not immediately create a second payment: the first transaction may still be on its way.
Most apparent “pending” cases fall into four groups: the transaction is still within its recent-blockhash validity window, it landed but your wallet or endpoint has not observed the required commitment, the blockhash expired before landing, or the RPC service is stale, rate-limited, disconnected, or otherwise unable to give you a reliable view. The steps below separate those possibilities without risking an accidental duplicate.
As an Amazon Associate I earn from qualifying purchases.
What a Solana transaction status actually means
Solana’s sendTransaction method verifies the signature and performs preflight checks, then relays the signed transaction. A successful response returns the transaction’s first signature. The official RPC reference cautions that “A successful response from this method does not guarantee the transaction is processed or confirmed by the cluster.” Treat that response as submission accepted by one RPC node, not as payment completed.
Free tools Windows power users keep installed
One-click scans. No signup required.
The signature is the durable handle for every later check. Solana exposes several commitment levels, and a wallet, explorer, and backend can each be using a different one or a different RPC endpoint.
#1 Best Overall
| Observation | What it proves | What it does not prove |
|---|---|---|
RPC returned a signature from sendTransaction |
The chosen RPC accepted the request after its checks and returned an identifier. | That a validator received, processed, or finalized the transaction. |
processed |
The node has a recent view in which the transaction was processed. | That the result cannot be rolled back. |
confirmed |
The transaction was voted on by a supermajority of active stake. | That it has the strongest possible finality. |
finalized |
The cluster has reached its strongest confirmation state for the transaction. | That every wallet UI has refreshed its display immediately. |
| No status or a missing transaction | That the queried endpoint cannot currently provide the requested evidence. | That the transaction never reached the network or definitely failed. |
Use the commitment level your application actually requires. A low-value interface update may show processed, while an exchange, accounting system, or withdrawal workflow may wait for confirmed or finalized. “Not shown” can therefore mean “not visible at this commitment or endpoint,” not necessarily “never landed.”
Safe troubleshooting procedure
Follow these steps in order. Do not move to a replacement payment until the evidence supports it.
1. Record the signature and cluster
Copy the complete transaction signature from the wallet or application. Also record whether the transaction was sent to mainnet, devnet, or testnet. These are separate Solana clusters; a signature searched on the wrong cluster will appear absent. Make sure the explorer, wallet, and RPC endpoint are all pointed at the same network.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Never provide a seed phrase or private key to an RPC operator, support person, or troubleshooting form. An RPC endpoint needs the signed transaction and public information, not your wallet’s secret material.
2. Query the signature status
Call getSignatureStatuses for the signature and note both the returned confirmation status and any error object. The request can be sent to the RPC endpoint configured in your wallet or application. A minimal JSON-RPC request has this shape:
{"jsonrpc":"2.0","id":1,"method":"getSignatureStatuses","params":[["signature-string-from-wallet"],{"searchTransactionHistory":true}]}The important fields are the confirmation state, the slot, and err. A non-null error means the transaction did not execute successfully. A status that is still processed is not equivalent to finality. If the result is null, continue with the remaining checks rather than treating null as proof of non-submission.
Rank #2
- Ideal for Gifting
- Ideal for a bookworm
- Compact for travelling
3. Request confirmed transaction details
When a status is available, call getTransaction at an appropriate commitment to inspect the recorded transaction, balances, logs, and error details. The method returns a confirmed transaction or null when it is not found at the requested commitment.
{"jsonrpc":"2.0","id":2,"method":"getTransaction","params":["signature-string-from-wallet",{"commitment":"confirmed"}]}A null result has several explanations: the transaction may not have landed, the requested commitment may be too strong for what the node currently knows, the endpoint may be behind, or the recent status cache may no longer contain the entry. After the blockhash window has passed, use transaction history and the resulting on-chain state—such as the recipient balance or application account state—to establish what happened.
4. Check the recent blockhash and validity height
Every Solana transaction carries a recent blockhash. It is valid only for a limited number of slots. Core transaction documentation describes a 150-slot age limit, while payment guidance describes the practical window as approximately 60 seconds. This is not a fixed wall-clock guarantee: slot duration varies, so signing delays, congestion, and endpoint lag can shorten or lengthen the observed time.
When constructing a transaction, obtain blockhash and lastValidBlockHeight from getLatestBlockhash and retain both values. The confirmation guide’s safe rule is to wait until the observed block height exceeds lastValidBlockHeight before declaring that original transaction expired. Do not rebuild merely because a wallet spinner has lasted a few seconds.
5. Keep blockhash, simulation, send, and confirmation views consistent
A common application error is to fetch a blockhash from one node, simulate on another, submit through a lagging node, and confirm through a fourth endpoint. The lagging node may report blockhash not found or fail to forward a transaction that is valid elsewhere.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteUse the same commitment for blockhash retrieval and preflight simulation. This remains important when skipPreflight is enabled: skipping simulation does not remove the need for a coherent confirmation strategy. Keep related requests on a healthy endpoint where possible, and compare the endpoint’s slot freshness with another reliable view if results conflict.
6. Read the error before changing anything
Separate an RPC transport problem from a transaction-level problem. A preflight error means signature verification or simulation rejected the transaction before forwarding. An on-chain instruction error means the transaction reached execution but an instruction failed. Solana transactions are atomic: state changes from a failed transaction are reverted, but fees can still be charged.
Insufficient SOL for the transaction fee and insufficient token balance for an instruction are different failures. Adding SOL may address the former; it will not create missing tokens or repair an invalid instruction. Likewise, changing RPC providers cannot fix a program instruction that is deterministically wrong.
7. Treat a timeout as unknown, not as failure
A client-side timeout can occur after the RPC accepted or even forwarded the signed transaction. While its blockhash remains valid, reuse the same signed transaction and continue tracking its original signature. Do not construct a second logical payment just because the first request did not return promptly.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Once the original validity height has passed, search transaction history and verify the expected state change. Rebuild and resend only after establishing that the original did not land. Retrying a withdrawal before blockhash expiry can create a double-spend risk if both submissions are processed.
8. Check the endpoint and connection
Shared public RPC services can return HTTP 429 when rate limits are exceeded or HTTP 403 when traffic is blocked. A stale slot, repeated disconnect, or failed WebSocket subscription can also leave a wallet showing an old state. Re-establish WebSocket subscriptions after a disconnect and reconcile the result with an HTTP status or transaction query.
If the same transaction behaves differently across endpoints, compare slot freshness, supported methods, request limits, delivery and retry behavior, status tracking, and fallback capacity. A provider change can improve delivery or visibility, but it is not a remedy for an invalid instruction or an insufficient balance.
Rank #4
Why Solana transactions fail
Expired or unrecognized blockhash
The transaction may have spent too long waiting for a signature, or the receiving node may be behind the node that issued the blockhash. Check lastValidBlockHeight and the commitment used to fetch it. If the validity height has not passed, continue tracking the original signature. If it has passed and history confirms no landing, fetch a fresh blockhash and rebuild.
Preflight simulation or signature failure
sendTransaction can reject a transaction before forwarding it when signature verification or simulation fails. Read the returned simulation error and correct the specific account, instruction, signer, or transaction-construction issue. Repeating the identical payload will produce the identical preflight result.
Instruction execution failure
An instruction can fail after the transaction reaches the cluster because a program rejected its inputs, account state, permissions, or requested operation. Atomicity means earlier state changes in that transaction are rolled back, yet the network can still charge the transaction fee. Inspect the returned error and program logs before deciding whether a new transaction is appropriate.
Insufficient SOL for fees
The documented base fee is 5,000 lamports per signature in the cited core transaction documentation. Fee rules can change, and transactions may involve additional prioritization or application-specific costs, so treat that figure as the documented base amount rather than a permanent universal price. The fee-balance error is distinct from a token-transfer balance error.
Insufficient token balance
A token instruction can fail because the source account lacks enough tokens, even when the wallet has enough SOL to pay the fee. Verify the token account, mint, decimals, and available balance. Sending the same transaction again without changing the balance or instruction cannot succeed.
Recommended Free Tools
Already processed
The transaction pipeline can reject a duplicate submission with an AlreadyProcessed condition. This is a signal to track the existing signature, not to create a second payment. Search by the first signature and reconcile the recipient’s state before taking any further action.
Best Value
- It can be a gift option
- Comes with secure packaging
- Helpful in various ways
Invalid or conflicting compute-budget instructions
Compute-budget instructions are validated as part of the transaction pipeline. Invalid or conflicting instructions can cause rejection during validation. Treat this as a construction or application-logic issue; changing hardware or waiting for the network will not repair malformed compute-budget settings.
Oversized or malformed transaction
Core documentation lists a 1,232-byte maximum for the documented transaction size limit. A transaction that exceeds the limit or is malformed can fail before meaningful execution. This is less likely than an expired blockhash or balance error for an ordinary transfer, but it matters for transactions carrying many instructions or account addresses.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why a transaction can remain pending
| What you observe | Most useful interpretation | Next safe action |
|---|---|---|
| The wallet says sent, but no confirmation appears | The RPC accepted the submission; processing is not yet proven. | Query the original signature and wait at the required commitment. |
Status is processed |
A node observed processing, but the view may still be rolled back. | Continue to confirmed or finalized if your use case requires it. |
getTransaction returns null immediately |
The transaction may be too new for that node, at a different commitment, or absent from its view. | Check the signature status, cluster, endpoint freshness, and retry the query later. |
| Status disappears after the validity window | The blockhash may have expired before the transaction landed, or the endpoint’s recent cache may no longer contain it. | Check history and resulting state before rebuilding. |
| HTTP 429 or 403 responses | The endpoint is rate-limiting or blocking requests. | Reduce request pressure or use a healthy fallback; do not infer an on-chain instruction failure. |
| WebSocket stopped updating | The subscription disconnected or the connection became stale. | Reconnect, then reconcile with HTTP RPC queries. |
How to retry without paying twice
- Keep the original signature, signed payload, cluster, blockhash, and validity height in your application logs.
- Query
getSignatureStatusesand inspecterr; usegetTransactionwhen a confirmed record is available. - While the validity height is still current, monitor the same signature rather than creating a replacement.
- After expiry, check transaction history and the recipient or application state. A state change can prove success even when a recent status cache no longer does.
- Only when the original is shown not to have landed should you obtain a fresh blockhash, rebuild the transaction, and submit a new logical payment.
- After resubmission, store the new signature separately. Never overwrite the first signature, because it is needed to explain an eventual duplicate or delayed landing.
Endpoint choices for applications
For an application that frequently sends transactions, evaluate infrastructure by evidence rather than a generic “fast RPC” label. Useful comparison points include:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems- Slot freshness and how quickly the endpoint reflects the cluster.
- Support for the RPC methods and commitment levels your workflow needs.
- Request limits, HTTP 429 behavior, and any traffic-blocking policy.
- Transaction delivery, retry, and status-tracking features.
- WebSocket reliability and the process for reconnecting subscriptions.
- Fallback capacity and the ability to reconcile one endpoint’s answer with another.
Measure representative latency and error rates for your own request mix and region. A provider switch addresses availability, freshness, or delivery symptoms; it does not correct a failed program instruction, missing token balance, invalid compute budget, or expired transaction that was never rebuilt.
Wallet-user checklist
- Copy the complete signature before closing the confirmation screen.
- Confirm mainnet, devnet, or testnet in both the wallet and the explorer.
- Look for a returned error, not just a spinner or “sent” label.
- Check the same signature at
processed,confirmed, and, when required,finalized. - Do not share a seed phrase or private key with an RPC service or support contact.
- Do not resend a timed-out payment until the original signature, blockhash validity, history, and resulting state have been checked.
- If a failed transaction charged a fee, remember that atomic rollback does not guarantee fee reimbursement.
Technical limits that explain timing
The recent-blockhash window is expressed in slots, not a guaranteed number of seconds. The documented 150-slot limit and the payment guidance’s approximate 60-second description are two views of the same operational constraint; variable slot timing means neither should be treated as a stopwatch. Applications should therefore use lastValidBlockHeight, not a hard-coded sleep, as the expiry test.
The 1,232-byte transaction-size limit explains why complex, account-heavy payloads can be rejected during construction or validation. The documented 5,000-lamport base fee per signature explains why a failed instruction can still have a financial effect. These figures come from current Solana documentation and should be rechecked when fee rules or protocol limits change.
When to contact wallet or application support
Provide support with the signature, target cluster, approximate submission time, commitment used, RPC response, and complete error object. Do not send secret keys. If the signature is finalized but the wallet balance is wrong, the issue is likely display synchronization or application accounting rather than transaction execution. If no signature was ever returned, the investigation starts with the wallet’s signing and RPC submission path; if a signature exists, the network and endpoint checks above provide the diagnostic trail.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
