Pending transactions are often described as sitting in the mempool, as though one existed. Every node maintains its own, and the differences between them explain several otherwise puzzling behaviors.
Propagation is peer to peer
A transaction enters the network at one node and spreads by being relayed to peers, each of which validates it before passing it on.
Spread is fast but not instantaneous, and it is uneven. Well-connected nodes see transactions sooner than those with few peers or slower links.
At any moment the network therefore holds many partially overlapping views rather than one shared queue.
Acceptance policies are local
Consensus rules define what is valid in a block. Mempool policy is separate and defines what a node is willing to hold and relay, and operators can configure it.
Minimum fee rates, limits on how many unconfirmed transactions may chain together and caps on total mempool size all vary between deployments.
A node whose mempool is full evicts the lowest-fee entries, meaning a cheap transaction can be present on some nodes and forgotten by others.
Conflicting versions coexist
Replacement rules let a sender broadcast a new version of a transaction with a higher fee, and nodes that accept replacement discard the original.
Nodes with replacement disabled keep the first version they received, so two incompatible transactions circulate simultaneously in different parts of the network.
Only one can confirm. Which one does depends on the policy of whichever node builds the block that includes it.
Private relay routes around the pool
Some transactions never enter public mempools at all, being sent directly to block builders through private channels.
The motivation is protection from having a strategy copied or front-run by parties watching public pending transactions.
The consequence is that a transaction can confirm without any explorer having shown it as pending, which looks like an anomaly and is routine.
What this means for fee estimation
Fee estimators infer required rates from what a node currently sees, so estimates differ between wallets connected to different infrastructure.
During rapid congestion the divergence widens, because the pool composition changes faster than estimation windows can track.
Stuck transactions frequently result from an estimate built on an incomplete view rather than from an error, which is why replacement and fee bumping exist as standard tools.
Wallets connected to a single provider inherit that provider's view completely. Comparing estimates across independent sources is the practical way to tell a genuine fee spike from a local artifact of one node's pool.