Cluster memory pool1 is a complete reworking of how mempool handles transaction organization and classification, conceptualized and implemented by Suhas Daftuar and Pieter Wuille. The design aims to simplify the overall architecture, better align transaction classification logic with miners’ incentives, and improve the security of second-layer protocols. Merged with Bitcoin Core in PR #336292 on November 25, 2025.
The mempool is a giant pool of pending transactions that your node must keep track of for several reasons: fee estimation, transaction replacement validation, and block construction if you are a miner.
These are many different goals for a single function of your node to service. Bitcoin Core through version 30.0 organizes the mempool in two different ways to assist in these functions, both from the relative point of view of any given transaction: forward-facing combined fee of the transaction and its children (descendant fee), and backward-facing combined fee of the transaction and its parents (ancestral fee).
These are used to decide which transactions to evict from your mempool when it is full and which to include first when building a new block template.
How is my Mempool managed?
When a miner decides whether to include a transaction in their block, their node looks at that transaction and any ancestors that must be confirmed first to be valid in a block, and looks at the average fee per byte of all of them together considering the individual fees they paid as a whole. If that group of transactions fits the block size limit and outperforms others in fees, it is included in the next block. This is done for each transaction.
When your node decides which transactions to evict from its mempool when it is full, it analyzes each transaction and the children it has, evicting the transaction and all its children if the mempool is already full with transactions (and their descendants) that pay a higher fee.
Look at the example transaction chart above, the fees are shown as such in parentheses (ancestor fee, descendant fee). A miner observing transaction E would likely include it in the next block, a small transaction that pays 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 relatively low fee, and would probably evict it or not accept it and keep it if it just received it.
These two classifications or arrangements are completely at odds with each other. The mempool must reliably propagate what the miners will mine, and users must be confident that their local mempool accurately predicts what the miners will mine.
Working the mempool in this way is important for:
- Mining decentralization: achieve all miners the most profitable set of transactions
- User Reliability: Accurate and reliable fee estimation and transaction confirmation times
- Second layer security: reliable and accurate execution of on-chain compliance transactions of second layer protocols
Current mempool behavior does not fully align with the reality of mining incentives, creating blind spots that can be problematic for second layer security by creating uncertainty about whether a transaction will reach a miner, as well as pressure for non-public broadcast channels to reach miners, potentially making the first problem worse.
This is especially problematic when it comes to replacing unconfirmed transactions, either simply to incentivize miners to include a replacement sooner or as part of a second-layer protocol applied on-chain.
Replacing based on existing behavior becomes unpredictable depending on the shape and size of the transaction network yours is caught in. In a simple fee increase situation, this may not propagate or replace a transaction, even when mining the replacement would be better for a miner.
In the context of second layer protocols, current logic allows participants to cause necessary ancestor transactions to be evicted from the mempool, or to make it impossible for another participant to send a necessary child transaction to the mempool under the current rules due to child transactions that the malicious participant created, or the eviction of necessary ancestor transactions.
All of these problems are the result of these inconsistent inclusion and eviction classifications and the incentive mismatches they create. Having a single global sort would solve these problems, but globally reordering the entire mempool for each new transaction is not practical.
Everything is just a graph
Transactions that depend on each other are a graph or a directed series of “paths.” When one transaction spends products created by another in the past, it is linked to that past transaction. When you also spend products created by a second past transaction, you link both historical transactions.
When not confirmed, transaction chains like this has to make earlier transactions commit first so later ones are valid. After all, you can’t spend results that haven’t been created yet.
This is an important concept to understand the mempool, it is explicitly ordered directionally.
Everything is just a graph.
Shards create clusters and create mempools
In the mempool cluster, the concept of a cluster is a group of unconfirmed transactions that are directly related to each other, that is, spending products created by others in the group or vice versa. This becomes a fundamental unit of the new mempool architecture. Parsing and sorting the entire mempool is an impractical task, but parsing and sorting clusters is much more manageable.
Each group is divided into piecessmall sets of transactions in the cluster, which are then ordered from the highest rate per byte to the lowest, respecting directional dependencies. So, for example, let’s say that, from largest to smallest, the fragments in group (A) are: [A,D], [B,E], [C,F], [G, J]and last [I, H].
This allows for pre-sorting all of these chunks and groups, and more efficient sorting of the entire mempool in the process.
Miners can now simply take the highest fee shards from each pool and place them into their template; If there is still room, they can move on to the next higher-fee shards, continuing until the block is roughly full and only needs to determine the last few transactions it can fit. This is approximately the optimal method of building block templates, assuming you have access to all available transactions.
When the nodes’ mempools fill up, they can simply take the lowest rate shards from each cluster and start evicting them from their mempool until it does not exceed the configured limit. If that’s not enough, it moves on to the next lower rate chunks, and so on, until it’s within the limits of its mempool. Done this way, strange edge cases that are not aligned with mining incentives are eliminated.
The substitution logic is also drastically simplified. Compare group (A) with group (B) where transaction K replaced G, I, J and H. The only criterion that must be met is the new fragment [K] should have a higher shard rate than [G, J] and [I, H], [K] must pay more in total fees than [G, J, I, H]and K cannot exceed the upper limit of how many transactions it is replacing.
In a cluster paradigm, all of these different uses are aligned with each other.
The new group of members
This new architecture allows us to simplify transaction pool limits, removing previous limitations on how many uncommitted ancestors a transaction can have in the mempool and replacing them with a global cluster limit of 64 transactions and 101 kvB per cluster.
This limit is necessary to keep the computational cost of pre-sorting clusters and their fragments low enough to be practical for nodes to operate consistently.
This is the real key idea of cluster mempool. By keeping shards and clusters relatively small, you simultaneously make it cheaper to build an optimal block template, simplify transaction replacement (fee increase) logic, and thus improve second-layer security and fix eviction logic, all at once.
No more costly and time-consuming on-the-fly calculations for templating, or unpredictable rate increase behavior. By correcting the misalignment of incentives in the way the mempool managed the organization of transactions in different situations, the mempool works better for everyone.
Cluster mempool is a project that has been years in the making and will have a material impact by ensuring that profitable block templates are open to all miners, that second layer protocols have robust and predictable mempool behaviors to build on, and that Bitcoin can continue to function as a decentralized monetary system.
For those interested in delving into the nitty-gritty of how cluster mempool is implemented and works, here are two Delving Bitcoin threads you can read:
High-level implementation overview (with design rationale): https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393
How Cluster Mempool Feerate diagrams work: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553
Don’t miss the opportunity to be an owner The central question – With articles written by many core developers explaining the projects they work on themselves!
This article is the editor’s letter that appears in the latest print edition of Bitcoin magazine, The Core Issue. We share it here as an early look at the ideas explored throughout the issue.
[1] https://github.com/bitcoin/bitcoin/issues/27677
[2] https://github.com/bitcoin/bitcoin/pull/33629
