Mempool Eviction

What Is Mempool Eviction?

Mempool eviction is the process by which a Bitcoin node removes unconfirmed transactions from its mempool when available memory is full. Every Bitcoin node maintains its own mempool as a waiting area for unconfirmed transactions. Since this pool has a finite size, the node must decide which transactions to keep and which to discard during periods of high demand.

Eviction acts as a market-clearing mechanism for block space. When network activity surges, the mempool fills with more transactions than can fit in upcoming blocks. Nodes prioritize transactions that pay higher fees per unit of data, discarding those that fall below the economic threshold. This creates a direct link between network congestion and the minimum fee required for a transaction to survive in the mempool.

How It Works

Bitcoin Core sets a default maximum mempool size of 300 MB via the -maxmempool configuration option. When a new transaction would push the mempool beyond this limit, the node's TrimToSize function activates and begins removing transactions.

The Eviction Algorithm

The eviction process follows a specific sequence:

1. A new transaction arrives that would cause the mempool to exceed its size limit
2. The node identifies the transaction whose "descendant package" (the transaction itself plus all in-mempool descendants) has the lowest combined feerate
3. The entire descendant package is removed from the mempool
4. The node raises its dynamic mempoolminfee to the evicted package's feerate plus the incrementalrelayfee
5. Any incoming transaction with a feerate below this new threshold is rejected outright

This approach uses descendant feerate for eviction, which is the inverse of how miners select transactions for blocks (by ancestor feerate). The logic is intentional: a low-fee parent transaction with a high-fee CPFP child will have a high descendant feerate, protecting it from eviction.

Key Configuration Parameters

Three fee-related settings in Bitcoin Core interact with the eviction process:

The mempoolminfee can only rise above minrelaytxfee, never fall below it. During heavy congestion, this dynamic floor becomes the binding constraint that determines whether a transaction survives.

Two additional parameters govern mempool behavior: -maxmempool sets the size limit (default 300 MB, minimum 5 MB), and -mempoolexpiry removes transactions older than the specified duration regardless of feerate (default 336 hours, or 14 days).

Monitoring the Mempool

Node operators can observe the current eviction threshold using the RPC interface:

# Check the current mempool state and dynamic minimum fee
bitcoin-cli getmempoolinfo

# Example output during congestion:
{
  "loaded": true,
  "size": 148532,
  "bytes": 299948210,
  "usage": 300000000,
  "total_fee": 12.45,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00012500,
  "minrelaytxfee": 0.00000100
}

# The mempoolminfee has risen far above minrelaytxfee,
# indicating active eviction and high congestion.

Congestion Events and Real-World Impact

Several major congestion events in 2023 and 2024 caused widespread mempool evictions, highlighting the practical consequences of this mechanism. For a detailed analysis of fee dynamics during these events, see Bitcoin Mempool Congestion Economics.

May 2023: BRC-20 Minting Frenzy

The launch of BRC-20 tokens on Bitcoin caused the mempool to swell beyond 400,000 unconfirmed transactions. Daily transactions hit a record of over 682,000 on May 8, with inscriptions accounting for roughly 32% of all transaction fees. Nodes running default 300 MB mempools actively evicted low-feerate transactions, and total fees per block briefly exceeded the 6.25 BTC block subsidy for the first time since 2017.

April 2024: Runes Protocol Launch

The Runes protocol launched at the halving block 840,000, triggering the most extreme fee spike in Bitcoin's history. Fee rates soared above 2,750 sat/vB, with average transaction fees reaching $128. Block 840,000 carried 37.67 BTC in fees (over $2.4 million), making it the most expensive block ever mined. Runes transactions consumed over 90% of all network fees within hours. Any transaction paying less than several hundred sat/vB was rapidly evicted from default-sized mempools.

Handling Evicted Transactions

Eviction removes a transaction from one node's mempool, but it does not invalidate the transaction. The transaction remains valid and can be resubmitted. Wallets and applications have several strategies for dealing with evictions:

Rebroadcasting

