Mempool
Each Bitcoin node's waiting area for unconfirmed transactions, where transactions compete for block inclusion based on fee rates.
Key Takeaways
- The mempool is each Bitcoin node's local holding area for valid, unconfirmed transactions: there is no single global mempool. Every node maintains its own version based on its configuration, connectivity, and replace-by-fee policy settings.
- Transactions compete for block space through fee rates measured in sat/vB: when demand exceeds the roughly 1 million vB per block limit, miners prioritize higher-paying transactions, creating a dynamic auction for confirmation.
- Layer 2 protocols like Lightning and Spark bypass the mempool entirely for routine payments: only channel open and close transactions touch the on-chain mempool, while individual payments settle instantly off-chain.
What Is the Mempool?
The mempool (short for "memory pool") is the set of valid, unconfirmed transactions that a Bitcoin node holds in RAM while waiting for miners to include them in a block. When a wallet broadcasts a transaction, nearby nodes validate it against consensus rules and local policy. If it passes both checks, the node adds it to its local mempool and relays it to connected peers. This propagation continues until most of the network has seen the transaction.
A common misconception is that "the mempool" is a single shared data structure. In reality, every Bitcoin node maintains its own independent mempool. Two nodes can have different contents based on propagation delays, differing policy configurations, or connectivity differences. When people refer to "the mempool," they typically mean the aggregate view across well-connected nodes, which monitoring tools like mempool.space approximate.
The mempool serves as the gateway between transaction broadcast and permanent inclusion in the blockchain. Understanding how it works is essential for estimating fees, diagnosing stuck transactions, and grasping the economics of Bitcoin's fee market.
How It Works
When a transaction arrives at a node, it goes through a two-stage validation process before entering the mempool:
- Consensus validation: the node verifies signatures, checks that inputs reference valid unspent UTXOs, confirms the transaction does not create coins from nothing, and ensures scripts execute correctly
- Policy validation: the node checks the transaction against local mempool policies, including minimum fee rate, size limits, and standardness rules
- If both pass, the transaction enters the local mempool and is relayed to peers
- The transaction waits in the mempool until a miner includes it in a block or it expires
Miners construct blocks by selecting transactions from their mempool, typically choosing those with the highest fee rates first. Because each block is limited to 4,000,000 weight units (roughly 1,000,000 virtual bytes), not every waiting transaction can fit. This scarcity of block space creates the competitive fee market.
Default Mempool Policies
Bitcoin Core nodes enforce several configurable policies that govern which transactions enter the mempool:
| Parameter | Default Value | Config Flag |
|---|---|---|
| Maximum mempool size | 300 MB | -maxmempool |
| Minimum relay fee | 1 sat/vB (lowered to 0.1 sat/vB in v29.1) | -minrelaytxfee |
| Transaction expiry | 336 hours (14 days) | -mempoolexpiry |
| Max ancestors/descendants | 25 transactions, 101,000 vB total | -limitancestorcount |
When the mempool fills to its 300 MB capacity, the node evicts transactions with the lowest descendant fee rates and raises a dynamic minimum fee floor. This floor gradually decays as congestion eases.
Fee Rate Dynamics
The mempool functions as a real-time auction for block space. During low-traffic periods, transactions paying 1 sat/vB confirm in the next block. During congestion, fee rates can spike above 500 sat/vB or higher. The April 2024 halving block saw a median fee rate of 1,805 sat/vB as Runes protocol transactions flooded the network.
Users have two primary mechanisms to manage fees for unconfirmed transactions:
- Replace-by-fee (RBF): broadcast a replacement transaction paying a higher fee. As of Bitcoin Core 28.0, full RBF is enabled by default, meaning any unconfirmed transaction can be replaced regardless of BIP125 signaling
- Child-pays-for-parent (CPFP): spend an output from the stuck transaction in a new child transaction with a high fee. Miners evaluate the combined ancestor fee rate and include both transactions if profitable
Fee Estimation
Bitcoin Core's estimatesmartfee RPC analyzes recent confirmation history to recommend fee rates for a target number of blocks. It uses exponential decay across three time horizons:
# Estimate fee rate for confirmation within 6 blocks
bitcoin-cli estimatesmartfee 6
# Response (example during moderate congestion)
{
"feerate": 0.00012500, # BTC/kvB
"blocks": 6
}
# Equivalent to ~12.5 sat/vB
# Conservative mode (higher estimate, safer)
bitcoin-cli estimatesmartfee 6 "conservative"Tools like mempool.space take a different approach: they analyze the current mempool state directly, projecting which transactions will fit into upcoming blocks. This provides more responsive real-time estimates compared to Core's historical approach.
SegWit and Virtual Bytes
Mempool sizing and fee rates are calculated in virtual bytes (vbytes), not raw bytes. The SegWit upgrade introduced a weight system that gives witness data (signatures) a 75% discount:
# Weight calculation
weight = (non_witness_bytes × 4) + (witness_bytes × 1)
vbytes = weight / 4
# Example: SegWit transaction
# 116 non-witness bytes + 110 witness bytes
weight = (116 × 4) + (110 × 1) = 574 WU
vbytes = 574 / 4 = 143.5 vB
# Fee calculation
fee_rate = total_fee_sats / vbytes
# 2,000 sats / 143.5 vB ≈ 13.9 sat/vBThis discount means SegWit transactions take up less effective space in both the mempool and blocks, increasing the network's practical throughput to roughly 1.7 to 2.0 MB per block compared to the pre-SegWit 1 MB limit.
Use Cases
Fee Optimization
Monitoring mempool congestion allows users and wallets to time transactions for lower fees. During periods of low activity (weekends, overnight hours in major markets), the mempool often clears to near-empty, and transactions paying 1 sat/vB confirm quickly. Batching multiple payments into a single transaction during these windows can reduce costs significantly.
Transaction Monitoring
Services that accept on-chain Bitcoin payments monitor the mempool to detect incoming transactions before they confirm. A transaction appearing in well-connected nodes' mempools provides a reasonable (though not guaranteed) signal that payment has been initiated. For low-value transactions, some merchants accept zero-confirmation payments based on mempool visibility, though this carries double-spend risk, especially under full RBF.
Mining Strategy
Miners continuously scan their mempool to construct the most profitable block template. Advanced mining software uses ancestor-aware fee rate sorting: rather than evaluating each transaction in isolation, it considers the combined fee rate of transaction packages (parents and children together). This is what makes CPFP effective.
Protocol Development
Mempool policy is a critical design surface for Bitcoin protocol development. Recent innovations include TRUC transactions (v3 policy) introduced in Bitcoin Core 28.0, which restrict transaction topology to improve the reliability of anchor outputs and Lightning channel closures. Package relay (1P1C) allows parent-child pairs to propagate together, ensuring CPFP works even when the parent alone falls below the mempool minimum fee rate.
Why It Matters
The mempool directly affects every Bitcoin user's experience. When the mempool is congested, on-chain fees rise and confirmation times become unpredictable. This congestion is a primary motivation for Layer 2 scaling solutions.
Lightning Network channels bypass the mempool entirely for routine payments. Only two on-chain transactions touch the mempool per channel lifecycle: the opening transaction and the closing transaction. Everything in between settles instantly off-chain, unaffected by mempool congestion or fee spikes.
Spark extends this concept further. As a Bitcoin Layer 2, Spark enables off-chain transfers of Bitcoin and stablecoins like USDB without any of those transfers entering the mempool. Users benefit from instant settlement and minimal fees regardless of on-chain conditions, while retaining the ability to exit to Layer 1 when needed.
Recent Developments
Bitcoin Core's mempool policy has evolved significantly in recent releases:
- Bitcoin Core 28.0 (October 2024): full RBF enabled by default, TRUC (v3) transaction policy, and 1P1C package relay for more reliable fee bumping
- Bitcoin Core 29.1 (September 2025): default minimum relay fee reduced 90% from 1 sat/vB to 0.1 sat/vB, reflecting Bitcoin's higher price making the old floor unnecessarily expensive for small transactions
- Cluster mempool (in development for v31.0): a fundamental restructuring that groups related transactions into clusters of up to 64 transactions for more accurate eviction ordering and mining optimization
The mempool landscape has also shifted dramatically since early 2025. After the congestion caused by Ordinals, BRC-20, and Runes activity in 2024, the mempool cleared substantially in February 2025. Throughout mid-2025, pending transaction counts have hovered between 3,000 and 30,000, with fees regularly at 1 sat/vB or below. This shift is attributed to growing Layer 2 adoption and reduced retail on-chain activity.
Risks and Considerations
Mempool as an Unreliable Signal
Seeing a transaction in the mempool does not guarantee it will confirm. Under full RBF, any unconfirmed transaction can be replaced by a higher-fee version. Services that rely on unconfirmed transactions for payment finality face double-spend risk. For high-value payments, waiting for at least one block confirmation remains the safest approach.
Fee Estimation Uncertainty
Fee estimation is inherently imperfect. Historical approaches (like Bitcoin Core's) can lag during sudden demand spikes. Real-time approaches (like mempool.space) can overreact to transient congestion. Overpaying wastes money; underpaying risks transactions getting stuck for hours or days. Users should understand that fee estimates are probabilistic, not guarantees.
Mempool Congestion and Denial of Service
Sustained high mempool congestion can make on-chain Bitcoin impractical for small payments. The April 2024 halving block saw individual transaction fees exceeding $100 on average. During these periods, fee sniping incentives also increase, and time-sensitive protocols like Lightning force-closes become more expensive. The 300 MB mempool limit and minimum fee rate provide some protection against spam, but determined attackers with sufficient budget can still congest the network temporarily.
Privacy Implications
Broadcasting a transaction to the mempool reveals information about the sender. Network observers monitoring mempool propagation can correlate transactions with IP addresses. Nodes that first relay a transaction are likely the originator. Bitcoin Core mitigates this with techniques like random relay delays and, as of v27.0, BIP324 encrypted peer-to-peer transport by default.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.