Skip to content
Encryptorium

PQC

PQC Migration Plans Have a ZK Blind Spot

Andreas Renz · · 8 min read
PQC Zero-Knowledge ZK Rollups Post-Quantum Migration

Several major public PQC migration documents do not discuss zero-knowledge proof systems, even though some deployed ZK systems still rely on the same quantum-vulnerable assumptions those migration programs are trying to retire. These two engineering communities are building toward the same migration window, and the public PQC guidance does not account for ZK verification infrastructure.

The blind spot is documented

Three major public PQC migration documents published in the last two years do not discuss zero-knowledge proof systems.

NIST's IR 8547 initial public draft, published in November 2024, describes NIST's transition approach from quantum-vulnerable digital-signature and key-establishment standards to PQC, and discusses use cases such as code signing, network security protocols including TLS, and S/MIME. It does not discuss zero-knowledge proof verification infrastructure.

The UK National Cyber Security Centre's 2025 PQC migration timeline provides a three-phase roadmap through 2035. Zero-knowledge proof systems do not appear.

The European Commission's Recommendation 2024/1101 focuses on public administrations and critical infrastructure and calls for a coordinated PQC implementation roadmap. It also appears not to discuss zero-knowledge verification infrastructure.

Their scope is the classical cryptographic stack: key exchange, digital signatures, symmetric encryption. The omission suggests an assumption: that the cryptographic assets needing migration are the ones these frameworks already enumerate. ZK verification infrastructure is not in the inventory.

ZK verifiers are not certificates

The PQC migration model that enterprise security teams follow is built around primitive replacement. Swap classical signature and key-establishment primitives in your PKI and secure channels. Update your code signing. The core operation is substitution: remove one algorithm, insert another, verify compatibility.

ZK verification does not fit this model. An on-chain verifier contract is not a certificate you can rotate on a schedule. It is a live cryptographic endpoint embedded in consensus rules, accepting or rejecting proofs that determine whether state transitions are valid. Replacing it can require governance votes, dual-verifier transition windows, backward-compatible proof formats, and coordination across an ecosystem of provers, sequencers, and bridges. For a deeper analysis of why ZK migration is an architecture problem rather than a parameter swap, see Post-quantum ZK is an architecture problem.

Many deployed Ethereum-facing ZK verifiers rely on pairing-friendly elliptic-curve cryptography, and some stacks use pairing-based SNARKs to compress larger proofs for efficient on-chain verification. These systems depend on pairing-based assumptions that Shor's algorithm would break. That makes verifier migration a live architectural question, not a theoretical one.

The gap is that PQC migration documents do not enumerate these verifiers, and ZK teams have not connected their upgrade timelines to PQC planning frameworks.

"We use STARKs" is not enough

On the ZK side of the divide, teams building on hash-based proof systems often treat post-quantum readiness as a settled question. Scalable Transparent Arguments of Knowledge (STARKs) rely on collision-resistant hash functions, not pairings or discrete logarithms, so the reasoning goes: no Shor vulnerability, no problem.

The original STARK paper does include "post-quantum secure" in its title, and the core construction avoids pairing-based assumptions. That much is accurate. But deployed STARK-based systems are not the STARK paper. They are composite architectures with multiple layers, and not every layer inherits the hash-based security of the inner proof.

Consider the compression problem. STARK proofs are large relative to Succinct Non-interactive Argument of Knowledge (SNARK) proofs. To reduce on-chain verification costs, several rollups wrap their STARK proof in a pairing-based SNARK before posting it to Ethereum. RISC Zero's documentation is explicit: their STARK-to-SNARK translator uses Groth16 over BN254 and "is therefore vulnerable to attacks from quantum computers." Polygon zkEVM uses a combination of eSTARK proofs and FRI that are compressed using FFLONK SNARKs, with zk-SNARKs published on-chain as validity proofs, reintroducing a SNARK wrapper with its own classical assumptions. (Polygon's zkEVM network is sunsetting during 2026, but the architecture pattern is illustrative of how composite stacks work in practice.)

Then there is the Fiat-Shamir compilation question. Hash-based inner proofs improve the post-quantum story, but they do not make the whole stack automatically post-quantum. Compression layers, recursive wrappers, commitment schemes, and the exact Fiat-Shamir security analysis in the Quantum Random Oracle Model (QROM) all matter. Published results support Fiat-Shamir security in quantum models: Unruh showed that standard Fiat-Shamir is not automatically quantum-secure and constructed a modified QROM-safe transformation, while Don, Fehr, Majenz, and Schaffner proved that Fiat-Shamir preserves soundness and proof-of-knowledge for suitable sigma protocols in the QROM. But post-quantum security at the compilation layer is not automatic and depends on the exact protocol class, transformation, and proof assumptions.

