Bitcoin Core published release candidate 4 of version 31.0 (v31.0rc4) on April 8, 2026, tagged on the same day as release candidate 3 — a back-to-back cadence that signals the development team is in a final polish sprint before the full v31.0 release, which was scheduled to land in early April. The GitHub repository confirms both rc3 and rc4 were tagged on April 8. Two release candidates in a single day, following an established release schedule that opened translation work on February 6, means the project is either wrapping up unusually fast or working through final-stage issues in quick iterations.
Bitcoin Core sits at the foundation of the entire self-custody stack. Every Lightning node (LND, CLN, LDK), every hardware wallet that communicates with a full node, every self-hosted payment processor, and every institutional custody solution that runs Bitcoin Core as its validation engine relies on the stability of its RPC interface and command-line options. Version 31.0 breaks that stability deliberately. The `-paytxfee` startup option and the `settxfee` RPC command — tools that allowed users to set a static fee rate for all wallet transactions — are not deprecated, not warned about in a final release, not present with a note in the changelog. They are gone. Any software that calls them will fail silently or error. The removal completes a cleanup that began in v30.0, released in October 2025, where these options were first flagged for removal. That was six months of notice. Now the notice period ends.
The technical change is straightforward: users and applications must now specify fee rates per transaction using the `fee_rate` parameter in RPCs like `fundrawtransaction`, `sendtoaddress`, `send`, `sendall`, and `sendmany`. The old way — set it once at startup or via a single RPC call, then fire transactions without re-specifying — is no longer available. This is not an optimization. It is a forced rewrite of any application logic that touched those two commands. The Bitcoin Core team removed them because static fee rates are a poor match for a variable-fee network. Users who set `-paytxfee 1sat/vB` and then leave it for six months will overpay dramatically when mempool pressure rises, or underpay when the network is quiet. The RPC versions let users shoot themselves in the foot without even knowing it. Removing the foot-gun was the goal. The method — making the break clean and non-negotiable — was the choice.
Why now? The network conditions are optimal for a major node upgrade. Mempool.space reports the Bitcoin hashrate at 953.8 exahashes per second and current fees at 1 to 3 satoshis per byte — the fastest/30-minute/1-hour brackets all 1–3 sat/vB. This is a low-fee environment. Node operators restarting their systems for an upgrade will not face a surge in stuck transactions or the pressure to bump fees mid-flight. The block height sits at 944,325, and with v30.0 already shipping six months ago, the ecosystem has had time to patch integrations for the deprecation warnings. The early-April release window was set in February when translations were opened on Transifex — this was not rushed. The two RCs on the same day suggest final fixes rather than architectural issues. The team is executing a planned major release on schedule, during a window when the network can absorb the disruption.
Who wins and who loses? Wallet and node developers who have already patched their code for v30.0's deprecation warnings gain a cleaner, simpler fee API — no legacy branches, no conditional logic to handle both old and new fee paths. They also gain the operational certainty that all Bitcoin Core instances worldwide, once upgraded to v31.0, will enforce dynamic fee estimation. But developers who missed the six-month window, or who maintained older codebases that did not get updated, will face failures. Any wallet still calling `settxfee` on v31.0 will error. Any Lightning node software that has not patched its fee-handling code will fail to open channels or route payments correctly. There will be stragglers — abandoned projects, forks, closed-source wallets — that do not upgrade and silently break on v31.0. The v30.0 release sunset v28.x from receiving updates. The v31.0 release will do the same to v29.x. Node count tracking across versions will reveal how much of the self-custody ecosystem still runs deprecated versions; that number is a proxy for upgrade lag and, by extension, security debt.
Our read: This is a textbook example of the tension between Bitcoin Core's role as a protocol reference implementation and its role as the de facto standard node software for everyone from hardware wallet providers to payment processors. The removal of `-paytxfee` and `settxfee` is technically correct — static fees are a bad idea on a dynamic-fee network — and the six-month notice period was generous. But the execution shows no compromise: the break is hard, the tooling to fix it is available, and the message is unambiguous. Bitcoin Core is saying, in code, that backwards compatibility has a limit. The wallet developer who did not patch in time will fix it or fall behind. This is how mature protocol software works. It also means that self-custody platforms and Lightning implementations need to track Bitcoin Core releases as carefully as they track protocol consensus rules. A major version bump is not a point release. It is an API reset. The smart operators already know this and have test environments running rc4. The ones who discover this on the main-network upgrade will have a smaller window to recover.
Watch four specific signals. First: the v31.0 final release tag on GitHub. With rc4 out and early April as the target, expect the final tag within one to two weeks. Any further delay beyond mid-April signals unexpected test failures or last-minute patches. Second: wallet and Lightning node software changelogs for v31.0 compatibility patches. LND, CLN, and LDK-based wallets should all publish fee-handling updates before v31.0 goes final. If a major implementation is still silent on this by the v31.0 final release, it either does not use those deprecated commands (low risk) or has not tested against v31.0 yet (high risk). Third: the Testing Issue #34840 on GitHub, where the community reports test failures. Watch for repeated errors on specific platforms — Windows with external signing, ARM architectures, or integration tests with common wallet software — that might extend the release cycle. Fourth: BIP-360 and Pay-to-Merkle-Root. The quantum-resistance proposal was documented in February 2026. If any v31.0 PRs include preparatory plumbing for P2MR soft-fork support, that is a signal the project is thinking beyond this release cycle and planning for a major upgrade window. That would be worth a follow-up story on its own.