Post-Quantum Migration for Blockchain Teams

TL;DR

Three NIST standards are final and have been since 13 August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. Two more are unfinished — HQC was selected on 11 March 2025 with no draft FIPS published, and FN-DSA has never appeared as a public draft. So "comply with applicable PQC FIPS" today means 203, 204 and 205 only. The deadline most checklists quote, NIST's 2030 deprecation and 2035 disallowance, comes from IR 8547, which has been an initial public draft since 12 November 2024 and was never finalised. What binds US federal systems is Executive Order 14412 of 22 June 2026: post-quantum key establishment by 31 December 2030, signatures by 31 December 2031, for High Value Assets and high-impact systems. The UK's NCSC gates are 2028, 2031 and 2035. Hybrid is the default everywhere serious. And on a blockchain, none of this works the usual way, because you cannot hard-fork a signature scheme without moving every user's coins first.

The Post-Quantum Migration, in the Order the Work Happens

Most guides in this genre are algorithm tours. That is the wrong shape, because the algorithm choice is the smallest decision you will make and, for most teams, it is already made for you by the standards that are final.

The order that survives contact with a real system:

1. Inventory every cryptographic primitive and the confidentiality lifetime of what it protects.
2. Migrate key establishment first, because harvest-now-decrypt-later is a confidentiality attack.
3. Deploy hybrid, not pure post-quantum, with a downgrade path.
4. Measure the size and latency cost against your actual protocol frames before you commit.
5. Make signatures agile — an algorithm identifier in the wire format — rather than choosing a post-quantum signature scheme now.
6. If you run a chain, solve the user-migration problem before you solve the algorithm problem. It is harder and it is on the critical path.

Everything below is detail on those six. For the hardware side — how close a machine actually is, and what the 2026 resource estimates do and do not say — I keep that separate in The Quantum Threat to Bitcoin and Ethereum, Measured. This article assumes you have decided to migrate and want the mechanics.

What NIST Actually Finalised, and What It Has Not

The NIST post-quantum cryptography project page↗, updated 5 August 2026, lists three final standards and HQC as selected for ongoing standardisation, with no entry at all for FN-DSA. That split is the single most load-bearing fact in this whole area, and it gets blurred constantly.

Read the table as a decision: if you need key establishment, you use ML-KEM. If you need signatures and you need them standardised now, you use ML-DSA, or SLH-DSA where you want a hash-based security argument rather than a lattice one. There is no third option with a final FIPS behind it.

HQC was selected on 11 March 2025 and documented in NIST IR 8545. It is a code-based KEM, chosen deliberately as a non-lattice backup in case something goes wrong with the lattice assumption underneath ML-KEM. That is the interesting part: NIST picked a second KEM not because ML-KEM is slow but because it does not want the whole internet resting on one mathematical family. No draft FIPS has been published for it. The FIPS number 207 that circulates for HQC is an inference, not a NIST assignment, and I have not seen it confirmed.

FN-DSA is murkier. NIST reportedly submitted the draft for approval on 28 August 2025, and a "FIPS 206 Status Update" was presented by Ray Perlner at the 6th PQC Standardization Conference↗, held 24–26 September 2025. No public draft appears in the CSRC news feed. The "late 2026 or early 2027" final date you will see quoted is a secondary-source projection, not a NIST commitment. Do not plan against it.

The rest of the 2025 and 2026 output is supporting material rather than new algorithms: SP 800-227 on 18 September 2025, a draft SP 800-230 adding SLH-DSA parameter sets on 13 April 2026, a draft SP 800-133r3 on 17 April 2026, and IR 8610 on 14 May 2026.

The signature onramp, and what it tells you

IR 8610, dated 14 May 2026, advanced nine candidates to round three of NIST's Additional Digital Signatures onramp: FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign and UOV.

