Cluster Mempool: How Bitcoin Core's Biggest Refactor Fixes Fee Estimation

Bitcoin Core 31.0, released on April 19, 2026, shipped the most significant architectural change to Bitcoin's transaction management in over a decade. The cluster mempool redesign replaces the legacy system for organizing, sorting, and evicting unconfirmed transactions with a unified framework built around transaction clusters and optimal linearization. The result: more accurate fee estimation, better block templates for miners, and stronger guarantees for replace-by-fee and child-pays-for-parent workflows.

For anyone building on Bitcoin, whether wallets, exchanges, or Layer 2 protocols, understanding this change matters. It affects how your transactions propagate, how fees are estimated, and how replacements are evaluated by every node on the network.

What Was Wrong With the Legacy Mempool

Bitcoin's mempool is the holding area where unconfirmed transactions wait to be included in a block. Every full node maintains its own mempool, and the logic governing which transactions to accept, which to evict when the pool is full, and which to include in a block template has been one of the most complex subsystems in Bitcoin Core.

The legacy mempool, used in Bitcoin Core through version 30.x, tracked transactions using two separate and conflicting ranking systems: ancestor feerate and descendant feerate. Each served a different operational purpose, and the tension between them created a cascade of problems.

Ancestor Feerate for Mining

When constructing a block template, Bitcoin Core selected transactions by highest ancestor feerate first. A transaction's ancestor feerate is calculated by summing the fees and sizes of the transaction itself plus all of its unconfirmed parents (ancestors). This approach attempts to find transactions that, together with their dependencies, offer the highest fee-per-byte to a miner.

Descendant Feerate for Eviction

When the mempool was full and needed to shed transactions, Bitcoin Core evicted by lowest descendant feerate. A transaction's descendant feerate accounts for itself plus all child transactions that depend on it. The logic: if a transaction has high-fee children, evicting it would also force the removal of those children, so the descendant feerate captures the total revenue at risk.

The Fundamental Mismatch

These two orderings do not produce consistent results. The mining algorithm and the eviction algorithm were using different approximations of the same underlying question: “how valuable is this transaction to a miner?” The consequence was that the eviction logic could remove transactions that the mining algorithm would have selected first. In the worst case, the very best transaction in the mempool (by mining priority) could be the first one evicted.

The core contradiction: Bitcoin Core's legacy mempool used one ordering to decide what to mine and a different ordering to decide what to discard. These orderings could directly contradict each other, meaning a node could evict exactly the transactions a miner would most want to include.

Ancestor and Descendant Limits

To keep computation tractable, the legacy mempool imposed hard limits: a maximum of 25 ancestor transactions and 25 descendant transactions per transaction, with a 101 kvB size cap in each direction. These limits existed because recalculating ancestor and descendant sets is expensive, and unbounded chains would make mempool operations too slow.

But the 25-transaction limit created its own problems. Because many Bitcoin transactions pay multiple parties (including change outputs), the descendant slots are shared between all recipients. A malicious party could exploit this by attaching enough child transactions to exhaust the descendant limit, preventing legitimate recipients from using CPFP to fee-bump their transaction. This attack vector, known as transaction pinning, was a persistent threat to Lightning channels and other protocols that rely on timely transaction confirmation.

How Cluster Mempool Works

The cluster mempool redesign, developed primarily by Suhas Daftuar and Pieter Wuille, replaces the dual-ordering system with a single, consistent framework based on three concepts: clusters, linearizations, and chunks.

Clusters

A cluster is a maximal set of transactions connected through spending relationships. If transaction A creates an output that transaction B spends, they belong to the same cluster. If transaction C spends an output from B, all three form one cluster. Clusters capture the complete dependency graph: every transaction that could affect the mining priority of any other transaction in the group.

Bitcoin Core 31.0 enforces new policy limits on clusters: a maximum of 64 transactions and 101 kvB of virtual size per cluster. These limits replace the old per-transaction ancestor and descendant limits, moving the constraint from individual transaction topology to the connected component as a whole.

Linearization

Once transactions are grouped into clusters, each cluster is linearized: its transactions are arranged in an optimal order for mining. The linearization algorithm determines the sequence in which a miner should include the cluster's transactions to maximize fee revenue, while respecting the constraint that parents must be included before children.

This is a computationally hard problem in the general case. Wuille spent months in 2025 evaluating three approaches: a simple candidate-set search, a linear-programming-based spanning-forest algorithm, and a min-cut-based method. Early that year, researcher Stefan Richter discovered that a 1989 paper on the maximum-ratio closure problem could be applied to cluster linearization, providing a theoretical foundation that had existed in computer science for decades but never been connected to Bitcoin.

Benchmarks showed the spanning-forest approach was far more efficient than the simple search, and it was selected for implementation. The 64-transaction cluster limit keeps the linearization problem tractable: sorting is done once when a cluster changes, and the result is cached until the next modification.

Chunks

A linearization divides a cluster into chunks: contiguous groups of transactions in the linearized order. Each chunk has a single feerate, and the chunk feerates decrease monotonically from the first chunk to the last. A chunk represents the atomic unit for all mempool operations: the smallest set of transactions that should be evaluated together.

