BIP-360, Hardware Wallets, and Bitcoin's Real Post-Quantum Migration Path: What's Actually Happening in 2026
Published by: QubitChain Research
URL: qubitchain.io/blog/bip-360-hardware-wallets-bitcoin-post-quantum-migration-2026
Category: Bitcoin Security, Post-Quantum Cryptography
Reading Time: Approximately 12 minutes
Last Updated: August 2026
TL;DR - Quick Answer
BIP-360 was merged into the official bitcoin/bips repository on February 11, 2026, introducing Pay-to-Merkle-Root (P2MR), a Taproot-like output type with the quantum-vulnerable key path removed. A working testnet from BTQ Technologies has been producing real quantum-resistant transactions since March 2026. None of that means Bitcoin is quantum-safe: mainnet activation has not happened, migration would be entirely voluntary, and roughly 25 percent of supply sits in addresses whose public keys are already permanently exposed.
Bitcoin's path to quantum resistance stopped being theoretical this year. A formal proposal is merged into the official BIP repository, a working testnet is producing real quantum-resistant transactions, and hardware wallet vendors are shipping devices with post-quantum firmware verification. None of that means Bitcoin itself is quantum-safe yet, and the gap between "proposal merged" and "network protected" is where most of the confusion in this space comes from.
Definition: BIP-360
A Bitcoin Improvement Proposal, authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke, introducing Pay-to-Merkle-Root (P2MR), a new Bitcoin output type functionally similar to Taproot but with the quantum-vulnerable key-path spend removed. Originally circulated as P2QRH (Pay-to-Quantum-Resistant-Hash), it was merged into the official bitcoin/bips repository on February 11, 2026.
This is where things actually stand, mechanism by mechanism.
What BIP-360 Changes, Precisely
Taproot, Bitcoin's current standard output type, commits to two things: an internal public key and the Merkle root of an optional script tree. That internal public key is the problem. Whenever a Taproot output is spent via the key path, which is the default and most common spending method, the public key becomes derivable, and it was already derivable the moment the output was created, since Taproot addresses encode the public key directly.
P2MR removes the key path entirely. It commits only to the Merkle root of a script tree, with no public key exposed by the address itself. To spend a P2MR output, you must use the script path, satisfying a Tapscript condition, which can include post-quantum signature verification opcodes rather than the classical Schnorr signatures Taproot's key path relies on.
This is a soft fork, deployable via a new SegWit witness version, meaning it doesn't require every node on the network to upgrade simultaneously the way a hard fork would. Existing wallets and legacy address types continue functioning exactly as before. Migration to P2MR addresses (which will use a new bc1z prefix) is entirely voluntary.
That voluntariness is both the proposal's strength and its most significant limitation. It means BIP-360 can activate without the kind of contentious, all-or-nothing coordination fight that has stalled other proposed Bitcoin changes. It also means adoption depends entirely on individual users and services choosing to migrate, with no mechanism to move dormant, lost, or simply unmigrated coins to safety.
The Signature Algorithms Actually Named in the Proposal
BIP-360's tapscript context is designed to support post-quantum signature verification opcodes, with ML-DSA (the NIST FIPS 204 standard, formerly CRYSTALS-Dilithium) as the leading candidate given its status as a finalized standard. The proposal's authors have also discussed FN-DSA (Falcon, the NIST FIPS 206 candidate still in draft as of this writing) as a future option once finalized, since Falcon's significantly smaller signatures matter for a network as sensitive to block space as Bitcoin.
The size tradeoff is worth sitting with directly.
| Signature scheme | Approximate size | Status in Bitcoin |
|---|---|---|
| Schnorr (current standard) | 64 bytes | Live on mainnet via Taproot |
| FALCON-512 (FN-DSA) | ~666 bytes | NIST FIPS 206 still in draft |
| SPHINCS+ (SLH-DSA) | 7,800+ bytes | NIST FIPS 205 finalized |
Every post-quantum signature scheme available today is dramatically larger than what Bitcoin currently uses, and that size increase translates directly into reduced transaction throughput at a fixed block size, or a separate, contentious debate about increasing block size to compensate. This is the same fundamental tradeoff every retrofitted blockchain runs into, and it's a large part of why BIP-360's authors describe their own proposal as incremental rather than a complete solution.
The Testnet Is Real, Not a Whitepaper Concept
BTQ Technologies released a working implementation, Bitcoin Quantum testnet v0.3.0, in March 2026, with full P2MR consensus logic running on SegWit version 2 outputs and five Dilithium (ML-DSA) signature opcodes enabled inside the tapscript context. This isn't a simulation. People are creating and spending P2MR transactions on a live test network right now. The testnet has attracted more than 50 miners, produced over 100,000 blocks, and assembled an open contributor base of more than 100 cryptographers and developers.
That's meaningful progress for a proposal that was only formally merged in February. It is also, importantly, still a testnet. Mainnet activation requires the kind of broad ecosystem consensus that Bitcoin's governance process is deliberately slow to produce, and a BIP merge into the repository, as the proposal's own authors and independent trackers have been careful to clarify, signals only that the documentation meets the bar for formal community discussion. It is not an endorsement and it is not a timeline commitment.
Where Hardware Wallets Actually Stand
This is the part most coverage of Bitcoin's quantum roadmap skips, and it matters because a protocol-level fix like BIP-360 is worthless to an end user if their signing device can't produce or verify the new signature types.
Trezor has taken the most public position. Its newest flagship, the Safe 7, uses a dedicated secure element (the TROPIC01 chip) and is marketed as having a "quantum-ready" architecture, though this framing currently applies to firmware verification and device authentication rather than transaction signing itself. Trezor has also stated plainly that its older devices, the Safe 5, Safe 3, Model T, and Model One, rely on classical-only elliptic curve verification in their immutable boot chains and cannot be patched to support post-quantum verification; owners of those devices will eventually need new hardware, not a firmware update, to get any quantum-resistant boot verification.
Ledger's public position has been more cautious and more focused on near-term threats. Ledger Donjon, the company's internal security research team, published an analysis in early 2026 examining the practical constraints of running post-quantum signature algorithms on hardware wallet-class devices, noting that the memory and computational overhead of schemes like ML-DSA and SLH-DSA is meaningfully higher than what current secure elements are built for. Ledger has since added ML-KEM support to its SDK, aimed at secure communication between the device and host application rather than transaction signing, which is a narrower and different problem than post-quantum transaction authorization.
| Vendor | Public position | Covers transaction signing? |
|---|---|---|
| Trezor Safe 7 | TROPIC01 secure element, "quantum-ready" architecture | No, firmware verification and device authentication only |
| Trezor Safe 5 / Safe 3 / Model T / Model One | Classical-only elliptic curve boot chain, cannot be patched | No, requires new hardware |
| Ledger | Ledger Donjon research on hardware constraints; ML-KEM added to SDK | No, secure device communication only |
Independent benchmarking work published by Blockstream tested hash-based post-quantum signature schemes, including SLH-DSA variants and stateful schemes like XMSS, directly on production hardware wallets from four vendors: Jade, Trezor, Ledger, and BitBox02. The headline finding is genuinely useful: hash-based signature schemes already run on today's hardware wallet-class chips without requiring new silicon, which is a meaningfully different and more optimistic conclusion than the "these devices can't handle it yet" framing that dominates most coverage. The tradeoff, consistent with the broader signature-size problem across post-quantum Bitcoin proposals, is signature size and, for stateful schemes like XMSS, the operational complexity of tracking signing state correctly across device backups and restores.
The Broader Regulatory Backdrop
None of this is happening in a vacuum. U.S. federal agencies have faced deadlines under National Security Memorandum 10 to submit post-quantum cryptography transition plans, part of the same regulatory pressure driving NSA's CNSA 2.0 mandate that we've covered elsewhere on this site. The Ripple-maintained XRP Ledger published its own post-quantum readiness roadmap in 2026, with milestones through the first half of the year and a target of full transition no later than 2028, including an explicit contingency plan the team calls "Quantum-Day" for accelerating migration if current standards are compromised sooner than expected. Every serious blockchain project is now being asked the same question by institutional counterparties and regulators alike: what is your actual, dated plan.
Bitcoin's answer, for now, is BIP-360: a real, working, technically sound but voluntary and partial fix, still years from mainnet activation even under an optimistic timeline, that leaves every dormant, lost, or unmigrated coin permanently exposed regardless of how successful the migration eventually is for active users. For the comparable government timeline, see our breakdown of the UK NCSC post-quantum migration timeline.
What This Actually Means If You Hold Bitcoin
If you're holding Bitcoin and paying attention to this, the practical takeaways are specific, not general anxiety.
- Address type matters more than ever. An estimated 25 percent of circulating Bitcoin supply, including coins widely attributed to Satoshi Nakamoto, sits in addresses where the public key is already permanently exposed on-chain. That exposure predates BIP-360 and nothing in the proposal retroactively fixes it.
- BIP-360 activation, even in an optimistic scenario, is a multi-year process requiring broad ecosystem consensus, followed by voluntary user migration to new bc1z address types. There is no forced or automatic protection for existing holdings.
- Hardware wallet vendors are moving at meaningfully different speeds, and the differences are concrete enough to factor into purchasing decisions: Trezor has published the clearest statement about which of its own devices can and cannot be upgraded, while Ledger's public focus has stayed on near-term threat models with post-quantum signing support still described as constrained by current hardware.
Why Genesis-Native Design Avoids This Entire Category of Problem
Every part of Bitcoin's quantum migration story, the years of proposal discussion, the soft fork mechanics, the voluntary address migration, the hardware wallet vendor fragmentation, exists because Bitcoin has to retrofit post-quantum security onto a seventeen-year-old protocol with a trillion-dollar installed base that cannot be forced to move.
A blockchain built from its genesis block on NIST-finalized post-quantum standards doesn't have a migration story to write. QubitChain.io implements ML-DSA as the only transaction signature scheme from block one; there is no legacy signature format to phase out, no dormant-address exposure accumulated over years of ECDSA use, and no hardware wallet fragmentation problem because the protocol was never built around a signature scheme that needed replacing in the first place.
Full technical architecture: qubitchain.io/whitepaper. See how every major blockchain's quantum posture compares: qubitchain.io/compare. You can also join our waitlist for launch updates.
References
- Beast, H., Heilman, E., & Foxen Duke, I. (2026). BIP-360: Pay-to-Merkle-Root (P2MR). Bitcoin Improvement Proposals Repository, merged February 11, 2026.
- BTQ Technologies Corp. (2026, March). BTQ Technologies Implements BIP 360 Quantum-Resistant Bitcoin Transactions on Testnet.
- Ledger. (2026, July). Post-Quantum Cryptography in the Ledger SDK.
- Trezor. Going Quantum: Post-Quantum Readiness in Trezor Hardware.
- Blockstream. (2026). Are Hardware Wallets Ready to Produce Post-Quantum Signatures?
- National Institute of Standards and Technology. (2024a). FIPS 204: Module-Lattice-Based Digital Signature Standard.
- National Institute of Standards and Technology. (2024b). FIPS 205: Stateless Hash-Based Digital Signature Standard.
- QubitChain.io Technical Whitepaper v2.0. (2026).
Frequently Asked Questions
Q: What is BIP-360?
A: BIP-360 is a Bitcoin Improvement Proposal authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke that introduces Pay-to-Merkle-Root (P2MR), a new output type functionally similar to Taproot but with the key-path spend removed, eliminating the exposed public key that a quantum computer could target. It was merged into the official bitcoin/bips repository on February 11, 2026. It is deployable as a soft fork and does not require existing addresses or wallets to change.
Q: Is Bitcoin quantum resistant yet?
A: No. BIP-360 has been merged into the BIP repository and is running on a live testnet operated by BTQ Technologies, but it has not activated on Bitcoin mainnet. A BIP repository merge signals the proposal meets documentation standards for formal community discussion, not endorsement or an activation timeline. An estimated 25 percent of circulating Bitcoin supply currently sits in addresses with exposed public keys, and that exposure is unaffected by BIP-360's existence until mainnet activation and voluntary migration occur.
Q: Which post-quantum signature algorithm does BIP-360 use?
A: BIP-360's tapscript context is designed to support post-quantum signature verification opcodes, with ML-DSA (NIST FIPS 204, formerly CRYSTALS-Dilithium) as the primary candidate given its finalized standard status. FN-DSA (Falcon, NIST FIPS 206) is discussed as a future option once finalized, due to its smaller signature size. The BTQ Technologies testnet has five Dilithium (ML-DSA) signature opcodes live and functional.
Q: Are Trezor and Ledger hardware wallets ready for post-quantum Bitcoin?
A: Partially, and unevenly. Trezor's Safe 7 uses a secure element with what the company calls a "quantum-ready" architecture for firmware verification and device authentication, though this does not yet cover transaction signing. Trezor has stated its older devices (Safe 5, Safe 3, Model T, Model One) cannot be patched for post-quantum boot verification and will require replacement. Ledger's public focus has remained on near-term threats, with its security research team, Ledger Donjon, noting the hardware constraints of running post-quantum signing algorithms on current secure elements, while its SDK has added ML-KEM support for secure device communication rather than transaction signing.
Q: Can current hardware wallets actually run post-quantum signature algorithms?
A: Independent benchmarking by Blockstream tested hash-based post-quantum signature schemes, including SLH-DSA and XMSS variants, on four production hardware wallets (Jade, Trezor, Ledger, and BitBox02) and found that hash-based schemes already run on current hardware wallet-class chips without requiring new silicon. The tradeoff is signature size, which is significantly larger than current Schnorr signatures, and for stateful schemes like XMSS, the operational complexity of correctly tracking signing state across device backups.
Q: Why does a soft fork like BIP-360 not fully solve Bitcoin's quantum problem?
A: Because migration to new P2MR addresses is entirely voluntary. BIP-360 does not force existing coins into quantum-safe addresses, meaning dormant wallets, lost keys, and any holder who does not actively migrate remain in exactly the same exposed state they were in before the proposal existed. A blockchain built natively on post-quantum signature standards from its genesis block avoids this category of problem entirely, since there is no legacy signature format to migrate away from. See more questions at qubitchain.io/faq.