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 reliability: accurate and reliable fee estimation and transaction confirmation times
- Second layer security: reliable and accurate execution of second layer protocols’ on-chain enforcement transactions
The current behavior of the mempool does not fully align with the reality of mining incentives, which creates blind spots that can be problematic for second layer security by creating uncertainty as to whether a transaction will make it to a miner, as well as pressure for non-public broadcasting channels to miners, potentially worsening the first problem.
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 being enforced on-chain.
Replacement per the existing behavior becomes unpredictable depending on the shape and size of the web of transactions yours is caught in. In a simple fee-bumping situation this can fail to propagate and replace a transaction, even when mining the replacement would be better for a miner.
In the context of second layer protocols, the current logic allows participants to potentially get necessary ancestor transactions evicted from the mempool, or make it not possible for another participant to submit a necessary child transaction to the mempool under the current rules because of child transactions the malicious participant created, or the eviction of necessary ancestor transactions.
All of these problems are the result of these inconsistent inclusion and eviction rankings and the incentive misalignments they create. Having a single global ranking would fix these issues, but globally reordering the entire mempool for every new transaction is impractical.
It’s All Just A Graph
Transactions that depend on each other are a graph, or a directed series of “paths.” When a transaction spends outputs created by another in the past, it is linked with that past transaction. When it additionally spends outputs created by a second past transaction, it links both of the historical transactions together.
When unconfirmed, chains of transactions like this must have the earlier transactions confirmed first for the later ones to be valid. After all, you can’t spend outputs that haven’t been created yet.
This is an important concept for understanding the mempool, it is explicitly ordered directionally.
It’s all just a graph.
Chunks Make Clusters Make Mempools
In cluster mempool, the concept of a cluster is a group of unconfirmed transactions that are directly related to each other, i.e. spending outputs created by others in the cluster or vice versa. This becomes a fundamental unit of the new mempool architecture. Analyzing and ordering the entire mempool is an impractical task, but analyzing and ordering clusters is a much more manageable one.
Each cluster is broken down into chunks, small sets of transactions from the cluster, which are then sorted in order of highest feerate per byte to lowest, respecting the directional dependencies. So for instance, let’s say from highest to lowest feerate the chunks in cluster (A) are: [A,D], [B,E], [C,F], [G, J], and last [I, H].
This allows pre-sorting all of these chunks and clusters, and more efficient sorting of the whole mempool in the process.
Miners can now simply grab the highest feerate chunks from every cluster and put them into their template, if there is still room they can go down to the next highest feerate chunks, continuing until the block is roughly full and just needs to figure out the last few transactions it can fit. This is roughly the optimal block template construction method assuming access to all available transactions.
When nodes’ mempools get full, they can simply grab the lowest feerate chunks from every cluster, and start evicting those from their mempool until it is not over the configured limit. If that was not enough, it moves on to the next lowest feerate chunks, and so on, until it is within its mempool limits. Done this way it removes strange edge cases out of alignment with mining incentives.
Replacement logic is also drastically simplified. Compare cluster (A) to cluster (B) where transaction K has replaced G, I, J, and H. The only criteria that needs to be met is the new chunk [K] must have a higher chunk feerate than [G, J] and [I, H], [K] must pay more in total fees than [G, J, I, H], and K cannot go over an upper limit of how many transactions it is replacing.
In a cluster paradigm all of these different uses are in alignment with each other.
The New Mempool
This new architecture allows us to simplify transaction group limits, removing previous limitations on how many unconfirmed ancestors a transaction in the mempool can have and replacing them with a global cluster limit of 64 transactions and 101 kvB per cluster.
This limit is necessary in order to keep the computational cost of pre-sorting the clusters and their chunks low enough to be practical for nodes to perform on a constant basis.
This is the real key insight of cluster mempool. By keeping the chunks and clusters relatively small, you simultaneously make the construction of an optimal block template cheap, simplify transaction replacement logic (fee-bumping) and therefore improve second layer security, and fix eviction logic, all at once.
No more expensive and slow on the fly computation for template building, or unpredictable behavior in fee-bumping. By fixing the misalignment of incentives in how the mempool was managing transaction organization in different situations, the mempool functions better for everyone.
Cluster mempool is a project that has been years-long in the making, and will make a material impact on ensuring profitable block templates are open to all miners, that second layer protocols have sound and predictable mempool behaviors to build on, and that Bitcoin can continue functioning as a decentralized monetary system.
For those interesting in diving deeper into the nitty gritty of how cluster mempool is implemented and works under the hood, 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 your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
[1] https://github.com/bitcoin/bitcoin/issues/27677
[2] https://github.com/bitcoin/bitcoin/pull/33629
