Rebroadcast

Overview

Rebroadcast resends an already signed transaction rather than creating a new payment. A wallet or service may do this when the original Broadcast reached only one provider, peers restarted, local mempools expired the entry, or the sender wants to restore visibility after a network interruption.

On networks where the transaction identifier is derived from the signed bytes, rebroadcasting identical bytes preserves the same hash. This makes retries easier to track and generally allows nodes to recognize duplicates safely. A different fee, nonce, input set, or signature usually creates a different transaction and should be handled as replacement rather than rebroadcast.

A node can reject a rebroadcast for the same reason it rejected the original. The transaction may conflict with a confirmed spend, use an old nonce, violate relay policy, or offer a fee below current conditions. Repeated submission cannot convert invalid data into a valid transaction or force block producers to include it.

During Congestion, a valid low-fee transaction can remain pending even after successful rebroadcast. The appropriate response may be fee replacement, child-pays-for-parent, cancellation through a conflicting nonce, or waiting, depending on the network and wallet. Operators should not apply a replacement strategy without understanding its effect on accounting and recipients.

Payment and payout systems should record every submission attempt, provider response, and canonical transaction hash. Automated retry schedules need rate limits and clear stop conditions. Once the transaction is confirmed or replaced, further rebroadcast should stop to avoid confusing monitoring and support.

A wallet should also avoid endless automatic rebroadcast of transactions that are intentionally canceled or replaced. The monitoring record needs a superseded state and a link to the replacement hash so later support queries do not mistake the old transaction for the active payout.