Bitcoin Core's signed v32.0 final source tag was created on October 21, 2026, following a release-candidate cycle that began on September 14. The milestone gives node operators and wallet developers a final code reference for reviewing the next major version of the software used to validate Bitcoin transactions and blocks.
There is an important publication distinction. As checked on October 26, the official repository contained the final tag and release notes, but the project's main download page still identified 31.1 as the latest version. Its releases index did not yet list a 32.0 announcement, and the 32.0 download directory showed release-candidate folders. The confirmed October 21 event is the source tag, not a separately verified website announcement date.
Fee estimates respond to the transactions waiting now
The fee-estimation change addresses a familiar mismatch: previously confirmed transactions can suggest an expensive fee even after congestion has eased. Bitcoin Core 32.0 combines its existing block-history estimator with a new estimator examining the mempool, the node's collection of unconfirmed transactions.
The combined result can lower the historical estimate. It does not use the new method to raise that estimate. The implementation also checks whether recent blocks make the node's mempool a useful basis for estimation.
That distinction matters when choosing a fee. An estimate is a judgment about conditions, not a promise of confirmation by a deadline. Incoming transactions can change the competition for block space. Developers can retain the historical estimator explicitly, while users evaluating confirmation costs can review how crypto transaction fees work.
Faster validation and a different signing default
Block validation now fetches previous transaction outputs from the chainstate database in parallel. This reduces waiting when validation needs disk reads. The default is eight prefetching threads; actual benefits depend on the machine and workload.
The wallet compatibility change deserves separate attention. The createpsbt, walletcreatefundedpsbt, converttopsbt and psbtbumpfee remote procedure calls (RPCs), which other software uses to request wallet operations, now create PSBT version 2 by default. Their psbt_version argument allows callers to request a specific version.
PSBT means Partially Signed Bitcoin Transaction. It packages a transaction and supporting information so that different participants or devices can prepare and sign it. Hardware-wallet workflows and multisignature arrangements use this kind of interchange.
Version 2 permits inputs and outputs to be added during transaction construction and reorganizes the information used by signing software. BIP 370, its specification, explicitly makes it incompatible with version 0. A service that only understands version 0 therefore needs compatibility testing before it accepts the new default. Requesting version 0 where required can preserve an existing workflow while its components are updated.
Wallet tools and security fixes need operational review
New wallet commands include addhdkey, which adds an extended key without importing a separate descriptor, and derivehdkey, which retrieves a derived extended key for setups such as multisignature wallets.
The exportwatchonlywallet command supports a cleaner separation between an offline signing wallet and an online wallet that observes transactions. The project's revised tutorial uses an exported watch-only file on the online machine, while the private keys remain with the offline wallet. This is relevant to operators reviewing crypto wallet arrangements, rather than a change that every holder must configure.
The release notes also document a walletnotify fix for non-Windows systems. Under the affected configuration, an authenticated RPC caller with permission to create wallets could exploit a crafted wallet name to execute commands. Wallet names are now treated literally.
A separate fix addresses a potential IP-address leak during private broadcasting when a failed connection using the newer transport protocol falls back to an older one. Its relevance depends on the operator's Tor and proxy configuration.
Prepare the upgrade without skipping verification
The immediate audience is people running Bitcoin Core and services that depend on its wallet or RPC behavior. Operators should read the release notes, review their integrations and back up the wallet before replacing software. A holder using a separate wallet product should follow that product's compatibility guidance.
Use the project's official distribution channels and confirm that the download is the intended final release. Verify the file's hash against the published checksum list and authenticate that list using trusted release-signing keys. A matching filename alone does not establish authenticity. GitHub's verified tag indicator concerns the source tag; it does not replace verification of a downloaded installer.
The maintenance policy keeps three major version lines supported. The repository's 32.0 notes identify 29.x and older as end of life with this release. The lifecycle page still labels the 32.x release date as to be announced and places 29.x's cutoff after v32.0. Version 28.x and earlier already have dated end-of-life entries. Operators on these older lines should prioritize moving to supported software.
The final tag does not measure deployment. How quickly node operators upgrade, and how quickly wallet applications complete PSBT version 2 support, remains uncertain. Those are separate adoption questions that the release itself cannot settle.