PQC migration timelines offer ZK teams something they currently lack: a structured planning framework with a fixed horizon. The NCSC guidance places full migration at 2035. The engineering work to replace a verifier, audit a new proof system, and coordinate a protocol upgrade takes years. ZK teams that have not started planning are borrowing against a deadline they have not yet acknowledged.

What convergence looks like now

Three decisions that practitioners are making today are already PQC decisions, whether they recognize it or not.

Commitment scheme selection. Choosing between KZG backed polynomial commitment schemes and hash/Merkle-based transparent proving stacks is no longer just a performance tradeoff. KZG gives constant-size proofs and cheap verification, but it relies on pairing-based elliptic-curve assumptions. Hash/Merkle-based transparent stacks avoid those pairing assumptions at the proof/commitment layer, which can simplify the post-quantum migration path. Teams selecting KZG today are choosing a migration path that requires component replacement under quantum threat. The performance gap is real, but so is the migration cost gap.

Verifier upgradeability. Systems with immutable verifier contracts or hard-fork-only upgrade paths face the highest PQC migration barriers. Designing for verifier replaceability (proxy patterns, governance-controlled upgrades, dual-verifier transition periods) is not over-engineering. It is PQ hygiene. A verifier that cannot be replaced is a cryptographic dependency that cannot be migrated.

Post-quantum folding. Recursive proof composition through folding schemes is increasingly common in rollup design. These schemes inherit the PQ properties of their underlying commitment layers. Lattice-based alternatives are now in active development; LatticeFold, by Boneh and Chen, shows that folding over plausibly post-quantum assumptions is feasible. But the field is early. Teams adopting folding-based architectures today should understand that their PQ migration path depends on which commitment scheme sits underneath.

What to do about it

For PQC migration teams: add ZK verification infrastructure to your cryptographic inventory. On-chain verifiers, rollup proof pipelines, and ZK-based authentication systems are cryptographic assets with non-standard upgrade semantics. They do not appear in your certificate management platform or your Cryptographic Bill of Materials (CBOM) scanner output. If your migration plan does not enumerate them, your plan is incomplete.

For ZK protocol teams: audit your full pipeline, not just your inner proof system. What is your compression layer? Is your Fiat-Shamir compilation analyzed in a quantum-aware model? Can your verifier be upgraded without a hard fork? If you cannot answer these questions, "post-quantum compatible" is not a claim you can make.

For both: the migration window is measured in years of engineering effort, not years until a cryptographically relevant quantum computer arrives. A March 2026 Google Quantum AI resource-estimate paper argues that breaking 256-bit elliptic-curve cryptography may require on the order of 1,200 logical qubits and, under specific architectural assumptions, physical resources in the hundreds of thousands. (For a detailed analysis of what that paper does and does not claim, see Google's quantum threat to Bitcoin: what the paper actually says.) Whether those estimates prove optimistic or conservative, migration lead time is measured in years of engineering. The question worth asking now: does your PQ migration plan account for your verification infrastructure?

For many teams, the honest answer is still no.

Sources:

  1. NIST, "Transition to Post-Quantum Cryptography Standards," IR 8547 Initial Public Draft, November 2024. csrc.nist.gov
  2. UK National Cyber Security Centre, "Timelines for migration to post-quantum cryptography," 2025. ncsc.gov.uk
  3. European Commission, "Recommendation (EU) 2024/1101 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography," April 2024. eur-lex.europa.eu
  4. Shor, P., "Algorithms for quantum computation: discrete logarithms and factoring," FOCS 1994. doi.org
  5. Ben-Sasson, E., et al., "Scalable, transparent, and post-quantum secure computational integrity," IACR ePrint 2018/046. eprint.iacr.org
  6. RISC Zero, "Cryptographic Security Model," Developer Docs v3.0. dev.risczero.com
  7. Polygon, "Overview," Polygon zkEVM Docs. docs.polygon.technology
  8. Unruh, D., "Non-interactive zero-knowledge proofs in the quantum random oracle model," EUROCRYPT 2015. eprint.iacr.org
  9. Don, J., et al., "Security of the Fiat-Shamir Transformation in the Quantum Random-Oracle Model," CRYPTO 2019. eprint.iacr.org
  10. Kate, A., Zaverucha, G. M., Goldberg, I., "Constant-Size Commitments to Polynomials and Their Applications," ASIACRYPT 2010. springer.com
  11. Boneh, D., Chen, B., "LatticeFold: A Lattice-based Folding Scheme and its Applications to Succinct Proof Systems," IACR ePrint 2024/257. eprint.iacr.org
  12. Babbush, R., et al., "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities," arXiv:2603.28846, March 2026. arxiv.org