Bitcoin Core v32.0rc1 Tagged: Final Release Targets October 10
Bitcoin Core tagged v32.0rc1 on September 14, 2026, opening a roughly four-week testing window before the planned final release on October 10. Node operators should pull the draft release notes and report issues before the final tag ships.
The first release candidate for Bitcoin's reference implementation is live, giving node operators roughly four weeks to test before the code ships to the network.
Key takeaways
- Bitcoin Core tagged v32.0rc1 at commit
d0231bbon September 14, 2026, four days past the original September 10 target, with a signed GPG tag from committer handlesedited. - The planned final v32.0 tag is October 10, 2026, per the published release schedule; RC1 is feature-complete and open for community testing now.
- Draft release notes are live on the Bitcoin Core devwiki. Node operators should read them and file issues before the final tag closes the window.
Bitcoin Core tagged v32.0rc1 on September 14, 2026 at 12:58 UTC, commit d0231bb, with a GPG-verified signature from the handle sedited (key ID: 9B79B45691DB4173, labeled "Reproducibility Matters"). The final v32.0 release is targeted for October 10, per release schedule issue #35122.
What RC1 Actually Is
RC1 is feature-complete code. Nothing new gets merged. From this point, the only changes that make it into v32.0 are bug fixes surfaced during the RC testing period.
If the community finds critical issues, maintainers cut RC2, then RC3 if needed. That is the normal cadence. The four-day slip from the September 10 target is not a signal of anything wrong; it is within the ordinary variance of a volunteer-driven open-source release process that has shipped a major version roughly every six months for years, per Bitcoin Core's lifecycle policy.
The draft release notes, moved to the devwiki via PR #36226 on September 11, are the authoritative changelog. Anyone writing about specific features in v32.0 should be working from that document directly at the devwiki draft, not secondhand summaries.
Why This Window Matters for Node Operators
Every full node on the Bitcoin network eventually runs on Bitcoin Core or a fork of it. The RC period is the last public checkpoint before that happens. It is the window where bugs get caught, where edge cases in wallet tooling surface, and where the distributed review process either holds or breaks.
The signed tag matters too. The sedited handle's GPG signature on the release tag, labeled "Reproducibility Matters," is a direct reference to deterministic builds. Reproducible builds mean anyone can verify that the binary they download matches the source code that was audited. That is not a formality; it is the mechanism that makes trusting the release rational rather than a leap of faith.
One proposal that was in the pre-freeze pipeline deserves attention once the devwiki draft is read carefully: a change that would let node operators reject unencrypted v1 outbound cleartext connections. If that made it into RC1, it represents a meaningful privacy upgrade at the P2P layer, raising the baseline cost of ISP-level traffic analysis on Bitcoin node communication. Verify against the devwiki before treating it as confirmed.
With v32.0 shipping, older supported major versions move a step closer to end-of-life. Per the Bitcoin Core lifecycle policy, when a new major version is released, the oldest maintained version falls out of the maintenance window and becomes end-of-life. Node operators on older versions should confirm their version against that page and plan an upgrade path before v32.0 final drops.
What to Watch Through October 10
The RC process is the signal to watch, not the final release. If RC1 passes without a consensus-critical finding, v32.0 ships on schedule and the story is Bitcoin's development machinery doing exactly what it is supposed to do. Boring, reliable, on time.
If the devwiki draft reveals a contentious RPC change, a wallet-breaking policy shift, or a consensus behavior that splits the community, this becomes a different story fast. The trigger that would change the framing entirely: a confirmed consensus-critical bug in RC1, or a changelog item that breaks existing self-custody tooling at scale.
The test binary path and verification steps will follow the same pattern as prior RCs. Confirm the exact download URL against bitcoincore.org before testing, and verify signatures before running anything.
Sources
Frequently Asked Questions
RC1 is feature-complete code released for community testing before the final tag. It is not for production nodes or active wallets. Run it on a testnet setup or an isolated environment to surface bugs. If issues appear, report them on the Bitcoin Core GitHub before the final tag closes the window.
Bitcoin Core releases use deterministic builds and GPG-signed tags. The release tag for v32.0rc1 carries a verified signature from key ID 9B79B45691DB4173. Verification steps are covered in the Bitcoin Core devwiki testing guide. Never skip verification on any binary touching your node or keys.
Older major versions eventually fall outside the maintenance window and stop receiving security backports. With v32.0 shipping, the support window shifts. Check your running version against Bitcoin Core's lifecycle policy. Nodes on versions outside the maintained range face real security risk over time, not just a missed feature.
