Why mempools feel confusing at first
Mempools often become visible only when something feels off: your wallet shows a transaction as pending, but an explorer does not show it yet. Or one node sees the transaction while another insists it has never seen it. This guide explains why those mismatches are normal - and how to interpret "pending" without panic.
- If a transaction is visible in my wallet, it must be accepted.
- All nodes and services see the same set of pending transactions at the same time.
One key idea: mempools are local, not global
A blockchain is a shared history of confirmed transactions that all honest nodes eventually agree on. Once a transaction is in a block and that block is accepted, every node’s copy of the chain includes it. A mempool is different. Every node maintains its own local mempool: a private list of transactions that this node has heard about and considers candidates for future blocks. There is no central, authoritative mempool that everyone reads from. The blockchain is shared; mempools are not. A mempool is more like a best-effort preview of what might be confirmed next, not part of the agreed, consensus state.
Pro Tip:"Pending" describes what one node currently sees, not what the network has agreed on.
How transaction propagation actually works (high-level)
When a transaction is created, it is first sent to one node in the network. That node checks it and, if it looks acceptable, broadcasts it to the peers it is connected to. Those peers then repeat the process: they add the transaction to their own mempools and forward it on to their peers. Over time, the transaction can spread outward like ripples from a stone dropped in water. Because this is a step-by-step relay, different nodes hear about the same transaction at different times, and some nodes may never receive it at all.
Why different nodes can see different things
Once mempools are seen as local lists plus gradual propagation, it becomes natural that they do not always match. Different nodes can have different information at different times. These differences usually come from three broad sources: how far a transaction has propagated, what local policies each node applies, and how each node manages limited mempool space during busy periods. All of these are normal parts of how a peer-to-peer network operates, even though they can make pending views look inconsistent from the outside.
Key facts
Partial propagation
The transaction has only reached some parts of the network so far, or some nodes never received it because of delays or dropped messages. In practice, one explorer or node may show the transaction while another never lists it at all.
Local policy
Each node can set its own rules for what to keep in its mempool, such as minimum fees, overall size limits, or spam filters. A valid transaction might be ignored or not stored by one node, so its tools will not show it, even though other nodes do.
Mempool eviction
When the mempool is crowded, a node may remove lower-priority transactions to make room for new ones. A transaction can vanish from that node’s pending list during congestion, even though it remains valid and might still be held by other nodes.
- These differences are normal outcomes of local state, not inconsistencies in the blockchain itself.
What explorers and wallets are actually showing
Block explorers typically run their own node or a small cluster of nodes and show the mempool view of those specific machines. What appears as "pending" there is simply what their nodes currently hold. Many wallets do not run a full node themselves. Instead, they connect to one or a few backend nodes and ask those nodes what they see in their mempools. Tools reflect the mempool of the nodes they are connected to.
What this means for “pending” status
When a tool marks a transaction as “pending”, it usually means: this specific node currently has the transaction in its mempool, and the transaction has not yet appeared in a block. It is a description of what that node sees right now. Pending does not guarantee that the transaction will be included in any future block. It also does not mean that every other node or explorer can see the same transaction at the same time. A transaction can be pending on one node and completely invisible on another that never received it or chose not to store it. The shared, final truth only appears when the transaction is included in a confirmed block on the blockchain.
Key facts
Pending means
This node has seen the transaction and is currently storing it in its mempool, but it is not yet in a block.
Pending does NOT mean: guaranteed inclusion
A pending transaction can still be replaced, dropped, or never selected for a block.
Pending does NOT mean: global visibility
Other nodes and tools might not see the transaction at all, even while one node shows it as pending.
What different mempools do NOT mean
- Different mempool views do not automatically mean the network is broken; they are a normal result of local lists and partial propagation.
- Seeing a transaction in one place and not another does not mean funds are lost, because ownership is defined by the blockchain, not mempools.
- Mempool differences by themselves do not prove censorship; they can arise from fees, policies, or simple non-delivery.
Pro Tip:When mempool views disagree, the most reliable question is: does this transaction eventually appear in a block on the blockchain. That final record determines balances, not who showed it as pending along the way. Differences between mempools are about who currently sees the transaction, not about who owns the funds. Treat inconsistent pending information as different camera angles first, and only worry about deeper issues if the on-chain outcome looks wrong.
A simple mental model to remember
Imagine a group of people in a building, where each room has its own small bulletin board. People write notes about planned actions and pin them to the board in their room, and sometimes they walk to nearby rooms and copy notes they find interesting. These room boards are like local mempools: each one has overlapping but slightly different notes, depending on who has visited and what they decided to keep. The official record, such as a single notice board in the lobby where final decisions are posted, is like the blockchain. Until a note is copied onto the central lobby board, different rooms can have different versions of what might happen. Once it is on the central board, everyone who checks it sees the same final information.
Calm closing and TL;DR
In a peer-to-peer network where each node keeps its own mempool, inconsistent pending views across wallets, explorers, and nodes are normal rather than exceptional. They reflect different local perspectives, not different definitions of who owns what. The only place where everyone ultimately agrees is the blockchain itself, when a transaction appears in a confirmed block. Keeping this mental model in mind can make it much less stressful when a transaction seems to be missing, moves between tools, or sits in a pending state for a while. A simple way to think about it is: many local previews, one shared final record.
TL;DR
- Each node maintains its own local mempool, so mempools are not global or shared by default.
- Different nodes, wallets, and explorers can show different pending states at the same time.
- “Pending” is a local observation that a node currently stores a transaction, not a guarantee it will be included.
- Only confirmed blocks on the blockchain create shared, final truth about whether a transaction happened.