The onramp exists for two reasons, and both are worth reading as a signal. NIST wants signature diversity outside lattices, for the same reason it picked HQC. And ML-DSA and SLH-DSA both produce far larger keys and signatures than ECDSA — SLH-DSA is slow with it, while ML-DSA's cost is almost entirely size — which is a problem for anyone whose wire format has a signature in every message. None of the nine is standardised. So any post-quantum signature decision a chain makes today is a decision between FIPS 204, FIPS 205, and the stateful hash-based schemes XMSS and LMS, which NIST approved in SP 800-208↗ rather than in a FIPS, and which carry a state-management requirement that rules them out for general use. That is the whole menu.

You Are Citing a Draft

Open any migration checklist and you will find "NIST requires deprecation of classical algorithms by 2030 and disallowance by 2035" stated as policy. Check the CSRC publication page for IR 8547↗. It is an initial public draft, released 12 November 2024, with a comment period that closed 10 January 2025. There is no second draft and no final. The 2030 and 2035 figures circulating in checklists come to me through secondary summaries, and I did not extract the timeline table from the PDF myself — so if you are writing a compliance document, fetch the source before you quote the dates verbatim.

What actually binds is Executive Order 14412↗, "Securing the Nation Against Advanced Cryptographic Attacks", signed 22 June 2026 and published in the Federal Register on 25 June 2026 as document 2026-12909. It applies to High Value Assets and high-impact systems, excluding national security systems, and it sets two dates:

• 31 December 2030 for post-quantum key establishment.
• 31 December 2031 for post-quantum digital signatures.

Note the ordering. Key establishment first, signatures a year later. That is not an accident; it is the harvest-now-decrypt-later logic written into policy.

The rest of the order sets the machinery. Section 4(a): each agency names a PQC migration lead within 30 days. Section 4(b): OMB guidance within 90 days, requiring an HVA inventory review, the 2030 and 2031 transitions, and a plan. Section 4(c): a NIST PQC migration pilot within 180 days, to be complete by 31 December 2027. Section 5(d): CISA publishes minimum elements for a cryptographic bill of materials within 270 days. Section 6(c): a FAR Council proposed rule within 180 days requiring covered contractors to comply with post-quantum FIPS by 31 December 2030.

That last one is the clause that reaches private companies. If you sell software into US federal procurement, the contractor rule is your deadline, and "applicable PQC FIPS" resolves to 203, 204 and 205, because nothing else is final.

The UK's is cleaner and earlier. The NCSC post-quantum migration roadmap↗, published March 2025, sets three gates: discovery and a migration plan by 2028, highest-priority upgrades done by 2031, full migration by 2035. It is guidance with no statutory force on its own, but for operators of essential services under the UK NIS Regulations 2018 those dates are the technical baseline a competent authority will apply. The roadmap builds directly on the algorithms NIST finalised in August 2024, and it was among the earliest national guidance to set dated migration gates against them.

Hybrid Is the Default

Pure post-quantum means you have replaced the classical algorithm. Hybrid means you run both and derive the shared secret from both, so an attacker has to break the lattice scheme and the elliptic curve scheme to get anything.

Hybrid wins on a simple asymmetry. ML-KEM has had a fraction of the cryptanalysis that X25519 has absorbed over two decades. If a lattice weakness lands in 2029, a hybrid deployment degrades to the security you already had. A pure deployment degrades to nothing. The cost is a larger handshake and two implementations to maintain — real, measurable, and cheap next to the failure mode.

Signal's rollout is the reference implementation of the pattern. On 2 October 2025 it shipped SPQR, the Sparse Post-Quantum Ratchet, turning the Double Ratchet into a Triple Ratchet with hybrid post-quantum forward secrecy and post-compromise security. It was built with PQShield, AIST and NYU, and it shipped with automatic downgrade fallback during the rollout period. Three properties worth copying: hybrid rather than replacement, automatic rather than opt-in, and a documented downgrade path so a partially upgraded network keeps working.

The downgrade path is the part teams get wrong. A protocol that hard-fails when one side lacks post-quantum support does not get deployed; it gets reverted at 2am. Negotiate, prefer, log what you got, and alarm on the ratio — not on the individual connection.

Where TLS Already Moved, and Where It Did Not

