Bitcoin Core 32.0 Release Candidate 1 Tagged for October 10 Final Release

What a Release Candidate Actually Is

A release candidate is a version of software that developers believe is ready to ship. They label it "rc1" — short for release candidate 1 — and share it with the wider community for testing. If testers find serious bugs, the team fixes them and issues rc2. If testing goes smoothly, the rc becomes the official release. Bitcoin Core follows this process for every major version update.

Feature-complete means no new features can enter the codebase once an rc is tagged. The 32.x branch is now locked; only confirmed bug fixes can be merged into it. New ideas already continue on the master branch, which now points toward v33. This separation keeps the release candidate stable while active development of the next version runs in parallel, which is standard practice for large open-source software projects.

Bitcoin is a payment network with no central company running it. Bitcoin Core is the most widely used software for operating a full node on that network. A full node stores every transaction ever recorded and checks each new one against the protocol rules. When Bitcoin Core releases a new version, thousands of node operators around the world decide independently whether and when to upgrade their software.

How Bitcoin Core Verifies Its Own Code

The tagged commit for v32.0rc1 has the full hash d0231bb01d83178224bf7b198ba04f78cc2c89ef. Anyone can check that string against the GitHub release page to confirm the code has not changed since tagging. The tag also carries a GPG signature from the handle "sedited," using key ID 9B79B45691DB4173. GPG signatures let the community verify that the person who signed the tag controlled the matching private cryptographic key.

The signature description reads "Reproducibility Matters," pointing directly to Bitcoin Core's deterministic build system. Deterministic builds mean that any developer who compiles the same source code on a compatible machine produces byte-for-byte identical binary files. Multiple trusted contributors independently compile the release and publish checksums of their results. If those checksums match across contributors, users can be confident that the downloadable binary matches the published source code exactly.

This verification process matters for anyone running Bitcoin software. Downloading software without checking signatures risks installing a modified binary that could, for example, silently swap a Bitcoin wallet address for an attacker's address during a transaction. Bitcoin Core's deterministic build system gives the community a way to catch tampering before it reaches end users, making it one of the strongest security practices in open-source financial software.

The Schedule Behind v32.0

Bitcoin Core publishes its release schedule openly on GitHub. Issue #35122 is the official tracking ticket for the v32.0 release cycle. It listed September 10 as the planned date for the 32.x branch split and RC1 publication. The actual tag landed on September 14, a four-day difference. For a large volunteer-driven open-source project with contributors spread across many time zones, that gap falls within normal variance.

The predecessor major release, v31.0, shipped on April 19, 2026, according to bitcoin.org's version history. That means roughly 148 days passed between v31.0 and the v32.0 RC1 tag. Bitcoin Core typically targets a new major version roughly every six months. The RC1 arrival in mid-September keeps the project close to that rhythm and gives the final release a realistic target in early October.

Release schedule issue #35122 lists October 10, 2026 as the target date for the final v32.0 release, leaving a 26-day window for community testing from September 14. During that period, node operators, exchange developers, and mining pool operators can run the release candidate on test networks and report any problems. Checking bitcoin price data during major software cycles gives a real-time view of how active the network stays through release periods.

What RC Testing Looks Like in Practice

Testing a Bitcoin Core release candidate is not automatic. Volunteers download the rc binary, run it on their own hardware, and watch for unexpected behavior. Some test against the public test network called testnet. Others run the automated regression test suite that ships with Bitcoin Core, which contains thousands of individual checks covering transaction validation, peer-to-peer networking, wallet handling, and consensus rule enforcement.

If a tester finds a serious problem, they file a bug report on the Bitcoin Core GitHub repository. Maintainers review the report, determine whether it represents a confirmed defect in rc1, and decide whether a fix is needed before the final release. If a fix is required, it gets merged into the 32.x branch and a new release candidate — rc2 — is tagged for another round of testing. That loop continues until maintainers are satisfied.

The mempool — the pool of unconfirmed transactions waiting for inclusion in the next block — is one area that receives particular attention during RC testing. Changes to fee estimation, transaction eviction rules, or relay policies affect every node on the network. A bug in mempool handling could cause a node to reject valid transactions or accept invalid ones, disrupting normal network operation and potentially triggering an urgent follow-up release candidate.

• Transaction validation and relay rules across testnet and mainnet configurations
• Wallet signing, address generation, and descriptor handling
• Peer discovery, connection limits, and ban logic for misbehaving nodes
• Regression tests covering known historical edge cases in consensus enforcement

The Path from Release Candidate 1 to Bitcoin Core 32.0

If the 26-day testing window surfaces no critical bugs, maintainers will promote the release candidate to the final v32.0 on or around October 10, 2026. At that point, signed binaries for Linux, macOS, and Windows will appear on bitcoin.org. Node operators and exchanges that have been running the rc will already know what has changed, making the production upgrade smoother than starting from scratch with no prior testing.

While RC testing runs, development on the master branch already points toward v33. Features proposed during the v32 cycle but not ready in time will be reviewed for inclusion in the next major version. Operators who want to understand how Bitcoin mining software interacts with node upgrades can watch the Bitcoin Core GitHub repository for merges into master during this period to get an early picture of what v33 might bring.

Bitcoin Core 32.0 release candidate 1 is a stable snapshot of code the development team believes is ready for the network. The tag on September 14, 2026 opened a formal public review window that any operator, exchange, or developer can participate in. If testing confirms that quality, that snapshot becomes Bitcoin Core 32.0 — the next major version of the most widely used node software on the Bitcoin network, with October 10 as the date the community is now working toward.