Shared Mempool

Overview

A shared mempool lets several ordering participants observe pending transactions before block production. Peers gossip submissions, validate admission rules, remove confirmed or expired items, and attempt to maintain overlapping transaction views. Shared visibility can improve failover and reduce dependence on one sequencer endpoint. It does not guarantee identical ordering, complete propagation, or freedom from private order flow. Network latency, local policies, fees, and denial-of-service defenses naturally create different views.

Designers must prevent spam, transaction replacement abuse, replay across domains, and leakage of sensitive intent. Users should understand whether submissions are public, encrypted, or sent privately. A shared mempool can support decentralized sequencing, but consensus is still required to choose one accepted order from competing proposals. Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Shared Mempool should be represented as a sequence of observable states rather than one success flag. 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.

Practical implication: A shared mempool distributes pending transactions, but consensus and ordering rules still decide which view becomes the canonical block.