Post-quantum key agreement is already the majority case on the public web. According to Cloudflare's Radar 2025 Year in Review↗, the share of human-generated web traffic to Cloudflare secured with post-quantum key agreement rose from 29% at the start of 2025 to 52% in early December 2025, and Cloudflare Radar has since reported it above 60%. Do not read that against the nearly 2% of TLS 1.3 connections in Cloudflare's March 2024 post↗, which measures a different thing. The Radar page itself returns a 403 on direct fetch, so verify the current number before you quote it.

Server-side is a different picture. Cloudflare Radar tracks the share of customer origins that support X25519MLKEM768, from daily automated TLS scans of TLS 1.3-capable origins, and that share has been reported in the high single digits — an order of magnitude behind the browser-facing side. The Radar page returns a 403 on direct fetch, so treat the exact number as unverified and check it yourself before it goes into a client document. I reached those figures through search summaries rather than the Radar page itself, which returned a 403 on direct fetch, so re-verify before quoting a percentage in a client document.

The shape of the gap matters more than the exact percentages. Browsers moved. CDNs moved. Origin servers, internal service-to-service traffic, database connections, message queues, VPN tunnels and admin planes did not. If your architecture terminates TLS at a CDN and then speaks plain classical TLS to an origin, the post-quantum protection stops at the edge. The hop nobody looks at is usually the one with the longest-lived secrets on it.

Practical consequence: your migration work is not in the browser-facing path, which a CDN vendor will hand you. It is in the internal hops. That is the same lesson as getting security headers right in production — the default-facing surface gets attention and the internal surface does not.

Size Is the Migration Cost Nobody Budgets

Here is where I have to be careful, because this is the section where guides invent numbers.

What I can source: NIST's Additional Digital Signatures onramp exists to find schemes with smaller signatures and faster verification than the lattice standards, and IR 8610 records SQIsign advancing on the strength of having the smallest combined key and signature sizes in the field. That is why nine more candidates went to round three on 14 May 2026, and why SQIsign and the multivariate schemes are in that list at all. I do not have the parameter-set byte counts in front of me from a primary source, so I am not going to print them. Read the parameter tables in FIPS 204 and FIPS 205 directly and measure against your own frame budget. A number-shaped hole is honest here; a remembered byte count is not.

What the size problem looks like in practice, with figures I can source:

EIP-8141 defines SECP256K1 signatures at 65 bytes — v, r, s, with the key recovered — and P256 signatures at 128 bytes, r, s, qx, qy, because P256 has no key recovery and must carry the public key. P256 is still a classical elliptic curve. Ethereum's own specification is already carrying a roughly 2x difference in authentication payload between two pre-quantum curves, and the calldata cost of that difference is real. Any post-quantum scheme lands in a protocol that is already size-sensitive at the 65-byte scale.

And on the consensus side, the Ethereum Foundation's plan replaces BLS with leanXMSS hash-based signatures aggregated through leanVM, a minimal zkVM cited at roughly 250x data compression. You do not build a zkVM to compress signatures unless the raw signatures are far too big to aggregate any other way. That 250x figure is the clearest published statement of how much size pressure a post-quantum consensus signature scheme creates. Rollup teams should read it alongside the blob economics, which I go through in Fusaka, Blobs and Rollup Economics, because the data budget is the same budget.

Three questions to answer before you pick a scheme:

• What is your per-message signature budget, in bytes, today, and what breaks at 10x?
• Do you verify one signature per message or thousands per block? Verification cost scales differently from size.
• Can you aggregate? If aggregation is the only way the numbers work, that constrains the scheme family before anything else does.

The Inventory Step Teams Skip

Every migration plan I have seen that failed, failed here. You cannot migrate a system you have not enumerated, and nobody has an accurate list of where their cryptography is, because most of it arrived inside dependencies.

Executive Order 14412 Section 5(d) directs CISA to publish minimum elements for a cryptographic bill of materials within 270 days of 22 June 2026. That tells you the artifact this is standardising on. Start producing one now rather than waiting for the format, because the hard part is the discovery, not the schema.

