Rebroadcasting the same signed Solana transaction is different from signing a new payment with a fresh blockhash. The first reuses one transaction identity; the second can create another independently executable attempt. Before signing again, establish whether the original already executed and whether it can still be accepted. An RPC submission response or a wallet timeout is not enough to answer both questions.
Ask what the Retry button actually does
A wallet can retry by forwarding the exact signed payload again, while another application can rebuild the payment and ask for a new signature. The button's label does not disclose that distinction. Save the first transaction identifier and compare any later identifier. Also compare the recipient, asset and amount: a different signature is a reason to reconcile a new attempt, not proof that a second payment succeeded.
Solana's sendTransaction reference states that the RPC relays the signed transaction as supplied and returns its first signature when accepted. The response does not wait for confirmation and does not guarantee execution. You can therefore have a returned identifier without a completed payment, or an uncertain interface response after an attempt was sent. Diagnose the transaction rather than interpreting every local message as its final outcome.
Classify the retry before reconciling the recipient
| Action or observation | Transaction identity | What to verify before paying again |
|---|---|---|
| Exact same signed bytes submitted again | The same signature | Its existing processing and execution result |
| Payment rebuilt with a fresh blockhash and signed | A new signature | Whether the original can still execute |
| Same recipient and amount but another signature | Separate candidate transaction | Results of both attempts, not only their visible similarity |
| RPC returned an identifier | Submission evidence | Actual status and any execution error |
| Wallet stopped waiting | An application timeout | Whether the original is confirmed, expired or still unresolved |
| No status in one lookup | No result from that lookup | Cluster, history coverage and validity evidence |
Solana's confirmation and expiration guide explains how recent blockhashes limit processing and support duplicate prevention. This article concerns ordinary transactions using that mechanism. Durable-nonce transactions have their own lifecycle; do not apply a recent-blockhash timeout to them merely because the wallet uses a similar send screen.
A fictional two-attempt payment
Imagine a payment of 4 token units from A to B. The first signed attempt has signature S1. The app loses its waiting connection, so it sends those same bytes again. Both submissions refer to S1, not two separate payments that should be added together in your accounting. Locate S1's actual result and token movement rather than counting submission attempts or repeated notifications.
Now suppose the app instead fetches a new blockhash and obtains a new signature S2 for the same 4-unit instruction. If S1 remains valid, both transactions can potentially execute. Two successful transfers would total 8 units, not one payment accelerated into completion. Solana's retry guidance specifically warns about re-signing before the initial blockhash expires. The fictional quantities illustrate the risk without providing a transaction script.
A new signature alone does not establish that the recipient got 8 units. One attempt might fail, expire or never be submitted. Open both records, inspect their results and identify the actual incoming movements. If only one succeeded, record that one as the executed payment and retain the other as an attempt. Our Solscan guide explains where the relevant movements differ from a general wallet activity summary.
Expiry prevents future acceptance; it does not erase earlier execution
For a recent-blockhash transaction, track the validity information returned when that blockhash was obtained, including lastValidBlockHeight. Use documented confirmation procedures and suitable current network observations rather than a guessed stopwatch interval. A wallet's timeout can be shorter than the transaction's acceptance window. Conversely, the expiration of that window does not show that the transaction was never processed before it ended.
That last distinction matters when a status lookup is empty. The getSignatureStatuses documentation distinguishes a recent-status search from searching transaction history. An absent result is not automatically a proof of nonexecution. Check the correct cluster, the available history and the original recipient records before deciding that a fresh payment is needed.
- Save the original signature, cluster, expected transfer and available validity information.
- Check status and the actual execution result for that signature.
- Determine whether Retry rebroadcasts the same bytes or creates a newly signed transaction.
- If considering a fresh signature, establish both the original outcome and whether further acceptance is still possible.
- Reconcile all candidate signatures against actual recipient movements.
- Report any duplicate execution to the receiving service with both records rather than sending another correction payment.
Changes to signed data are not an invisible adjustment
The blockhash is part of the transaction message that is signed. Treat a changed blockhash or instruction as a new signing decision. Do not accept an app's assurance that it merely refreshed the payment without checking the resulting identifier and intended effect. A signature-verification error is also different from a successful broadcast; preserve the exact error instead of repeatedly modifying fields until a screen looks successful.
For application developers, keep the business payment reference separate from its candidate signatures. Store submission, confirmation and execution as distinct states, and associate subsequent candidates with the same intended payment. Repeated user clicks should not silently create independently payable instructions. Follow the network's documented retry procedure and respect RPC limits; an aggressive resend loop does not solve missing outcome tracking.
The recipient's order record still needs reconciliation
A no-account swap has its own instructions about amount, network and payment window. A network retry does not extend those conditions. If two different signatures executed, provide both and explain that they were attempts to pay one order. Do not assume the receiver will combine them automatically or that an extra payment is a way to repair the original record.
If the problem is specifically an unavailable recent blockhash, our Blockhash Not Found guide covers that diagnosis. The retry decision remains separate: determine which transaction exists, what it did, and whether another instruction could duplicate it. A useful final record contains executed movements and unresolved attempts, rather than a count of how often the Send button was pressed.
FAQ
What does a Solana transaction signature identify?
The first signature is used as the transaction identifier. Repeated submission of the same signed payload therefore refers to the same transaction identity.
Does signing a Solana payment again create a new attempt?
Rebuilding it with changed signed data, such as a fresh blockhash, creates another signed transaction. Reconcile the original before authorizing a new attempt that might also execute.
Can changing a blockhash cause signature verification failure?
The blockhash is part of the signed message, so an old signature does not authorize arbitrary changes to it. Use the wallet's documented flow rather than manually altering a signed payload.