The Mempool

Between the moment you broadcast a transaction and the moment it lands in a block, it lives in a waiting room called the mempool (memory pool). It is tempting to picture one giant shared waiting room for the whole network. That picture is wrong, and unlearning it is the single most important idea on this page: there is no global mempool. Every node keeps its own set of valid, unconfirmed transactions, and those sets differ.

What a mempool actually is

A node’s mempool is the collection of transactions it has received, validated as consensus-valid (good signatures, no double-spend against the current UTXO set, correct scripts), and is willing to hold and relay — but which are not yet confirmed in a block. It is RAM-resident working state, not part of the blockchain. When a transaction is mined, the node removes it from the mempool; when the node restarts, the mempool can be rebuilt from peers.

Think of it as each node’s personal answer to: “Of all the unconfirmed transactions I’ve heard about, which ones are legitimate candidates for the next block?”

Admission policy: standardness, not just validity

Recall the two-rulebook distinction from transaction & block propagation. Consensus validity is necessary to enter the mempool, but it isn’t sufficient. To be admitted (and relayed), a transaction must also pass the node’s policy filter:

• Minimum fee rate — a transaction paying below the node’s floor (in sats/vByte) is rejected to prevent free-loading and spam.
• Dust limit — outputs too tiny to be economically spendable are discouraged.
• Standardness — only well-known script forms are relayed; bizarre or oversized scripts are filtered (a miner could still mine them, but the network won’t gossip them).
• Ancestor/descendant limits — caps on how many unconfirmed transactions can chain together, to bound the work of re-evaluating dependent transactions.

   incoming tx
       │
       ▼
  consensus-valid? ──no──► reject (it can never be in a block)
       │ yes
       ▼
  passes policy?   ──no──► don't relay / don't admit
   (min fee, dust,          (it COULD be mined, but this node
    standardness, limits)    won't carry it)
       │ yes
       ▼
  add to mempool, relay onward (inv)

The key takeaway: policy is local and conservative. Different nodes can run slightly different policy, which is one reason their mempools diverge.

Why mempools differ — there is no single global mempool

Several forces guarantee that no two nodes hold identical mempools:

• Timing & connectivity — a transaction reaches different nodes at different times; some haven’t heard it yet.
• Policy differences — a transaction that’s above one node’s fee floor may be below another’s.
• Conflicts & replacements — with RBF/CPFP, one node may hold the original transaction while another already holds the replacement that conflicts with it.
• Eviction — under memory pressure, nodes drop different transactions (see below).

This matters intensely for zero-confirmation thinking: because mempools disagree, “it’s in the mempool” is not a guarantee that miners have it, that it will be mined, or that a conflicting version isn’t circulating elsewhere. Only a confirmed transaction is agreed upon network-wide.

Never treat the mempool as consensus

The mempool is best-effort, local, and mutable. Two honest nodes can permanently disagree about it and both be correct. The network only truly agrees on the chain of confirmed blocks — the mempool is merely each node’s private guess about what the next block might contain.

Eviction and the size cap

A mempool isn’t allowed to grow without bound — that would let an attacker exhaust every node’s RAM for free. Each node enforces a maximum mempool size (e.g. ~300 MB by default). When it fills:

• Transactions are evicted lowest-fee-rate first — the least economically attractive go.
• Eviction raises the effective minimum fee to enter: once the pool is full of, say, 10 sat/vByte transactions, anything below that simply won’t fit. This dynamic floor is itself a spam defense.

So during congestion, low-fee transactions may silently vanish from mempools network-wide and need to be re-broadcast or fee-bumped later.

Fee-rate ordering feeds the fee market

A rational miner wants to maximize the fees in the limited space (weight) of a block. So the mempool is effectively a priority queue ordered by fee rate (sats per vByte), not by absolute fee or by arrival time.

   Mempool sorted by fee rate (sats/vByte), highest first:

   120 ████████  ┐
    95 ██████    │  ← a miner fills the next block from the TOP
    60 ████      │     until the block's weight limit is reached
    30 ██        ┘
     8 █            ← these wait (or get evicted if the pool fills)

This ordering is the raw input to the fee market: when demand for block space exceeds supply, the fee rate needed to sit “above the cut line” rises, and users bid against each other. It’s also why RBF and CPFP exist — they’re the mechanisms a user employs to move up this queue after broadcasting.

Run a node, watch the mempool

The clearest way to internalize “there is no global mempool” is to compare your own node’s mempool against a public explorer’s and watch them differ in real time. See running a node.

The thread

How does this help untrusting strangers agree on one ledger? The mempool is where the network’s future is contested but not yet settled. By having each node independently validate and rank candidate transactions — rather than trusting a central queue — Bitcoin keeps even the staging area trust-minimized. Disagreement here is expected and harmless: the protocol funnels all these private, divergent guesses into a single point of agreement only when a miner commits a block, and every node re-checks that block for itself. Consensus is reached not by agreeing on the waiting room, but by agreeing on what leaves it.

Check your understanding

1. Why is it inaccurate to speak of “the” mempool? Name three reasons two honest nodes’ mempools differ.
2. Distinguish consensus validity from policy/standardness in the context of mempool admission. Give a case where a transaction passes one but not the other.
3. When a mempool hits its size cap, which transactions are evicted, and how does that create a dynamic minimum fee?
4. Why is the mempool ordered by fee rate (sats/vByte) rather than total fee? How does this feed the fee market?
5. Why is “it’s in the mempool” a weak guarantee for a merchant accepting a payment?