A first pass costs an afternoon:

# primitives that appear in source, config and lockfiles
rg -n 'secp256k1|ed25519|x25519|prime256v1|PKCS1|PKCS8|BLS12|alt_bn128|KZG|ECDSA|ECDH|RSA' .

# what your TLS endpoints actually negotiate, per host
openssl s_client -connect "$HOST:443" -tls1_3 2>/dev/null | grep 'Server Temp Key'

Grep finds what your code names. It will not find what a dependency, a hardware module, a managed database or a cloud KMS chose on your behalf, and those are where the surprises live. For each finding, record five fields:

The fourth row is the one that turns a spreadsheet into a plan. A signing key held in a hardware module you cannot re-provision, or an on-chain verifier in an immutable contract, is not a line item. It is a redesign. Find those in month one, not month twenty.

Harvest-now-decrypt-later gives you the ordering rule. It is a confidentiality attack: recorded ciphertext decrypted later. It does not apply to signatures, because a quantum computer cannot retroactively forge a signature that was already verified and accepted. So key establishment protecting genomic records, health data, defence traffic, long-retention financial records, source code and IP goes first. A session token expiring in an hour goes last. Peter Gutmann of the University of Auckland is the most prominent published sceptic of blanket harvest-now framing, and the distinction is worth understanding before you let it set your budget — I am working from secondary summaries rather than his papers, so read them directly before you cite him., and the distinction is worth understanding before you let it set your budget — though I am working from secondary summaries of his critique.

The Blockchain Problem: You Cannot Hard-Fork a Signature Scheme

In a normal system, migrating a signature scheme is a deployment. You ship a new version, support both during a window, then drop the old one. The users do not participate.

On a chain, the users are the migration. Every output or account is bound to a key that only the holder can move. The protocol cannot rotate it, cannot re-sign it, and cannot reach the person holding it. A hard fork that changes the signature scheme does nothing for existing balances. Adding a post-quantum scheme is the easy half. Getting every user to move is the half that has no technical solution.

That is why the live proposals look the way they do.

BIP-360↗ — Pay-to-Merkle-Root, renamed from Pay-to-Tapscript-Hash, authors Hunter Beast, Ethan Heilman and Isabel Foxen Duke, created 18 December 2024 — defines SegWit version 2 with prefix bc1z. It is P2TR with the quantum-vulnerable key-path spend removed, so newly created outputs stop being exposed at rest. It deliberately contains no post-quantum signature algorithm; those were split into a future BIP so P2MR can be debated without settling the algorithm argument. It is Draft, reported merged into the bitcoin/bips repository on 11 February 2026, with a first signet transaction reported on 10 September 2025.

BIP-361 — "Post Quantum Migration and Legacy Signature Sunset", authors Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile and Pierre-Luc Dallaire-Demers, created 11 February 2026, Draft and Informational — attacks the other half. Phase A, roughly 160,000 blocks after activation, prohibits sending to quantum-vulnerable outputs. Phase B, two years later, tightens ECDSA and Schnorr spend rules, encumbering them with a quantum-safe rescue protocol: it leans on the asymmetry of knowledge between a quantum attacker and the real holder, who knows the BIP-32 hardened derivation path, so legitimate owners retain a recovery route that an attacker does not have. Adam Back has argued for optional upgrades instead of a scheduled freeze, and critics call the proposal confiscatory. Lopp's own line, posted to X on 15 April 2026: "I know folks don't like it. I don't like it myself. I wrote it because I like the alternative even less." In the same post he added that BIP-361 "isn't a spec, nor is it proposed for activation" and is "a rough idea for a contingency plan that needs more R&D".

Neither BIP has a BIP-9 or BIP-8 activation mechanism, deployment parameters, or a Bitcoin Core merge. The 2026 merge dates refer to the documentation repository. Nothing here is scheduled.

