What is the mempool? Where transactions wait before a block

What is the mempool, exactly?#

When you send a transaction, it does not go straight into the blockchain. Full nodes keep track of unconfirmed transactions that are eligible for the next block, and Bitcoin Core stores them in memory in what it calls the memory pool, or mempool ^[1]. Think of it as a waiting room: valid transactions sit there until a miner picks them up and puts them into a block, at which point they get their first confirmation.

The mempool is useful to everyone, but essential to miners, who build the next block from it ^[1]. The Bitcoin Wiki describes the same flow from the miner’s side: when miners construct new blocks, they fill their candidate blocks with transactions taken from their own node’s mempool ^[3].

Where the mempool sits

Is there one mempool for the whole network?#

No — and this surprises many beginners. The Bitcoin Wiki calls it a common misconception that “the mempool” is one network-wide thing; in reality every node has a different, though probably similar, set of transactions ^[3]. It adds a sharp observation: if every node were guaranteed to hold exactly the same mempool, there would be no need for mining or a blockchain at all ^[3].

Websites that show “the mempool size” are therefore showing their own node’s view. Two such sites can disagree, and both can be correct. Your wallet may also be connected to nodes that have not yet heard of your transaction, or that dropped it.

How does a transaction get into a mempool?#

A node only accepts a transaction it can verify. It must spend outputs that exist and are unspent, carry valid signatures, and pass the node’s policy checks. Policy is the set of rules a node can change at will — such as whether it relays transactions at all — as opposed to consensus rules that everyone must share ^[3]. One policy setting is the minimum relay fee: the lowest fee a transaction must pay for a node to relay it, and there is no single network-wide value because each node chooses its own ^[4]. In Bitcoin Core’s current source code (its main development branch), the default is the number 100 ^[5], which Bitcoin Core reads as satoshis per 1,000 virtual bytes (vB, the size unit fees are measured in) ^[6]. That works out to 0.1 sat/vB.

1. Valid by consensus rules

   Inputs exist and are unspent, signatures check out, outputs do not exceed inputs.

2. Standard by policy

   Bitcoin Core only relays and mines transactions that pass its standardness tests ^[2], such as a maximum standard weight of 400,000 units ^[5].

3. Pays enough

   The fee rate must clear the node’s own minimum relay fee.

4. Fits the chain limits

   Bitcoin Core by default limits how many unconfirmed ancestors and descendants a transaction can have (25 each) ^[5].

How do miners choose which transactions to include?#

Block space is limited — Bitcoin blocks are capped at 4 million weight units ^[7] — so miners pick the most rewarding transactions first. The developer guide explains that transactions are prioritised by their fee per byte, with higher-paying transactions added in sequence until the available space is filled ^[2]. The amount being sent does not matter; size and fee do.

Tx B pays the biggest fee in total, but Tx A pays the most for each unit of block space it uses, so a miner filling a block in fee-rate order includes A first.

Miners can go one step further and look at families of transactions. Child Pays For Parent (CPFP), also called ancestor mining, means selecting transactions based not only on their own fees but also on the fees of their parents and children ^[4]. Bitcoin Optech explains why this works: consensus rules require a parent transaction to appear earlier in the chain than the child that spends it, even inside the same block ^[8]. So a high-fee-rate child gives miners a reason to mine its unconfirmed parent too, and Bitcoin Core calls this ancestor feerate mining when it builds block templates ^[8]. That opens a way to rescue a stuck payment, covered below.

What happens when the mempool fills up?#

Mempools have a size limit and an age limit. In Bitcoin Core’s code, a routine called LimitMempoolSize first expires transactions that have waited longer than the configured expiry time, then trims the pool down to its maximum size ^[9]. The trimming removes the lowest-fee-per-byte transactions first ^[3]. In the current source code, the default expiry is 336 hours and the default maximum is 300 megabytes of memory use ^[10].

Current column: Bitcoin Core’s src/kernel/mempool_options.h, src/policy/policy.h and src/policy/feerate.h on the main development branch, fetched 3 October 2026, so a released version may differ. 0.16 column: the Bitcoin Wiki’s description of that version. Every node operator can change these settings.

Bitcoin Core rounds any fractional satoshi in a fee up to the next whole satoshi ^[6]. A node relaying at this floor does not mean miners will mine your transaction soon: when blocks are full, they still pick higher fee rates first ^[2].

Mempools are also less permanent than the blockchain. Older developer documentation describes the mempool as kept in non-persistent memory and lost when a node shuts down, so never-mined transactions tend to slowly disappear from the network ^[1]; the Bitcoin Wiki notes that newer Bitcoin Core versions save it across restarts ^[3]. Either way, a dropped transaction was never confirmed, so the coins never left your wallet.

How can you unstick a transaction?#

If your fee was too low, you have two common tools, and which one you can use depends on your wallet:

• Replace-by-Fee (RBF). BIP 125 lets a transaction signal that it may be replaced. A replacement must pay at least the original’s absolute fee and also pay for its own size at the node’s minimum relay rate — in the BIP’s example, with a 1 sat/byte minimum, a 500-byte replacement must pay at least 500 sats more than the original ^[11].
• Child Pays For Parent (CPFP). The recipient (or you, via your change output) spends the stuck transaction’s output in a new transaction with a high fee. Miners that select by ancestor fees may then include both to collect it ^[4]. Bitcoin Optech notes that wallets can rely on this as long as a moderate percentage of miners select transactions that way ^[8].
• Wait. If the network quietens down, low-fee transactions often get mined eventually; if not, they may expire from mempools and you can send again.

Does Ethereum have a mempool too?#

Yes. On Ethereum, a transaction is broadcast and added to a transaction pool of other pending transactions ^[12]. ethereum.org describes each execution client adding valid transactions to its local mempool and gossiping them to other nodes, and the block proposer for each slot bundling transactions from its local mempool into the next block ^[13]. Ethereum prices inclusion with gas fees rather than fee per byte; see transaction fees explained.

What mistakes do beginners make here?#

• Checking one mempool website and panicking

  Each site shows its own node’s mempool. If one does not show your transaction, check another or look it up by txid.

• Sending the same payment twice

  If the first transaction later confirms, you will have paid twice. Use RBF or CPFP, or wait for the first to drop, instead of re-sending blindly.

• Judging priority by amount

  A huge payment with a tiny fee rate waits longer than a small payment with a high one. Miners look at fee per unit of size.

• Thinking “stuck” means lost

  An unconfirmed transaction never moved the coins on-chain. Even so, do not treat it as cancelled: someone could rebroadcast it and it could still confirm later.

Frequently asked questions#

The bottom line#

The mempool is not a single queue but thousands of similar waiting rooms, one per node. Each admits transactions by its own policy, and miners pick from theirs by fee rate until the block is full.

Once you see it that way, stuck transactions make sense: they are simply priced below what miners are taking right now. Learn how that price is set in transaction fees explained, then see what happens after selection in blocks and confirmations.

Sources#