Bitcoin Core tagged v31.0rc2 on GitHub on 2026-03-25, placing the next major release of the network's reference implementation into its second and likely final round of community testing before a target launch in early April 2026. The release candidate carries two headline upgrades — cluster mempool and SwiftSync — that together represent years of engineering work by the protocol's open-source contributors.
The stakes are not abstract. Bitcoin Core is the software that defines standard network behaviour for the overwhelming majority of full nodes. Every design decision embedded in a major release propagates across tens of thousands of independent operators who collectively enforce the rules of the network. That makes a major release candidate a live referendum on years of engineering judgement, and rc2 the moment when the broader developer community stress-tests the final form of that judgement before it ships.
Cluster mempool is the more structurally significant of the two changes. The project, completed in late 2025 and staged for v31.0 according to Bitcoin Optech Newsletter #385, overhauls how Bitcoin Core organises transactions inside the mempool for fee-optimised block building. Developer Pieter Wuille introduced the TxGraph class at the Bitcoin Core PR Review Club — a data structure that strips transactions down to only their weight, fees, and relationships, giving the mempool a clean graph over which to run linearisation algorithms. Wuille published benchmarks in May 2025 comparing three linearisation approaches and found both advanced approaches substantially more efficient than the prior candidate-set search. The practical beneficiaries are immediate: Lightning Network channel force-closes and fee-bumping strategies using Child-Pays-For-Parent and Replace-By-Fee depend on the mempool's ability to correctly evaluate transaction clusters. Poor cluster accounting means mispriced fees; cluster mempool is the structural fix.
SwiftSync is the second headline feature, and its numbers are stark. A sample implementation posted to Delving Bitcoin by Sebastian Falbesoner, based on a proposal by researcher Ruben Somsen, shows a 5.28x speedup in Initial Block Download over Bitcoin Core's default IBD settings — reducing a roughly 41-hour sync to roughly 8 hours, according to Bitcoin Optech Newsletter #349. The mechanism is precise: before syncing, an operator who has already reached a recent block produces a 'hints file' indicating which transaction outputs will remain in the UTXO set at that block. During IBD, outputs not destined for the final UTXO set are excluded from costly chainstate writes; a cryptographic accumulator tracks every created and spent output, and when the node reaches the terminal block, an empty accumulator confirms the hints file was honest. A manipulated file is detected and IBD restarts. The design is trustless by construction. A Rust implementation was announced in September 2025, and SwiftSync PR #34004 is open in the bitcoin/bitcoin repository. Somsen noted an additional synergy: users who download assumeUTXO data at the same terminal block do not need a separate hints file, which could meaningfully simplify the onboarding experience for new node operators.
Ruben Somsen, writing on Delving Bitcoin in April 2025, said: 'SwiftSync speeds up assumeUTXO's background validation, making it a nice addition for users of assumeUTXO.' Bitcoin Optech Newsletter #349, summarising the benchmark thread, reported: 'As of writing, the most recent results posted in the thread show a 5.28x speedup of initial block download (IBD) over Bitcoin Core's default IBD settings, reducing the initial sync time from about 41 hours to about 8 hours.' Fresh comment from Bitcoin Core maintainers on what rc2 resolves relative to rc1 was not available at publication time.
The v31.0 release also removes the '-paytxfee' startup option and the 'settxfee' RPC, both deprecated in v30.0. Those options allowed users to set a static fee rate for wallet transactions — a blunt instrument that could result in systematic overpayment or underpayment relative to actual network conditions. Their removal is a quiet signal about the direction of wallet fee management: the protocol's reference implementation is moving away from static configuration and toward dynamic estimation, precisely the kind of estimation that cluster mempool is designed to make more accurate. The live network context is telling: at the time of this brief, mempool.space showed fees at 1-to-2 satoshis per virtual byte — the fee floor — with network hashrate at 1,005.2 exahashes per second at block 942,566. A low-fee environment makes accurate estimation more consequential, not less, because the margin for error compresses.
For node operators, the immediate signal is to test rc2 on non-production infrastructure and report regressions to the GitHub issue tracker before the final tag. For Lightning developers and wallet builders, cluster mempool's ship date sets the clock for real-world validation of fee-estimation improvements in force-close and CPFP scenarios — the first empirical test of a project that has lived in review and benchmarks for years. The open question of how SwiftSync hints files will be distributed — whether via CDN, torrent, or integration with the codebase itself — carries sovereignty implications that the community has not yet resolved and will need to address before v31.0's onboarding story is complete. Watch the final v31.0 tag on bitcoincore.org and GitHub for the signed release that triggers the upgrade cycle across the network; watch Delving Bitcoin and the bitcoin-core-dev mailing list for rc2 regressions that could shift that timeline; and watch the SwiftSync distribution question, because how a hints file reaches a new node operator will say something durable about where the line sits between convenience and self-reliance in this ecosystem.