A Blockchain PQC Migration Framework

Government and national cyber guidance consistently frames PQC migration as a multi-year program. NSA CNSA 2.0 sets milestones such as “support and prefer” for key establishment by 2025, with “exclusively use” targets between 2030 and 2033 [47]. The UK NCSC uses milestones of 2028, 2031, and 2035 for complete migration [48]. NIST IR 8547 states that 112-bit security public-key algorithms are planned to be deprecated after 2030, with a goal of disallowing all quantum-vulnerable public-key algorithms entirely after 2035 [49].

For digital assets, a credible migration plan should align with these external milestones, but must account for the coordination costs analyzed above. Because blockchain upgrades move more slowly than centralized system upgrades, not faster, networks need a more aggressive start date. A post-quantum-safe authorization path needs to be available early so that migration can begin well before it becomes urgent, because by the time it becomes urgent, it will be too late.

We recommend protocols approach this migration systematically in 3 separate phases:

Phase 1: Cryptographic Inventory, Operational Readiness, and Off-Chain Hardening

The first requirement is visibility. Every digital asset organization needs a cryptographic inventory, not just of public endpoints, but of embedded and third-party dependencies across the full stack: wallet SDKs, hardware wallets, custody systems (HSM and MPC), remote signers, validator and sequencer operations, bridges, RPC infrastructure, and software supply chain signing. Without this map, protocol and operational upgrades will miss critical components. You cannot migrate what you have not inventoried.

In parallel, deploy post-quantum key establishment in the off-chain control plane wherever it is operationally feasible. Hybrid TLS and the existing OpenSSH defaults are mitigations that can be rolled out without protocol changes or user migrations, and they reduce long-term confidentiality exposure while on-chain plans mature. For most organizations, this should be treated as an immediate action item.

Finally, start the on-chain program in Phase 1, even if the on-chain changes ship later. The longest lead-time dependency for blockchains is not the cryptography but ecosystem coordination. Wallets, exchanges, custodians, and users all have to adopt the new authorization path, and that adoption window cannot be compressed. Starting the design, specification, and ecosystem engagement work now is not premature; it is the only way to have enough runway.

Phase 2: Deploy an On-Chain Authorization Path Designed to be the Final Migration

This is the critical path for digital assets. The objective is not simply to support post-quantum signatures, but to deploy an authorization path that can realistically become the default without requiring two full user migrations.

In practice this implies:

• Protocol support: Deterministic verification in consensus clients, and transaction and script formats that can carry the new authorization data without hitting existing size or compute limits.
• Economic sustainability: Fee and resource pricing rules that reflect the real costs of larger authorization data and verification, so the network remains stable under load and incentives align with migration rather than against it.
• Migration mechanics: Safe key rotation and upgrade flows that can be automated by exchanges and custodians, supported by wallet UX that makes upgrading routine rather than exceptional, with clear failure handling for edge cases.
• Testnets and rollout: Public testnets, independent security audits, and performance benchmarking under realistic load, followed by a staged mainnet rollout with published integration timelines for major ecosystem actors.
• Ecosystem readiness: Reference implementations in major languages, migration tooling, and monitoring dashboards to measure adoption rates and identify cohorts that are not upgrading.

The intent is to give users a viable post-quantum-safe option early, then allow a long runway for voluntary migration before any attempt to deprecate legacy authorization.

Phase 3: Default Adoption and Deprecation of Quantum-Vulnerable Authorization

External guidance converges on the early 2030s for completing migration across major system categories. For blockchains, “complete” should be interpreted strictly: the default way to authorize value transfers no longer relies on elliptic curve signatures, and legacy authorization paths are possibly deprecated rather than left as permanent escape hatches.

In a blockchain context, deprecation is typically gradual. It usually means: defaulting new outputs and accounts to post-quantum-secure authorization; increasing policy and economic friction for legacy authorization (higher fees, reduced priority, warning messages in wallets); and eventually disabling legacy paths via consensus once measured adoption is high and the ecosystem has had sufficient time and tooling to migrate safely.

The uncomfortable truth is that this phase — complete deprecation — is where most blockchain PQC plans become vague. It is easy to propose a new signature scheme; it is hard to build the social and technical machinery to actually move an entire ecosystem off the old one. More importantly, it is not just a coordination problem, it is a throughput problem. Even if every user is willing to migrate, the system still needs enough blockspace to process that migration.

Migration Throughput Reality Check

A useful way to ground this is to ask a simple question: how long would it take for every Bitcoin UTXO to move to a PQ address type, if a fixed share of Bitcoin blockspace were dedicated purely to migration transactions?

Under an extreme assumption where 100% of blockspace is used for migration, recent research shows it will take ~76 days [50]. As soon as migration competes with normal economic activity, timelines extend significantly.

The implication is simple. Migration timelines are bounded by system capacity. If meaningful migration only begins once the quantum threat is widely accepted, there may not be enough time for the system to complete the transition.

“The networks that will be best positioned are the ones that design for the full lifecycle from the beginning: not just ‘how do we support PQ signatures?’ but ‘how do we complete migration within real throughput limits before the threat materializes?’”

Time to Migrate All UTXOs (Days) vs % Blockspace Used for Migration TXs