What can be done, and how urgent is quantum migration?

Post-quantum cryptography, or PQC, uses cryptographic constructions designed to resist known classical and quantum attacks. It runs on conventional computers; a user does not need a quantum computer to produce a post-quantum signature.

In August 2024, NIST finalised standards including ML-DSA and SLH-DSA for digital signatures, and ML-KEM for establishing shared secrets. ML-KEM is not a replacement transaction-signature algorithm. The distinction matters when a product advertises itself as “post-quantum.”¹²³

The existence of a standard does not automatically protect a blockchain. A network must accept the relevant verification rules, implementations must be reliable, wallets and custodians must support them, and existing assets or authorities must migrate. Larger keys or signatures, verification costs and aggregation requirements can affect the design.

The appropriate judgement is to prepare and test migration now, while treating the date of a practical attack as uncertain. NIST recommends beginning the transition using available standards. That recommendation is evidence of a need for preparation, not proof that an attacker can already recover a production blockchain key.⁴

A new device, a longer seed phrase or encrypted transport can improve other security properties without resolving quantum forgery of an exposed signing key. An institution must identify the exact cryptographic boundary covered by each claim.

Where a hybrid requires two independent authorisations, both must be satisfied. Where an attacker can choose either a classical path or a post-quantum path, the vulnerable path may remain sufficient. Security is determined by the complete acceptance rule, including recovery and emergency access.

What a real migration involves

For a Bitcoin output, migration can require an authorised spend into a new supported output type. A consensus upgrade that permits stronger outputs does not automatically move every old coin. For an account-based application, migration may instead involve changing authentication logic or authority, provided the existing design and network support it.

A credible migration sequence includes:

1. Inventory the assets, key types, public-key exposure and signing authorities.

2. Establish the target construction and the status of network support.

3. Implement and test signing, verification, recovery and custody integration.

4. Obtain the required governance decisions and operational approvals.

5. Move assets or replace authorities while the old authorisation remains trustworthy.

6. Verify completion, including backups, administrative keys and exceptional recovery paths.

The process must cover more than customer wallets. Validators, bridge signers, contract upgrade keys, oracles, software distribution and relevant proof or commitment systems can create additional dependencies. Ethereum's public quantum-security material identifies distinct work across account signatures, consensus, data commitments and application proofs. A stronger wallet signature alone cannot establish that the whole system is quantum-resistant.⁵

After a signature scheme becomes practically forgeable, proving legitimate ownership through another signature under the same compromised assumption becomes problematic. That is one reason to plan migration before a demonstrated attack, rather than assume a normal key rotation will remain trustworthy afterwards.

Existing proposals illustrate different scopes, not completed protection

Status checked on 24 September 2026: Bitcoin's BIP 360, Pay-to-Merkle-Root, is a draft proposal that removes Taproot's key-path spend from a proposed output design. It addresses prolonged public-key exposure; it does not itself deliver a complete post-quantum signature scheme or eliminate the short-exposure spending problem.⁶

BIP 361 is a draft informational proposal concerning post-quantum migration and restrictions on legacy signatures. It is not an activated rule or an agreed deadline for Bitcoin holders.⁷

Ethereum's post-quantum team publishes work spanning execution, consensus and data layers. Its roadmap explicitly remains subject to research and governance. The existence of that programme is relevant evidence of preparation, but it is not proof that all existing accounts, validators and applications have migrated.⁸

A book that labels each item research, specification, implementation, test deployment, activated rule or completed asset migration gives readers a more useful picture than a binary “quantum-safe network” label.

How to assess urgency without inventing a countdown

A cryptographically relevant quantum computer, or CRQC, must be capable of completing the particular attack, at the relevant key size, with sufficient reliability and within the time available. The raw number of physical qubits does not establish that capability.

Logical qubits are protected through error correction. Resource assessments also depend on gate counts, error rates, connectivity, operation speed and the overhead of keeping a long computation reliable. Smaller experimental demonstrations and algorithm simulations should not be equated with recovery of a production cryptocurrency key.⁹¹⁰

In March 2026, Google Research published reduced resource estimates for elliptic-curve attacks under stated hardware assumptions. These are projected requirements for future machines, not a reported theft demonstration. Such research can shorten the prudent preparation horizon without establishing a date when the required hardware will exist. Google's stated 2029 migration timeline is an organisational target, not a proven arrival date for an attacker.⁹

The planning relationship is:

preparation time + deployment and migration time + contingency < time remaining before the relevant attack is feasible.

The right-hand side is uncertain. The left-hand side can be investigated and reduced now.

Suppose a fictional custodian needs 18 months for system and vendor changes, 12 months for client migration, and a six-month allowance for testing and disruptions. Under an illustrative sequential plan, it needs three years. Waiting for a confident forecast that the threat is two years away would already be too late for that plan. This is a lead-time example, not a forecast of quantum capability.

Different exposures have different clocks. A long-exposed treasury key may be vulnerable to a machine too slow to compete with a newly revealed spending key. An upgrade authority protecting many client accounts may deserve priority over an individually small balance. Confidential records with long secrecy requirements create a separate “collect now, decrypt later” problem; public blockchain transactions are already visible, and their central issue here is future forgery of authority.¹⁰

Dormant assets turn a technical migration into a governance problem

Some owners will be inactive, unaware, unable to sign or permanently missing their keys. Proposed responses can include leaving old spending rules available, restricting legacy spends after a transition, or introducing additional recovery conditions. Each choice has costs: potential theft, immobilised legitimate assets, contested recovery rights or disagreement over the accepted chain.

These are possible policy choices, not statements about what Bitcoin or Ethereum has decided. BIP 361 and Ethereum's quantum-security discussion show that legacy and dormant holdings are part of the migration debate.⁷⁵

For a capital-markets institution, the issue can affect custody terms, client communications, asset recognition, trading support and liquidity before a cryptographic attack occurs. An uncertain future technology can create present governance and market risk when participants disagree about the remedy.

The practical objective is a dated exposure inventory, a tested migration route where support exists, accountable owners and evidence-based escalation triggers. Those triggers should track demonstrated capabilities and actual deployment milestones, rather than a vendor's qubit headline or a single predicted “Q-day.” Chapter 7 develops operational controls; Chapter 17 develops the evidence and scenario framework.