The simplest approach is to rebroadcast the original transaction. If congestion has subsided and the mempoolminfee has decayed below the transaction's feerate, the transaction will be accepted again. Many wallet implementations handle rebroadcasting automatically.

RBF Fee Bumping

Replace-by-Fee allows the sender to create a new transaction spending the same inputs but with a higher fee. Since Bitcoin Core v29.0, full RBF is enabled unconditionally: any unconfirmed transaction can be replaced with a higher-fee version, regardless of signaling. This makes RBF the preferred method for recovering from eviction during sustained congestion.

# Bump the fee on a stuck/evicted transaction using Bitcoin Core wallet
bitcoin-cli bumpfee <txid>

# Or create a manual replacement with higher fee
bitcoin-cli send '[{"<address>": <amount>}]' null "unset" null \
  '{"fee_rate": 50, "inputs": [{"txid": "<original_txid>", "vout": 0}]}'

For a comprehensive guide on fee bumping strategies, see Bitcoin Fee Bumping: RBF and CPFP Guide.

CPFP (Child Pays for Parent)

If the original transaction has already been received (it has an output belonging to the recipient), the recipient can create a high-fee child transaction spending that output. This raises the descendant feerate of the parent, making it more attractive to miners and protecting it from eviction. CPFP is particularly useful when the sender cannot replace the transaction via RBF.

Cluster Mempool: The Next Evolution

Bitcoin Core's cluster mempool redesign (merged in late 2025 for the v31.0 release) fundamentally changes how eviction works. Instead of evaluating transactions by descendant feerate, the new system organizes transactions into clusters and linearizes them into "chunks" ordered by optimal feerate.

Under cluster mempool, eviction removes the lowest-feerate chunk, while block construction selects the highest-feerate chunk. This creates perfect symmetry between what miners want to include and what nodes evict: the transactions most likely to be evicted are exactly those least likely to be mined next. The old ancestor/descendant limits (25 ancestors, 25 descendants, 101 kvB per chain) are replaced by cluster limits of 64 transactions and 101 kB virtual size per cluster.

For a deeper exploration of this redesign, see Bitcoin Cluster Mempool Explained.

Why It Matters

Mempool eviction directly affects the reliability of Bitcoin payments. A transaction that gets evicted may appear to "disappear" from the sender's perspective, creating confusion and uncertainty. For merchants, exchanges, and payment processors, understanding eviction is essential for building robust transaction monitoring systems.

Layer 2 protocols like the Lightning Network and Spark address the eviction problem by moving most transactions off-chain entirely. Off-chain payments settle instantly without competing for block space, making them immune to mempool congestion and eviction dynamics. When on-chain settlement is required (for channel opens, closes, or force closures), protocols use techniques like anchor outputs, v3 transactions, and package relay to ensure time-sensitive transactions can be fee-bumped above the eviction threshold.

Risks and Considerations

Silent Transaction Failure

Unlike a transaction that is explicitly rejected, an evicted transaction simply vanishes from the mempool without notification. Wallets that do not monitor for eviction may display a pending transaction indefinitely, even though no node is holding it. Users should monitor fee estimates and set appropriate feerates when the fee market is active.

Non-Uniform Mempools

Each node maintains its own mempool independently. A transaction may be evicted from one node's mempool while still present in another's, depending on each node's configuration, the order of transaction arrival, and local maxmempool settings. This means there is no single, network-wide view of which transactions have been evicted. Mempool policy is a local decision, not a consensus rule.

Time-Sensitive Transaction Risk

Transactions with time constraints face the greatest risk from eviction. Lightning Network penalty transactions, HTLC timeout claims, and other timelocked outputs must confirm before their deadlines expire. If these transactions are evicted during a congestion spike, the sender may lose funds. This is why Lightning implementations use fee bumping mechanisms and why watchtowers monitor for on-chain events.

Dust Consolidation Vulnerability

Transactions that consolidate many small dust outputs tend to be large in size but low in urgency. During congestion events, these consolidation transactions are among the first to be evicted because their feerate must cover a larger transaction size. Node operators should consolidate UTXOs during low-fee periods, as discussed in Bitcoin UTXO Management Strategies.

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.