Bitcoin Magazine
The Core Issue: Cluster Mempool, Problems Are Easier In Chunks
Cluster Mempool1 is a complete reworking of how the mempool handles organizing and sorting transactions, conceptualized and implemented by Suhas Daftuar and Pieter Wuille. The design aims to simplify the overall architecture, better align transaction sorting logic with miner incentives, and improve security for second layer protocols. It was merged into Bitcoin Core in PR #336292 on November 25, 2025.
The mempool is a giant set of pending transactions that your node has to keep track of for a number of reasons: fee estimation, transaction replacement validation, and block construction if you’re a miner.
This is a lot of different goals for a single function of your node to service. Bitcoin Core up to version 30.0 organizes the mempool in two different ways to help aid in these functions, both from the relative point of view of any given transaction: combined feerate looking forward of the transaction and its children (descendant feerate), and combined feerate looking backwards of the transaction and its parents (ancestor feerate).
These are used to decide which transactions to evict from your mempool when it’s full, and which to include first when constructing a new block template.
How Is My Mempool Managed?
When a miner is deciding whether to include a transaction in their block, their node looks at that transaction, and any ancestors that must be confirmed first for it to be valid in a block, and look at the average feerate per byte across all of them together considering the individual fees they paid as a whole. If that group of transactions fits within the blocksize limit while outcompeting others in fees, it is included in the next block. This is done for every transaction.
When your node is deciding which transactions to evict from its mempool when it is full, it looks at each transaction and any children it has, evicting the transaction and all its children if the mempool is already full with transactions (and their descendants) paying a higher feerate.
Look at the above example graph of transactions, the feerates are shown as such in parentheses (ancestor feerate, descendant feerate). A miner looking at transaction E would likely include it in the next block, a small transaction paying a very high fee with a single small ancestor. However, if a node’s mempool was filling up, it would look at transaction A with two massive children paying a low relative fee, and likely evict it or not accept and keep it if it was just received.
These two rankings, or orderings, are completely at odds with each other. The mempool should reliably propagate what miners will mine, and users should be confident that their local mempool accurately predicts what miners will mine.
The mempool functioning in this way is important for:
Mining decentralization: getting all miners the most profitable set of transactions
User relia
