Transaction Propagation

Overview

Transaction propagation begins when a wallet or service submits a transaction to one or more network nodes. Accepting nodes validate basic policy and relay the transaction through gossip, inventory announcements, direct forwarding, or protocol-specific paths.

Peers may see the transaction at different times or reject it because of fees, conflicts, missing dependencies, rate limits, or local policy. Private relays and sequencer endpoints can bypass public mempools, changing visibility and ordering opportunities. Applications should measure acceptance and eventual inclusion rather than assuming one successful RPC response means network-wide distribution. Redundant submission can improve reliability but must not create unintended duplicate actions. Privacy-sensitive users should consider that propagation patterns can reveal an origin, while operators need anti-spam controls that preserve legitimate relay. Operational systems need idempotent processing keyed to stable transaction and business identifiers. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available.

These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. User-facing status should describe what is known without overstating settlement. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers. Operational takeaway: Propagation spreads a transaction through nonidentical peer views, so submission acceptance, network visibility, and eventual inclusion are separate states.