Ethereum's EIP-8141, Frame Transaction, Draft since 29 January 2026, defines three verification schemes — ARBITRARY at 0x0, SECP256K1 at 0x1, P256 at 0x2 — and describes itself as "a native off-ramp from the elliptic curve based cryptographic system used to authenticate transactions today, to post-quantum (PQ) secure systems". It ships the extension point and no post-quantum algorithm. The Foundation's stated L1 target, on ethereum.org's quantum-resistance page↗, is that "the structured fork milestones target the completion of core post-quantum infrastructure by approximately 2029", with full execution-layer and ecosystem migration extending beyond that. That is its own assessment.

The pattern across all three is the same, and it is the correct pattern: ship the agility before the algorithm. That is the design lesson to take into your own protocol, and it is the same discipline as planning for upgradeability in contracts — put an identifier in the format, keep the verifier swappable, decide the algorithm later when the standards catch up.

If you are weighing a chain that claims post-quantum security already, the comparison is in Quantum-Resistant Blockchains Compared.

A Plan You Can Run This Quarter

1. Produce a cryptographic inventory. Grep the repos, then read the dependency and infrastructure layer, which is where the real findings are. Record primitive, owner, data confidentiality lifetime, rotation mechanism, vendor dependency.
2. Rank by confidentiality lifetime, not by system importance. Ten-year secrets on a low-traffic internal service outrank ephemeral secrets on your busiest endpoint.
3. Turn on hybrid key agreement where it costs nothing. CDN-terminated traffic is usually a settings change. Then do the hop behind the CDN, which is the one that matters.
4. Add an algorithm identifier to any wire format you own. Signature schemes, session records, signed webhooks, stored envelopes. If the format cannot express "which algorithm", you will be doing a flag-day migration later.
5. Find the keys nobody can rotate. Hardware modules, immutable on-chain verifiers, embedded devices, long-lived signing keys in vendor systems. These are the long-lead items.
6. Write the deadline that applies to you, with its citation. EO 14412 if you sell into US federal. NCSC 2028/2031/2035 if you operate essential services in the UK. Not IR 8547, which is a draft.
7. If you run a chain, start the user-migration design now. The algorithm will be standardised long before your users have moved, and the moving is the multi-year part.

If you want this run against a specific protocol or product — inventory, ranking, and a migration plan with the dates that actually bind you — let's talk about your project.

Key Takeaways

• Three FIPS are final, two workstreams are not. FIPS 203 (ML-KEM), 204 (ML-DSA) and 205 (SLH-DSA) since 13 August 2024; HQC selected 11 March 2025 with no draft FIPS; FN-DSA never published as a public draft.
• IR 8547 is still an initial public draft from 12 November 2024, with a comment period that closed 10 January 2025. Citing its 2030/2035 dates as NIST policy is a sourcing error.
• EO 14412 is the binding US instrument: post-quantum key establishment by 31 December 2030, signatures by 31 December 2031, with a FAR rule reaching covered contractors by the same 2030 date.
• Hybrid is the default, and Signal's SPQR from 2 October 2025 is the pattern to copy: hybrid, automatic, with a documented downgrade path.
• TLS moved at the edge and not at the origin. Over 60% of human TLS traffic to Cloudflare uses hybrid ML-KEM against roughly 10% of origins, per figures I could only reach through secondary summaries.
• Size is the constraint that picks your scheme. NIST advanced nine candidates to round three of its Additional Digital Signatures onramp on 14 May 2026 in IR 8610 — an onramp it opened to find signature schemes smaller and faster to verify than ML-DSA and SLH-DSA.
• On a chain, the users are the migration. BIP-360, BIP-361 and EIP-8141 all ship agility rather than an algorithm, because moving every user is the part with no technical fix.

About the Author

I'm Uvin Vindula — a Web3 and AI engineer based between Sri Lanka and the UK. I build production smart contracts and Next.js systems, which means I have had the "where exactly is our cryptography" conversation more than once, and it is always longer than anyone expects. You can see my work at iamuvin.com or reach out about a project at hello@iamuvin.com↗.

If you are planning a migration across contracts and backend services, this pairs with the smart contract security checklist I work from.