The key insight is that chunks never cross cluster boundaries. Every mempool operation (mining, eviction, replacement evaluation) can be expressed purely in terms of chunks, and all operations use the same ordering. This eliminates the fundamental mismatch of the legacy system.

Unified Operations: One Ordering for Everything

With clusters linearized into chunks, every mempool operation becomes a simple comparison of chunk feerates:

Block construction simply iterates through chunks in descending feerate order until the block is full. Eviction removes chunks from the bottom of the ordering. The same data structure serves both purposes, which means the mining and eviction orderings are now guaranteed to be consistent.

Better Replace-by-Fee

The legacy RBF rules could not properly determine whether a proposed replacement made the mempool better or worse for miners. The old system used per-transaction feerate comparisons as a proxy, but these approximations were a major source of pinning problems and fee-bumping failures.

Bitcoin Core 31.0 introduces feerate diagram policy for RBF validation. A replacement is only accepted if the resulting mempool's feerate diagram is strictly better than before the replacement. The feerate diagram is a curve plotting cumulative virtual size against cumulative fees across all chunks: if the new diagram is everywhere at or above the old one (and strictly above somewhere), the replacement is accepted.

This eliminates all known cases where a replacement could make the mempool worse off. Under the old rules, a replacement could evict high-fee transactions from the mempool while nominally meeting the feerate threshold, leaving miners with less total revenue. The feerate diagram policy makes this impossible.

What feerate diagram policy means in practice: A replacement transaction must make the mempool strictly better for miners across all possible future block positions. This is a stronger guarantee than the legacy rule, which only checked whether the replacement had a higher individual feerate than the transaction it replaced.

Implications for CPFP and Package Relay

Child-pays-for-parent has always been a critical fee-bumping mechanism, especially for protocols where one party cannot unilaterally modify a transaction (such as pre-signed commitment transactions in Lightning channels). The legacy mempool's handling of CPFP was complicated by the ancestor and descendant limits, leading to the CPFP carve-out exception.

CPFP Carve-Out Is Gone

The CPFP carve-out was a special rule that allowed one additional child transaction to bypass the descendant limit under specific conditions. It was designed for two-party protocols like Lightning, where each party needs to be able to attach a fee-bumping child to a shared commitment transaction. But the carve-out only supported two parties and introduced edge-case complexity.

Bitcoin Core 31.0 removes the CPFP carve-out entirely. The new cluster limits (64 transactions per cluster) provide enough room that the carve-out is no longer necessary. For smart contracting use cases that require similar guarantees, TRUC transactions (BIP 431) and sibling eviction now serve as the designated anti-pinning mechanism.

Package Relay

Package relay allows nodes to evaluate groups of related transactions together rather than individually. This is essential for CPFP: a low-fee parent transaction that would be rejected on its own can be accepted when submitted alongside a high-fee child. The cluster mempool makes package evaluation natural, since clusters already group related transactions and linearization computes the optimal ordering.

With the cluster mempool in place, package relay rules can reference chunk feerates directly. A package that creates a new cluster (or extends an existing one) is evaluated by its impact on the overall feerate diagram. This is a substantial improvement over the legacy approach, which relied on ad hoc rules for package acceptance.

What This Means for Layer 2 Protocols

Layer 2 protocols like Lightning and Spark depend on the ability to get transactions confirmed within specific time windows. Lightning penalty transactions, channel force-closes, and HTLC timeouts all require reliable propagation through the mempool to miners. The legacy mempool's inconsistencies created real security risks for these protocols.

Reduced Pinning Risk

Transaction pinning attacks exploit mempool policy to prevent a victim's transaction from being confirmed. In the legacy mempool, an attacker could submit a low-fee, high-weight descendant of a shared transaction to exhaust the descendant limit, blocking the victim from fee-bumping. With cluster mempool, the replacement rules are based on feerate diagram improvement rather than individual feerate comparisons, making pinning attacks significantly harder to execute.

TRUC transactions (formerly called v3 transactions) provide an additional layer of protection. TRUC transactions restrict topology to one parent and one child, with the child limited to 1,000 vB. This gives Layer 2 protocols a dedicated, pin-resistant transaction type for time-sensitive operations like commitment transaction broadcasting.

More Predictable Fee Bumping

When a Lightning node needs to force-close a channel during a fee spike, it must estimate the correct fee and potentially bump it via RBF or CPFP. Under the legacy system, fee bumps could fail silently: a replacement that met the nominal feerate threshold might still be rejected due to inconsistencies in how the mempool evaluated transaction packages. The cluster mempool's unified chunk ordering makes the rules deterministic. If your replacement improves the feerate diagram, it will be accepted.

The Development Timeline

