Many explanations and block explorers encourage the idea that once a transaction is sent, the whole network instantly knows about it. This guide unpacks why decentralized nodes never share a single, perfectly synchronized view of pending transactions. A mempool is the local data structure where a node holds valid, unconfirmed transactions it currently knows about. We will look at how transactions move between nodes via gossip, why mempools are local and policy-driven, and why nodes disagree about which transactions exist at a given moment. We will not walk through wallet interfaces, trading workflows, or protocol-specific fee rules. The focus is the network-level mechanism: how transactions propagate, why propagation is slow and lossy, and what mempool visibility can and cannot tell you about eventual inclusion.
The misconception: a single shared mempool
A common mental model treats the mempool as a single global queue: every pending transaction goes into one big bucket, and every node, explorer, and wallet reads from the same list. This picture is intuitive if someone is used to centralized systems where a server maintains a canonical job queue.
In a peer-to-peer blockchain network, there is no central server maintaining such a queue. Each node runs its own software, connects to a limited set of peers, and stores only the transactions it has received and chosen to keep. The “global mempool” idea conflicts with this architecture because no protocol rule forces nodes to hold identical mempool contents or to relay every transaction to everyone.
As a result, two honest, fully synced nodes can legitimately disagree about whether a specific transaction exists at a given moment. This is not a bug in consensus; it is a direct consequence of how decentralized networking and local policies work before a transaction reaches a block.
- The mempool is not a single global database; it is a separate local data structure on each node.
- Broadcast is not instant delivery; it is the start of a best-effort gossip process across limited peers.
- Network visibility is not uniform; different nodes legitimately see different pending transactions at the same time.
- Mempool presence is not a promise of inclusion; it only means some node is currently storing the transaction.
- Explorer output is not ground truth; it reflects the mempool view of specific nodes, not the entire network.
What a mempool actually is
At the system level, a mempool is a node’s in-memory (or local-disk) staging area for transactions that have passed basic validation but are not yet part of the canonical chain. It is a buffer between the raw network and the node’s view of confirmed state.
When a node receives a transaction from a peer, it checks signatures, basic format, and simple policy rules. If the transaction passes, the node stores it in its mempool along with metadata such as fee rate, arrival time, and dependency relationships. From there, the node may offer these transactions to any local block-production logic or simply keep them for relay.
The mempool is not part of consensus state: nodes are free to configure size limits, fee thresholds, and eviction policies. Two nodes following the same consensus rules can still maintain different mempools because mempool behavior is governed by local resource constraints and policies, not by the chain’s agreement rules.
- Local: each node has its own mempool, populated only with transactions it has received and accepted.
- Ephemeral: mempool contents change constantly as transactions arrive, are included in blocks, or are evicted.
- Policy-driven: nodes apply local rules for minimum fees, size limits, and replacement, which shape mempool contents.
- Best-effort: nodes attempt to relay and store useful transactions but are not required to hold or forward everything.
- Outside consensus: mempool state is not agreed upon by the network and is not recorded on-chain.
Local views and partial knowledge
Because each node connects to only a subset of all other nodes, its mempool can only contain transactions that have reached it along some network path and passed its local filters. There is no mechanism that forces every transaction to traverse every path or be retained indefinitely.
Network topology matters: a transaction may spread quickly through one cluster of well-connected nodes while reaching distant regions more slowly or not at all. Local policies matter as well: a node that enforces a higher minimum fee or stricter filters will reject or evict transactions that another node happily keeps.
The result is that mempools across the network overlap but are not identical. At any given time, some transactions are widely known, some are known only in a small region of the network, and some have already been forgotten by nodes that once held them.
- Connectivity: nodes have different peers, so some receive a transaction along short paths while others never see it.
- Timing: even with identical peers, message arrival order and network latency create short-term differences in mempool contents.
- Fee thresholds: nodes may reject or evict transactions below a local minimum fee rate, while others still keep them.
- Eviction: when mempools are full, nodes drop lower-priority transactions, leading to divergent sets.
- Filtering: nodes may apply additional policy filters (e.g., size, complexity, or risk rules) that cause them to ignore certain transactions.
Vignette: Same transaction, different local reality
Consider two friends, Ana and Ben, each running their own full node in different regions. Ana’s node is connected to peers mostly in her geographic area, while Ben’s node is connected to a different set of peers closer to him.
A new transaction is created and first reaches a peer near Ana. It quickly gossips through that cluster and lands in Ana’s mempool, where she can query it by hash. She sends the hash to Ben and asks if his node also sees it.
Ben queries his node and finds nothing. In this moment, the transaction exists in Ana’s local view but has not yet travelled along any path that reaches Ben’s peers. A few seconds or minutes later, depending on network conditions and policies, the transaction may finally propagate to Ben’s region and appear in his mempool, or it may be filtered or evicted along the way and never arrive at all.
Gossip and transaction propagation
When a wallet or application “broadcasts” a transaction, it usually sends it to one or a few entry nodes, not to every node in the network. From there, the transaction spreads via a gossip protocol: each receiving node validates it and then decides whether to forward it to some of its peers.
A typical node first performs lightweight checks: format, signatures, and simple policy rules. If the transaction passes and is not already in the mempool, the node adds it to its mempool and marks it as newly seen. The node then advertises or directly relays the transaction to a subset of its peers, often rate-limited to avoid flooding the network.
Each peer repeats this process independently. Because nodes choose which peers to inform, how quickly to send data, and when to de-prioritize or drop messages, the resulting propagation is uneven. “Broadcast” therefore means initiating a chain of best-effort relays, not guaranteeing that every node will receive or store the transaction.
- A transaction is created and sent to one or a few initial nodes in the network.
- An entry node performs basic validation and, if acceptable, inserts the transaction into its local mempool.
- That node marks the transaction as new and schedules announcements or relays to a subset of its peers.
- Receiving peers validate the transaction independently and, if they accept it, add it to their own mempools.
- Each of those peers then repeats the process, gradually spreading the transaction across their respective peer sets.
- At every hop, local policies, rate limits, and temporary issues can slow, filter, or stop further propagation.
Why propagation is slow, uneven, and lossy
Propagation is bounded by ordinary networking limits. Nodes are distributed across the world, so messages incur physical latency; a transaction cannot reach distant regions faster than packets can traverse the internet. Bandwidth limits and congestion mean nodes cannot relay every transaction to every peer immediately.
Nodes also cap the number of peers they connect to and prioritize certain message types. Under load, a node may delay or drop transaction announcements to preserve resources for blocks and essential protocol traffic. Anti-spam and denial-of-service protections further restrict how quickly and how often nodes relay unconfirmed transactions.
Together, these constraints make propagation slow relative to the idealized “instant broadcast” picture, uneven across regions and peer groups, and lossy in the sense that some transactions are delayed, deprioritized, or never forwarded beyond a small neighborhood of nodes.
- Geography: long-distance network links add latency, so distant nodes learn about a transaction later.
- Peer selection: each node has a limited, changing peer set, so some parts of the network are only weakly connected.
- Filtering: nodes may drop low-fee or suspicious transactions early, preventing them from spreading widely.
- Back-pressure: when bandwidth or CPU is constrained, nodes throttle or defer transaction relays.
- Temporary outages: node restarts, peer disconnects, and routing issues interrupt propagation paths.
Why transactions can disappear
A transaction can leave a node’s mempool for many ordinary reasons. The most obvious is success: once the node sees the transaction confirmed in a block, it removes the now-redundant mempool entry. Less obvious are cases where the transaction is evicted, replaced, or never stored in the first place.
If the mempool reaches its configured size limit, the node typically evicts lower-priority transactions, often based on fee rate or age, to make room for newer or more valuable ones. Replacement rules allow a conflicting transaction with higher effective fee to displace an older one that spends the same inputs, so the original may simply vanish from mempools that adopt the replacement.
Some transactions never enter the mempool at all because they fail validation or violate local policy, for example due to malformed data, insufficient fees, or exceeding per-transaction limits. Node restarts can also clear mempool contents unless the software explicitly persists them, so a transaction that was once visible may disappear from a particular node after a reboot even though it still exists elsewhere.
- Eviction by fee or age: when space is scarce, nodes drop older or lower-fee transactions to admit new ones.
- Validation failure: malformed, double-spending, or otherwise invalid transactions are rejected and never stored.
- Replacement: a newer transaction spending the same inputs with higher effective fee can displace the older one.
- Node restart: unless persisted, mempool contents are cleared when a node stops and restarts.
- Incomplete propagation: some nodes never receive a transaction due to network issues or upstream filtering.
Vignette: The vanishing low-fee transaction
Imagine a period when many users are sending transactions and mempools across the network are near capacity. A user submits a low-fee transaction that reaches a few nearby nodes and is briefly stored in their mempools. Explorers connected to those nodes show the transaction as pending.
As more higher-fee transactions arrive, some nodes hit their mempool size limit and begin evicting the lowest-fee entries. On those nodes, the low-fee transaction is removed to make room, even though it has not been confirmed. Other nodes with more space or different thresholds may still keep it.
Later, the user creates a replacement transaction spending the same inputs with a higher effective fee. That replacement reaches several block-producing nodes quickly and is accepted into their mempools, while many of them have already forgotten the original. From the network’s perspective, the original transaction quietly disappears from most mempools, and the replacement becomes the version that is likely to be included.
Visibility vs inclusion: what mempools do not guarantee
Seeing a transaction in any mempool means only that at least one node currently stores a valid, unconfirmed copy of it. It does not imply that most nodes know about it, that block producers have seen it, or that it will be selected soon. Mempool visibility is a local observation, not a network-wide guarantee.
A stronger condition is when a transaction has propagated to most block-producing nodes and sits in their mempools. Even then, inclusion is not assured: producers still apply their own selection logic, typically prioritizing higher-fee or otherwise preferred transactions.
Inclusion in a block is a separate event governed by block-construction rules and consensus, not by mempool state. A transaction can be visible in many mempools and still be delayed, replaced, or never included; conversely, a transaction can be included in a block even if some nodes never saw it in their mempools before the block arrived.
- Broadcast: the transaction is handed to one or a few nodes to start gossip; this is an action, not proof of network-wide delivery.
- Received: a specific node has accepted the transaction into its mempool; this is observable only from that node’s perspective.
- Seen by producers: block-producing nodes have the transaction in their mempools; this is inferred, not directly observable in most systems.
- Included: the transaction appears in a valid block on the canonical chain; this is the first durable, consensus-level record.
What mempools guarantee — and what they don’t
Mempools provide useful signals about short-term network behavior, but they are not part of the protocol’s hard guarantees. Consensus rules specify which blocks and transactions are valid on-chain; they do not require nodes to store, relay, or prioritize unconfirmed transactions in any particular way.
It is therefore important to distinguish properties that follow from node implementation and configuration from properties that are actually guaranteed. The table below summarizes several common assumptions and clarifies whether they are guarantees or heuristics.
Key facts
Local retention
Guarantee (conditional): a node keeps a transaction in its mempool until it is confirmed or until local policy rules trigger removal (eviction, replacement, restart).
Validation rules
Guarantee: a node only accepts transactions into its mempool that satisfy consensus-level validity checks and its configured policy checks.
Global visibility
Non-guarantee: no rule ensures that every valid transaction reaches every node or any specific fraction of the network.
Inclusion timing
Non-guarantee: mempool presence does not specify when, or even whether, a transaction will be included in a block.
Ordering
Non-guarantee: the relative position of transactions in a mempool does not determine their final ordering in blocks.
Uniform content
Non-guarantee: different nodes may have different mempool contents at all times due to connectivity and policy differences.
UX uncertainty as a system property
User-facing uncertainty around pending transactions is not only a user-interface issue; it is a direct consequence of local mempools and gossip-based propagation. Because each service or node has its own mempool, two data sources can legitimately disagree about whether a transaction exists or how “crowded” the network appears.
Propagation delays mean some observers see a transaction almost immediately while others see it only after several hops, if at all. Eviction and replacement cause transactions to appear, disappear, and reappear under new parameters, which looks unstable from the outside but follows consistent local rules.
This variability is inherent to decentralized systems that avoid a single coordinating server. Any interface that reports mempool state is presenting a snapshot of one or a few nodes’ local views, which are necessarily partial and subject to change until transactions are actually confirmed on-chain.
Pro Tip:Treat mempool data as a hint about current network conditions, not as a commitment about inclusion or timing. Short-term disagreement between explorers, nodes, and services is normal because each one is sampling a different local view.
Where mempools fit in the transaction lifecycle
The mempool occupies a middle stage in a transaction’s lifecycle. First, a transaction is created and handed to at least one node. If it passes validation and policy checks, that node inserts it into its mempool and begins gossiping it to peers.
As the transaction propagates, it may enter many other mempools, be evicted from some, or be replaced by a higher-fee variant. During this phase, the transaction is unconfirmed and subject to all the uncertainty described earlier.
Eventually, a block producer may select the transaction from its local mempool and include it in a block, or the transaction may be effectively abandoned if it is never selected and gradually disappears from mempools. The mempool is therefore a transient holding area, not a final destination: transactions either progress from it into blocks or fall out of it over time.
- Transaction creation: data is constructed and sent to one or more entry nodes (mempool not yet involved).
- Initial acceptance: an entry node validates the transaction and, if acceptable, adds it to its local mempool.
- Propagation: the transaction gossips across peers, entering and leaving various nodes’ mempools.
- Selection: block-producing nodes consider transactions from their local mempools when assembling candidate blocks.
- Confirmation or abandonment: once included in a block, the transaction leaves mempools; otherwise it may be evicted or forgotten.
The mempool mental model
The most robust way to think about mempools is as many independent, ephemeral queues at the edges of the network, not as one shared global buffer. Each node maintains its own set of candidate transactions, populated by whatever has reached it through gossip and passed its local rules.
Gossip-based propagation spreads transactions gradually and imperfectly, so awareness is always partial and time-dependent. Transactions can appear, disappear, and be replaced in these local queues without any on-chain trace until they are actually included in a block.
This contrasts sharply with the “single global queue” misconception, where visibility implies universal knowledge and eventual inclusion. In reality, visibility is local and temporary, and inclusion is a separate consensus event that happens elsewhere, based on the mempool contents of specific block-producing nodes at specific times.
- Mempool contents are local, temporary views of unconfirmed transactions, not shared global state.
- Gossip is best-effort: broadcast starts propagation but does not ensure universal delivery.
- Transactions can be evicted, replaced, or forgotten from mempools without ever reaching the chain.
- Inclusion happens in block construction, using the mempools of specific producers at specific times.
- Mempool visibility is a hint about possibilities, not a guarantee about outcomes.