Addressing Core Challenges: Cluster Mempool and Incremental Problem Solving

Cluster Mempool¹ represents a significant redesign of the mempool’s transaction organization and sorting mechanisms, conceived and executed by Suhas Daftuar and Pieter Wuille. This innovative design seeks to streamline the architecture, align transaction sorting mechanisms with miner incentives, and enhance security for second-layer protocols. It was integrated into Bitcoin Core in PR #33629² on November 25, 2025.

The mempool comprises a large collection of pending transactions that a node must manage for various purposes, including fee estimation, transaction replacement validation, and block construction for miners.

Such diverse objectives for a single node function necessitate effective organization. Up until version 30.0 of Bitcoin Core, the mempool organizes transactions in two principal manners: by the combined fee rate of a transaction and its descendants (descendant fee rate), and by the combined fee rate of a transaction and its ancestors (ancestor fee rate). This dual organization assists in determining which transactions to evict when the mempool reaches capacity and which transactions to prioritize when constructing a new block template.

How Is My Mempool Managed?

When miners evaluate the inclusion of a transaction in their blocks, their nodes examine both the transaction and any necessary ancestor transactions that must be confirmed beforehand. They assess the average fee rate per byte across all of these transactions collectively, based on the total fees paid. If this collective group fits within the block size limit and offers competitive fees, it is included in the subsequent block.

In instances where a node’s mempool is at capacity, the node evaluates each transaction alongside its children, opting to evict the transaction along with its descendants if the mempool is already filled with transactions (and their descendants) that exhibit a higher fee rate.

The accompanying graph illustrates transactions with their respective fee rates indicated in parentheses (ancestor fee rate, descendant fee rate). For example, a miner evaluating transaction E would likely choose to include it in the next block, as it is a small transaction with a high fee and a single small ancestor. Conversely, if a node’s mempool were filling up, it may discard transaction A, which has two larger children paying a lower relative fee.

The juxtaposition of these two rankings creates inconsistencies. The mempool must reliably reflect the transactions miners are likely to mine, and users should be assured that their local mempool can accurately predict miner behavior.

The performance of the mempool in this manner is critical for several reasons:

Mining decentralization: ensuring all miners access the most profitable set of transactions.
User reliability: providing accurate fee estimations and transaction confirmation timelines.
Second layer security: guaranteeing reliable execution of on-chain enforcement transactions for second-layer protocols.

The existing behavior of the mempool does not fully reflect the realities of mining incentives, resulting in blind spots that could be detrimental to second-layer security by introducing uncertainty about whether transactions will be mined. This scenario may lead to increased reliance on non-public broadcasting channels, potentially exacerbating the initial issue.

This situation becomes particularly problematic when replacing unconfirmed transactions, either to incentivize quicker inclusion by miners or as part of an on-chain enforced second-layer protocol.

The predictability of transaction replacement becomes compromised based on the complexity of the transaction web. In straightforward fee-bumping scenarios, transactions may fail to propagate and replace an existing transaction, even if doing so would be advantageous for miners.

In the context of second-layer protocols, the present logic might allow participants to inadvertently evict necessary ancestor transactions or hinder others from posting essential child transactions due to malicious actions or the eviction of crucial ancestor transactions.

These complications stem from the misalignment arising from inconsistent inclusion and eviction rankings. Establishing a singular global ranking could resolve these issues, but globally reordering the entire mempool for each new transaction proves impractical.

It’s All Just A Graph

The Core Issue: Cluster Mempool, Problems Are Easier In Chunks 2

The interdependencies of transactions can be visualized as a directed graph, where transactions spend outputs created by earlier transactions, linking them together. Unconfirmed chains of such transactions must have their preceding transactions confirmed before later ones can be deemed valid, as outputs cannot be spent until they are created.

This concept is crucial for understanding the directional order of the mempool.

It is simply a matter of visualizing a graph.

Chunks Make Clusters Make Mempools

The Core Issue: Cluster Mempool, Problems Are Easier In Chunks 3

Within the framework of cluster mempool, a cluster refers to a set of unconfirmed transactions that are interrelated, either by spending outputs from the same group or vice versa. This establishes a fundamental unit for the new mempool architecture. While analyzing and ordering the complete mempool may be cumbersome, focusing on clusters presents a more feasible approach.

Each cluster can be subdivided into chunks, smaller segments of transactions sorted by fee rate from highest to lowest, while maintaining directional dependencies. For instance, a cluster might comprise chunks arranged as follows from highest to lowest fee rate: [A,D], [B,E], [C,F], [G,J], and lastly [I,H].

This methodology allows for the pre-sorting of chunks and clusters, thus enhancing the overall efficiency of the mempool sorting process.

Miners can now efficiently select the highest fee rate chunks from each cluster and incorporate them into their block template. If space permits, they can continue to include chunks with progressively lower fee rates until the block is optimized. This strategy aligns with the objective of constructing an optimal block template based on all available transactions.

When a node’s mempool reaches capacity, it can systematically evict the lowest fee rate chunks from each cluster until compliance with the configured limit is achieved. If this proves insufficient, eviction will continue with subsequent lowest fee rate chunks, ensuring the process aligns with mining incentives.

The replacement logic is thereby simplified. For example, in comparing cluster (A) with cluster (B), where transaction K replaces G, I, J, and H, the only requirements are that the new chunk [K] must exhibit a higher chunk fee rate relative to [G,J] and [I,H] and additionally, [K] must offer greater total fees than the transactions being replaced, without exceeding the defined limit of transactions it can replace.

In this clustered paradigm, the diverse functional requirements coalesce with one another into a unified approach.

The New Mempool

The newly established architecture allows for the simplification of transaction group limits by replacing previous constraints regarding unconfirmed ancestors with a universal cluster limit of 64 transactions and 101 kvB per cluster. This limitation is vital for maintaining manageable computational costs associated with the pre-sorting of clusters and their chunks, ensuring practical node performance.

This insight lies at the heart of the cluster mempool design. By maintaining smaller chunks and clusters, the optimal block template construction is made less resource-intensive, while simultaneously streamlining transaction replacement logic and enhancing second-layer security as well as optimizing eviction processes, thus benefiting all stakeholders.

The cluster mempool initiative represents years of dedicated effort and is poised to significantly impact the accessibility of profitable block templates for all miners, ensuring that second-layer protocols can depend on a reliable mempool behavior, and that Bitcoin continues to operate as a decentralized monetary system.

For those interested in further exploring the intricacies of cluster mempool implementation and functioning, the following Delving Bitcoin threads provide valuable insights:

High Level Implementation Overview (With Design Rationale): https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393

How Cluster Mempool Fee Rate Diagrams Work: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553