The cluster mempool project spanned three years of research, design, and incremental implementation across dozens of pull requests in the Bitcoin Core repository. The tracking issue (#30289) listed approximately 46 pull requests across four development layers.

New RPC Tools for Developers

Bitcoin Core 31.0 exposes the cluster mempool internals through new RPC commands, giving wallet developers and infrastructure operators direct visibility into how their transactions are being evaluated:

• getmempoolcluster: returns all transactions in the same cluster as a given txid, along with their linearized ordering and chunk groupings
• getmempoolfeeratediagram: returns the entire mempool's feerate diagram, showing how cumulative fees relate to cumulative virtual size across all chunks
• getmempoolentry: now includes chunk size and chunk fees in addition to the legacy fields, allowing developers to see exactly which chunk a transaction belongs to and at what feerate it is expected to be mined

These tools allow wallets and services to make fee decisions based on the same data structures the node uses internally, rather than relying on external estimators or stale heuristics.

Cluster Limits vs. Legacy Limits

The shift from ancestor/descendant limits to cluster limits is not just a renaming. It changes the shape of the constraint:

The 64-transaction cluster limit is larger than the old 25-transaction ancestor or descendant limit, but it applies to the entire connected component rather than per-transaction chains. In practice, most organic transaction patterns fit comfortably within the cluster limits. The main impact is on adversarial scenarios where attackers deliberately build deep chains to exploit limit asymmetries.

Impact on Fee Estimation

Fee estimation has historically been one of the weakest parts of the Bitcoin user experience. Legacy estimators tracked historical confirmation rates: observing how quickly transactions at various feerates were included in blocks and extrapolating to predict the feerate needed for a target confirmation time. This approach is inherently backward-looking and struggles during rapid fee market transitions.

The cluster mempool enables a fundamentally different approach. Because the mempool is now a fully ordered set of chunks, a node can directly compute how many blocks of pending transactions exist at any given feerate threshold. Rather than asking “historically, what feerate confirmed within 3 blocks,” a node can answer “right now, how much block space is occupied by chunks with a higher feerate than yours?”

This mempool-based fee estimation is more responsive to current conditions and eliminates the lag inherent in historical models. While Bitcoin Core 31.0 does not yet ship a mempool-based fee estimator as the default, the getmempoolfeeratediagram RPC provides the raw data for wallets and services to build their own. Future Bitcoin Core releases are expected to incorporate mempool-aware estimation directly.

The Linearization Algorithm

The mathematical core of the cluster mempool is the linearization algorithm. Given a cluster of transactions with fees, sizes, and dependency relationships, the algorithm must produce an ordering that maximizes the feerate of the first chunk (the transactions a miner should include first), subject to the constraint that parents appear before children.

This is equivalent to the maximum-ratio closure problem, a problem studied in operations research since the late 1980s. The connection was identified by Stefan Richter in early 2025, drawing on a 1989 paper that predated Bitcoin by two decades. Wuille implemented and benchmarked three algorithms:

• A simple candidate-set search that enumerates possible transaction subsets
• A spanning-forest algorithm based on linear programming, adapted from the closure-problem literature
• A min-cut-based approach using network flow techniques

The spanning-forest algorithm proved both more efficient and more practical. It was merged into Bitcoin Core in December 2025 (PR #32545), replacing the initial candidate-set search. The algorithm's cost model controls how much CPU time is spent linearizing large clusters that cannot be solved optimally within a reasonable budget, falling back to a good-enough approximation when necessary.

Implications for Spark and On-Chain Settlement

Spark, like all Bitcoin Layer 2 protocols, ultimately relies on L1 transactions for settlement. Users exit from Spark to Bitcoin's base layer by broadcasting pre-signed exit transactions, and these transactions must compete in the mempool like any other.

The cluster mempool improves this interaction in several ways. More accurate fee estimation means Spark wallets and service providers can set fees that are neither wastefully high nor dangerously low during congestion. The feerate diagram RBF policy ensures that fee bumps on exit transactions behave predictably: if a bump improves the mempool for miners, it will be accepted. And the removal of the old descendant-limit pinning vector reduces the risk that an adversary could interfere with time-sensitive settlement operations.

For developers building on Spark's SDK, the new getmempoolcluster and getmempoolfeeratediagram RPCs provide tools to build more intelligent fee strategies for on-chain operations. Understanding where your transaction sits in the chunk ordering gives direct insight into expected confirmation time.

What Comes Next

The cluster mempool in Bitcoin Core 31.0 is a foundation, not a finished product. Several follow-on improvements are expected in future releases:

• Mempool-based fee estimation as the default, replacing the historical confirmation-rate model
• Further refinement of the spanning-forest linearization algorithm for better performance on edge-case cluster topologies
• Enhanced package relay policies that fully leverage chunk-aware evaluation for multi-transaction submissions
• Potential adjustments to cluster size limits based on real-world network data from the 31.0 deployment

The cluster mempool also unlocks the possibility of smarter block template construction for miners. Rather than rebuilding templates from scratch, miners can detect when a mempool update improves the top of the feerate diagram and selectively update only the affected portion of the template. This reduces computational overhead for mining operations and supports decentralized mining by lowering the hardware requirements for template construction.

For a deeper look at how Bitcoin's fee market has evolved and what drives fee spikes, see our analysis of Bitcoin fee market dynamics and the economics of mempool congestion.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.