Cluster mempool
The cluster mempool is a redesign of Bitcoin Core's unconfirmed transaction pool that groups transactions into connected components (clusters) and orders them by linearized chunk feerate. It replaced ancestor-and-descendant limits with cluster limits. Bitcoin Core 31.0 shipped the design as the mempool implementation. The change is policy and mining-algorithm internal structure, not a consensus change. It is related to but distinct from the broader topic of the mempool.
Prior mempool model
The pre-cluster mempool tracked, for each transaction, its unconfirmed ancestors and descendants. Mining used ancestor feerate as a proxy for whether a transaction would be selected soon. Replacement policy used that proxy plus absolute-fee and count caps. The proxy is inaccurate for graphs with several fee-payers, which led to pinning and to block templates that left fees on the table. Child-pays-for-parent carve-out was a special case that allowed Lightning a second child; it is incompatible with a strict cluster size limit. Suhas Daftuar and others proposed bounding each connected component so that an exact linearization (an ordering of the cluster into monotonically nonincreasing feerate chunks) is computable. Incentive compatibility of a replacement then reduces to comparing feerate diagrams.
Clusters and linearization
Two transactions are in the same cluster if they are linked by any chain of unconfirmed parent/child edges. Bitcoin Core 31.0 defaults to at most 64 transactions and 101 kB virtual size per cluster. Those limits can be changed with debug arguments. There are no separate ancestor or descendant count limits. Within a cluster, a linearization algorithm produces a sequence of chunks: subsets that a miner would include together. Transactions are scored by the feerate of their chunk. That score is used for selecting transactions into block templates, evicting transactions when the mempool reaches its size limit, announcing transactions to peers, and deciding whether a replacement or a package improves the mempool. RPCs getmempoolcluster and getmempoolfeeratediagram expose cluster membership, chunk grouping, and the mempool-wide feerate diagram.
Child-pays-for-parent carve-out is removed. Protocols that needed it are expected to use TRUC (1-parent-1-child, sibling eviction) or to stay within cluster limits. One-parent-one-child package relay can accept a parent below minrelaytxfee, including zero fee, for both TRUC and non-TRUC packages, with the restriction that extra unconfirmed parents of the child must already be in the mempool. Cluster mempool does not by itself prevent all pinning. Absolute-fee pinning and replacement-count pinning still require topology restrictions or other rules for the worst adversarial cases. TRUC remains useful after cluster mempool for that reason. Related replacement policies include Replace by fee and Full RBF.
Bitcoin Core 31.0 is the first release in which the mempool is the cluster mempool. Mining software that consumes Core's template RPCs inherits the new ordering. Other node implementations may retain ancestor/descendant mempools. Wallets do not need a new transaction format, but Lightning and vault protocols that depended on carve-out need a TRUC migration before operators upgrade those nodes. Fee market forecasting remains covered under Fee estimation.
Linearization aims to produce an ordering a miner would actually prefer under chunk feerate, not merely under ancestor feerate. When two replacements compete, comparing feerate diagrams asks whether the proposed mempool would confirm more fee sooner across the relevant feerate range. That comparison is tractable only because each cluster is bounded. Unbounded graphs made exact incentive checks too expensive for relay.
Deployment
Wallet authors still build ordinary transactions. The practical constraint is to avoid attaching many unconfirmed parents or siblings that would merge clusters past the 64-transaction or 101 kBvB limits. TRUC packages stay inside a two-transaction cluster by construction. Mining RPCs continue to return block templates. Internally those templates are assembled from chunk scores rather than from the older ancestor-score heuristic. Mining templates built from chunk feerate can include packages that ancestor-score ranking would have deferred. Fee estimators that still assume ancestor buckets may need updates as cluster linearization becomes the default selection model.