Mempool

Overview

A mempool stores transactions that a node has checked against current consensus and local relay rules but that are not yet confirmed in a block. Nodes advertise and relay eligible transactions to peers, while producers choose candidates for inclusion. There is usually no single global mempool. Nodes can differ because of network latency, fee thresholds, capacity, replacement policy, private order flow, or chain state. A transaction visible in one mempool may be absent elsewhere or later removed.

Wallets should track broadcast acceptance separately from confirmation and preserve enough information to rebroadcast or replace transactions safely. Payment services must not credit solely from mempool observation because conflicts and drops remain possible. Operators should monitor size, fee distribution, and rejection reasons for reliable fee estimation. 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: Mempools hold unconfirmed local candidates, so visibility indicates propagation rather than canonical inclusion, finality, or universal network acceptance.