Broadcast

Overview

Broadcast begins when a wallet, node, or service submits a completed transaction to the peer-to-peer network. The receiving node decodes the message, applies consensus and local policy checks, and may place the transaction in its pending pool. If accepted, the node can relay it to additional peers through Message Propagation.

A successful API response from a broadcast endpoint usually means that one node accepted or recognized the transaction. It does not mean miners or validators will include it, that every peer has seen it, or that contract execution will succeed. Payment systems should distinguish submission, peer acceptance, block inclusion, confirmation, and final settlement.

Broadcast can fail for several reasons: malformed encoding, an invalid signature, a spent input, an incorrect nonce, insufficient balance, a fee below relay policy, or a conflicting transaction. Some nodes also reject technically valid but nonstandard transactions under their local policy. Error handling should preserve the raw transaction and exact response.

If a valid transaction remains unseen or is dropped from peer pools, a sender may use Rebroadcast. Repeated submission cannot repair a fundamentally invalid transaction or guarantee inclusion during Congestion. Fee replacement, nonce management, or a new transaction may be required instead.

Operationally, broadcast should be idempotent and observable. Systems should record the transaction hash before sending, use multiple providers carefully, and avoid creating a different signed transaction on every retry. Monitoring must continue after submission because only later blockchain data establishes whether the transaction entered the canonical chain.

Multi-provider broadcasting should use the identical signed payload and should treat already-known responses as successful recognition rather than errors. If providers return conflicting validation results, the system should stop automated replacement, retain the evidence, and determine whether the difference comes from node policy, synchronization, or transaction validity.