Q-Day Is Closer Than You Think: Post-Quantum Threats to Blockchain Privacy

Three Papers, Twelve Months, One Conclusion

In May 2025, a single researcher at Google published a paper that cut the estimated cost of breaking RSA-2048 — the encryption standard protecting most of the internet — from 20 million qubits to under 1 million. Nine months later, Iceberg Quantum brought that number below 100,000. Three weeks after that, Google Quantum AI published resource estimates for breaking 256-bit elliptic curve cryptography — the same math that secures every Bitcoin and Ethereum private key — with under 500,000 qubits and a runtime measured in minutes.

Three papers. Twelve months. A 10-100x reduction in what it takes to break the cryptography that the entire blockchain ecosystem relies on.

This isn't a theoretical exercise. Google's own calculations suggest a 41% probability that a quantum computer could derive a Bitcoin private key before a ten-minute transaction confirmation window closes. Not in some distant future. Within the planning horizon of the machines being built right now.

If you design, build, or operate privacy infrastructure on Ethereum — or if you hold assets in any protocol that uses zero-knowledge proofs — this article explains what's at stake, what's already been broken, what's still safe, and what the migration paths look like.

What "Q-Day" Actually Means

"Q-Day" is the day a quantum computer can break widely deployed public-key cryptography in practice — not just in theory, not just for a researcher with a billion-dollar budget, but as a repeatable operation. The term is borrowed from nuclear weapons development ("the day the bomb works"), and the analogy is intentional: once the capability exists, it cannot be un-invented.

For blockchain, Q-Day has a specific meaning: the day someone can forge a digital signature, break a zero-knowledge proof, or decrypt encrypted data using a quantum computer faster than the system can respond.

The consensus timeline from cryptography researchers, intelligence agencies, and hardware manufacturers has been narrowing for years. But what happened between May 2025 and March 2026 accelerated the conversation from "decades away" to "maybe this decade."

The Three Papers That Changed the Timeline

Paper 1: Craig Gidney at Google (May 2025)

Craig Gidney, a researcher at Google Quantum AI, published "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits" — and then showed the number could be brought below 1 million qubits using improvements to quantum error correction and arithmetic circuits.

The prior state of the art, from Gidney and Ekerå in 2021, estimated 20 million physical qubits for RSA-2048. Gidney's 2025 update applied improved surface code magic state distillation and windowed arithmetic to slash that figure by more than an order of magnitude.

RSA-2048 isn't directly used in blockchain. But the mathematical hardness assumption — integer factorization — is in the same complexity class as the elliptic curve discrete logarithm problem that secures every wallet, every signature, and every pairing-based zero-knowledge proof in the ecosystem. Improvements in attacking one directly translate to improvements in attacking the other.

Paper 2: Iceberg Quantum (February 2026)

Iceberg Quantum, a startup specializing in quantum algorithm optimization, published a preprint demonstrating RSA-2048 factorization with fewer than 100,000 logical qubits. Their approach combined novel quantum circuit compilation techniques with hybrid classical-quantum processing to dramatically reduce the qubit overhead.

From 20 million to under 100,000 in less than a year. Two orders of magnitude.

To put this in context: IBM's Condor processor (2023) has 1,121 qubits. Google's Willow processor (2024) demonstrated quantum error correction below the surface code threshold with 105 physical qubits. The gap between "what exists" and "what's needed" went from approximately four orders of magnitude to roughly two. That's a gap that hardware roadmaps are explicitly designed to close.

Paper 3: Google Quantum AI (March 2026)

The most directly relevant paper for blockchain: Google Quantum AI published resource estimates for breaking 256-bit elliptic curve cryptography (specifically secp256k1, the curve used by Bitcoin and Ethereum) with under 500,000 physical qubits and a runtime of minutes.

This paper didn't just estimate resources — it computed the probability of a successful attack within specific time windows. The headline result: a 41% probability of deriving a Bitcoin private key from its public key before a standard 10-minute transaction confirmation. Not certainty. Not impossibility. A coin flip.

Google accompanied this paper with something unprecedented: a responsible disclosure of the vulnerability, published as a zero-knowledge proof. We'll come back to the irony of that later.

The Expert Timeline

Where do researchers actually place Q-Day?

The honest answer is: nobody knows. But the range of informed estimates has been compressing.

a16z Crypto's analysis of the quantum threat landscape identifies three tiers:

NIST clearly takes the threat seriously enough to act now rather than later. Their Post-Quantum Cryptography Standardization Process — which began in 2016 — finalized three standards in August 2024 and published NIST IR 8547, which mandates the deprecation of all quantum-vulnerable cryptographic algorithms by 2035. NIST doesn't set deadlines for problems they consider speculative.

The National Security Agency (NSA) has been even more direct. Their Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requires all national security systems to transition to post-quantum algorithms by 2033 — with software and firmware requiring transition by 2030.

Whether Q-Day arrives in 2030 or 2040 is, in some sense, beside the point. The cryptographic migration takes years. The data being exposed today is permanent. And for privacy protocols specifically, the threat model has a uniquely devastating feature.

What's Vulnerable in Blockchain

Before focusing on privacy protocols, let's map the full attack surface. Shor's algorithm — the quantum algorithm that solves both integer factorization and the discrete logarithm problem in polynomial time — threatens every component of blockchain infrastructure that relies on the hardness of these mathematical problems.

Shor's Algorithm: The Universal Solvent

Shor's algorithm, published by Peter Shor in 1994, runs on a quantum computer and solves two problems exponentially faster than any known classical algorithm:

1. Integer factorization — breaks RSA
2. Discrete logarithm over finite fields and elliptic curves — breaks ECDSA, EdDSA, ECDH, BLS signatures, and all pairing-based proof systems

For blockchain, the second is the critical one. Virtually everything is built on elliptic curve cryptography (ECC).

The Full Attack Surface

Everything in this table falls to the same attack: Shor's algorithm on the elliptic curve discrete logarithm problem. When the quantum hardware exists to run Shor's at sufficient scale, all of these break simultaneously. Not one at a time. All at once.

BN254: Already Below the Bar

Before quantum computers enter the picture, BN254 — the curve behind Tornado Cash, RAILGUN, 0xBow Privacy Pools, and most deployed ZK applications on Ethereum — already has a classical security problem.

The Kim-Barbulescu attack (2015) improved the Number Field Sieve algorithm for computing discrete logarithms in the specific finite field extension used by BN254 pairings. This reduced BN254's effective security from the originally claimed ~128 bits to approximately 100 bits.

One hundred bits of security means an attacker with $2^{100}$ operations can break the system. That's still computationally infeasible today with classical computers. But it's below NIST's 128-bit minimum for new cryptographic deployments, and it means BN254 has less margin against advances in both classical and quantum attacks.

This is why we migrated UPP from BN254 to BLS12-381 — a painful circuit-level rewrite that bought us 128-bit classical security. But even BLS12-381 falls to Shor's algorithm. The SNARK system is a stopgap. The curve is stronger, not safe.

Why Privacy Protocols Are Uniquely Threatened

Here's where blockchain privacy diverges from the general quantum threat.

When a quantum computer breaks ECDSA, the immediate risk is wallet theft. Attackers can derive private keys from public keys and steal funds. That's bad. But it's a forward-looking threat — the attacker needs a quantum computer now to steal funds now. And there are mitigations: don't reuse addresses, move to quantum-resistant signature schemes, upgrade wallet software.

For privacy protocols, the threat is retroactive.

Harvest Now, Decrypt Later

Every shielded transaction on Ethereum is public data. The encrypted ciphertext, the ZK proof, the ephemeral public keys — all of it is stored permanently on the blockchain. It's visible to anyone running a node. It's been visible since the transaction was mined.

Today, that data is meaningless without the private keys. The ZK proofs verify without revealing the witness. The encrypted notes can't be decrypted without the recipient's key. The ephemeral public keys are useless without the corresponding secrets.

When a sufficiently powerful quantum computer exists, all of those protections collapse:

1. Ephemeral public keys embedded in shielded transactions can be used to derive ECDH shared secrets via Shor's algorithm. This decrypts the note data — revealing sender, recipient, amount, and token for every historical transaction.

2. BabyJubJub spending keys (used by RAILGUN) can be extracted from the public keys embedded in note commitments. This reveals the owner of every note ever created.

3. ZK proofs can be forged. The soundness of Groth16 and PLONK relies on the discrete logarithm assumption. If that assumption breaks, an attacker can generate proofs for statements that aren't true — withdrawing funds they don't own, bypassing compliance checks they shouldn't pass.

The "harvest now, decrypt later" (HNDL) strategy is not speculative. It's an acknowledged practice by intelligence agencies, including the NSA. The logic is straightforward: storage is cheap, encrypted data is publicly available on every blockchain, and the decryption capability is a matter of when, not if. Record everything now. Decrypt later.

For a privacy protocol, this means: data you shielded in 2026 could be fully exposed in 2035. Every sender. Every recipient. Every amount. Retroactively. There is no "undo" for a transaction that's been on-chain for nine years.

This is fundamentally different from the wallet theft scenario. Wallet theft is a point-in-time risk. Privacy breach is cumulative. Every day that a privacy protocol operates on pairing-based cryptography, it generates more data for future decryption. The liability grows monotonically.

What This Means for Existing Protocols

Let's be specific about what's at risk for each major privacy protocol:

Tornado Cash (sanctioned, but the smart contracts still exist on-chain): All historical deposits and withdrawals used Groth16 on BN254. A quantum attacker could forge withdrawal proofs, but more importantly, could potentially deanonymize the link between deposits and withdrawals by analyzing the proof structure. The anonymity guarantees are time-limited.

RAILGUN: Uses Groth16 on BN254 with BabyJubJub for key management. Every note's owner is identifiable once BabyJubJub private keys can be extracted. Every encrypted note is decryptable once ECDH shared secrets can be computed. The entire transaction history — $4.5 billion in cumulative volume — becomes transparent.

0xBow Privacy Pools: Same proof system as Tornado Cash (Groth16 on BN254). Same vulnerability. The ASP compliance layer doesn't change the quantum exposure of the underlying cryptography.

UPP's PLONK system: Our everyday proof system uses PLONK on BLS12-381. This is a pairing-based scheme. It falls to Shor's algorithm just like Groth16 on BN254, albeit from a higher classical security baseline (128-bit vs ~100-bit). We designed it knowing this. That's why it isn't the only system.

What's Safe

Not everything falls to quantum computers. The distinction is between cryptographic primitives based on structured mathematical problems (factoring, discrete logarithm) and those based on unstructured problems (hash collision, lattice shortest vector).

STARKs: Hash-Based and Quantum-Resistant

STARKs — Scalable Transparent Arguments of Knowledge — are the most mature post-quantum zero-knowledge proof system. Their security rests entirely on the collision resistance of hash functions (SHA-256, Keccak-256, Blake2, etc.).

The best quantum attack against hash functions is Grover's algorithm, which provides a quadratic speedup for brute-force search. For a hash function with $n$-bit security against classical attacks, Grover's algorithm reduces this to $n/2$ bits of quantum security. The fix is straightforward: double the hash output size. A 256-bit hash (128-bit classical security) becomes 128-bit secure against quantum attacks, or use a 512-bit hash for 256-bit quantum security.

As StarkNet's analysis demonstrates, STARKs can provide Bitcoin-level quantum security using hash functions that already exist and are already standardized. No new mathematical assumptions. No new hardness conjectures. Hash functions have been studied for decades, and their security model is well-understood.

STARKs also have no trusted setup — they're "transparent," meaning the verifier doesn't need to trust that a setup ceremony was performed honestly. This eliminates an entire class of vulnerabilities (toxic waste, ceremony collusion) that affects all pairing-based SNARKs.

The trade-off is cost. STARK proofs are larger (~5 KB vs ~200 bytes for Groth16) and more expensive to verify on-chain (~20 million gas vs ~230K gas for a SNARK on BN254). That's approximately 100x more expensive. But the security model is categorically different.

FHE: Lattice-Based and Conjectured Safe

Fully Homomorphic Encryption (FHE) schemes like TFHE (used by Zama and Fhenix) are built on lattice problems — specifically, Learning With Errors (LWE) and its ring variant (RLWE). These problems are conjectured to be quantum-resistant: no known quantum algorithm provides a significant speedup over classical attacks.

The emphasis on "conjectured" matters. Lattice problems don't have the same decades-long track record as hash functions. NIST selected lattice-based schemes for their post-quantum standards (see below), which is a strong vote of confidence. But the security margins are less well-understood than for hash-based constructions.

FHE is primarily relevant for on-chain computation over encrypted data — a different use case from zero-knowledge proofs. But the quantum resilience of the underlying lattice assumptions means FHE-based privacy solutions inherit post-quantum security by construction.

Hash-Based Signatures: NIST-Standardized and Proven

Hash-based signature schemes — XMSS, LMS, and SPHINCS+ (standardized as NIST FIPS 205 / SLH-DSA) — rely solely on hash function security. They're the most conservative post-quantum signature scheme: their security proof reduces directly to the second-preimage resistance of the underlying hash function. No algebraic structure. No lattice assumptions. Just hashes.

The downside: signature sizes are large (up to 50 KB for SPHINCS+ at the highest security level) and signing is slower than ECC. For blockchain applications where signature size directly impacts gas costs and block space, this is a meaningful constraint.

The NIST Post-Quantum Standards

NIST's Post-Quantum Cryptography Standardization Process, which ran from 2016 to 2024, produced three final standards. These aren't recommendations. They're federal standards, mandated for use in U.S. government systems and increasingly adopted by the private sector.

FIPS 203: ML-KEM (Key Encapsulation)

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), derived from CRYSTALS-Kyber, is the standard for post-quantum key exchange. When two parties need to establish a shared secret over an insecure channel — the operation currently performed by ECDH in stealth address protocols — ML-KEM is the NIST-approved replacement.

ML-KEM comes in three security levels:

For comparison, a standard ECDH public key on secp256k1 is 33 bytes (compressed). The post-quantum equivalent is 24-47x larger. This has direct implications for on-chain data costs and stealth address design.

FIPS 204: ML-DSA (Digital Signatures)

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), derived from CRYSTALS-Dilithium, is the standard for post-quantum digital signatures. This is the ECDSA/EdDSA replacement.

An ECDSA signature on Ethereum is 65 bytes. ML-DSA-44 at the lowest security level is 2,420 bytes — 37x larger. For Ethereum, where every byte of calldata costs gas, this isn't a trivial increase. Transaction costs could increase by an order of magnitude for the signature component alone.

FIPS 205: SLH-DSA (Hash-Based Signatures)

FIPS 205 (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+, is the conservative alternative — hash-based, with security proofs that don't rely on any algebraic structure at all. It's slower and produces larger signatures than ML-DSA, but its security argument is simpler and better understood.

NIST IR 8547: The Deprecation Mandate

NIST IR 8547, published alongside the standards, sets a concrete timeline: all quantum-vulnerable algorithms must be deprecated by 2035. This means RSA, ECDSA, ECDH, and by extension, all pairing-based proof systems built on these curves.

For the blockchain industry, 2035 isn't a distant deadline. It's nine years away. The Ethereum protocol itself — including its validator BLS signatures — needs to migrate. Every smart contract, every wallet, every ZK circuit built on elliptic curve assumptions is on the clock.

Migration Paths for Privacy Protocols

Given the threat landscape, what can privacy protocols actually do? There are four viable migration paths, each with different trade-offs.

Path 1: STARK Adoption

Replace pairing-based SNARKs with hash-based STARKs. This is the most direct path to post-quantum ZK proofs.

Advantages:

• Quantum-resistant by construction
• No trusted setup
• Mature prover implementations (Stwo, Stone, ethSTARK)
• Already deployed in production (StarkNet, StarkEx)

Challenges:

• ~100x higher verification gas on Ethereum L1
• Larger proof sizes (impacts calldata costs)
• Different circuit development paradigm (AIR vs R1CS)
• Existing deployed contracts can't be upgraded (immutable)

Path 2: Hash-Based Proof Systems

Build ZK proof systems from hash functions directly, without the STARK framework. This includes systems like Aurora (R1CS over hash-based IOPs) and various hash-based commitment schemes.

Advantages:

• Minimal assumptions (hash collision resistance only)
• Can reuse existing R1CS circuit designs

Challenges:

• Less mature tooling than STARKs
• Performance characteristics still being optimized
• Limited production deployments

Path 3: Lattice-Based Proofs

Construct ZK proof systems from lattice assumptions (LWE, SIS). Research-stage systems like lattice-based SNARKs aim to provide the succinctness of SNARKs with post-quantum security.

Advantages:

• Potentially smaller proof sizes than STARKs
• Could maintain SNARK-like verification efficiency
• Built on NIST-standardized assumptions

Challenges:

• Still in active research
• No production implementations
• Concrete security parameters remain uncertain
• Parameter sizes are large

Path 4: Hybrid Approaches

Run classical and post-quantum systems in parallel. Use SNARKs for efficiency today, STARKs for quantum resistance where needed. Migrate gradually as the threat materializes and as STARK verification costs decrease.

Advantages:

• No immediate disruption to existing systems
• Users choose their security level
• Incremental migration
• Cost-optimized for current threat environment

Challenges:

• Dual implementation and maintenance burden
• Users must understand the threat model to make informed choices
• Pool fragmentation if SNARK and STARK users are segregated

This is the path we chose.

UPP's Dual Proof System

Universal Private Pool runs two proof systems side by side. Not as a migration path where one replaces the other. As complementary systems for different threat models.

PLONK on BLS12-381: The Everyday System

For routine private transactions — paying invoices, transferring between wallets, moving funds between shielded positions — UPP uses PLONK on BLS12-381.

• 128-bit classical security (NIST-compliant, unlike BN254's ~100-bit)
• ~200K gas verification (efficient, thanks to EIP-2537 BLS12-381 precompiles since the Pectra upgrade)
• Universal trusted setup (no per-circuit ceremony; deterministic Phase 2)
• Browser-based proving (WASM, 10-30 seconds)
• NOT post-quantum secure — still pairing-based, still falls to Shor's algorithm

For transactions where the privacy exposure window is short — you shield, transfer, and withdraw within days or weeks — the quantum threat is minimal. The attacker would need a quantum computer right now, today, to exploit the proof before the funds have moved. Given the current state of quantum hardware, this is a reasonable risk assessment for low-to-medium-value everyday transactions.

Circle STARK: The Post-Quantum Vault

For high-value, long-duration privacy — storing significant assets in a shielded position for months or years, protecting data that must remain private for decades — UPP offers a Circle STARK mode.

• ~128-bit quantum security (hash-based, Keccak-256)
• ~20M gas verification (expensive, but the cost of quantum resistance)
• No trusted setup at all (fully transparent)
• Native Rust proving (Stwo prover, ~2ms proof generation)
• Post-quantum secure — relies only on collision resistance of Keccak-256

The STARK verifier is built natively in Solidity — not wrapped through a SNARK, not verified via an intermediary, not dependent on any off-chain component. It uses the Stwo prover framework from StarkWare, operating over the Mersenne-31 field ($p = 2^{31}-1$) with a custom Keccak-256 channel that leverages Ethereum's native keccak256 opcode for a 100x gas reduction over Blake2s.

The system currently supports two circuit types:

How They Coexist

Both proof systems operate on the same pool. The same Merkle tree. The same ASP compliance layer. The same ragequit guarantees. A user who shields via SNARK can withdraw via STARK, and vice versa (once all circuit variants are implemented).

The choice between SNARK and STARK mode is a per-transaction decision made by the user based on their own threat model:

This isn't a hedge. It's a deliberate architectural decision. We wrote about the reasoning behind it in our post-quantum documentation: the SNARK system is efficient and practical for the vast majority of transactions today. The STARK system exists because "today" has an expiration date, and the data being generated now will outlive the cryptography protecting it.

What the Protocol Stack Looks Like Post-Quantum

Understanding UPP's approach requires mapping which components are already quantum-resistant and which still need migration.

Already Quantum-Resistant (Hash-Based)

These components rely exclusively on hash functions and symmetric cryptography. Grover's algorithm provides only a quadratic speedup against them, which is neutralized by using appropriate output sizes.

The insight here is that UPP's core protocol design — the UTXO model, the nullifier scheme, the ASP compliance circuit, the ragequit mechanism — is inherently quantum-resistant. These are all hash-based constructions. The vulnerability lives entirely in the elliptic curve layer used for proofs and key management.

Vulnerable (Elliptic Curve-Based)

The last row is important: even if a privacy protocol migrates everything internal to post-quantum primitives, Ethereum itself still uses ECDSA for transaction authentication. A quantum attacker who can derive private keys from public keys can impersonate any Ethereum account. This is an ecosystem-wide problem that requires an Ethereum protocol upgrade — outside the scope of any individual application.

The Migration Phases

Our migration plan proceeds in four phases, with the first two already complete:

Phase 1: Hash-Based Shield (Complete) Replaced BabyJubJub key derivation with Keccak hash for STARK accounts. New commitment format using hash-based ownership instead of elliptic curve keys.

Phase 2: STARK Proving (Complete) Built native Circle STARK verifier in Solidity (~1,900 lines across 7 libraries). Implemented withdraw and transfer circuits in Rust using Stwo. End-to-end verification on Ethereum L1. 72 tests passing.

Phase 3: Full STARK Integration (Next) Replace remaining SNARK-only circuits (merge, joinsplit, merge-transfer variants) with STARK equivalents. Browser-based STARK proving via WASM compilation.

Phase 4: Post-Quantum Key Management (Future) Replace ECDH stealth addresses with ML-KEM or hash-based alternatives. Update note encryption and viewing key architecture to remove all elliptic curve dependencies.

When Phase 4 is complete, UPP's entire stack — from proof generation to key management to note encryption — will operate on post-quantum assumptions. The only remaining EC dependency will be Ethereum's own transaction signing, which requires a protocol-level upgrade.

The Google Irony

In March 2026, Google's Quantum AI team published their resource estimates for breaking 256-bit ECC. The paper itself is significant. The way they published it is remarkable.

Google chose to disclose the vulnerability as a zero-knowledge proof. Using SP1 zkVM and Groth16, they generated a proof attesting: "We computed these quantum resource estimates correctly, and the results show that secp256k1 can be broken with under 500,000 qubits." The proof was verified on-chain — on BLS12-381.

Read that again.

A zero-knowledge proof, verified on BLS12-381, attesting that quantum computers can break the discrete logarithm problem on which BLS12-381's security depends.

The ZK proof proving that pairing-based cryptography is on borrowed time was itself verified using pairing-based cryptography. The vulnerability disclosure was authenticated by the very system it disclosed as vulnerable.

This isn't hypocrisy. It's pragmatism. BLS12-381 is the best available verification system on Ethereum today. The proof is valid now, while quantum computers are still too small to forge it. But the proof itself is evidence that "now" won't last forever. It's a self-referential demonstration of urgency: the tool we used to prove the threat is the same tool the threat will destroy.

Google's team explicitly acknowledged this irony in their disclosure. It's perhaps the most effective argument for post-quantum migration: the proof system we trust today to verify mathematical statements can itself verify the statement that it will eventually be broken.

Grover's Algorithm: The Other Quantum Threat

Shor's algorithm gets the headlines because it catastrophically breaks public-key cryptography. But Grover's algorithm — the other major quantum algorithm — deserves mention for what it does and doesn't threaten.

Grover's algorithm provides a quadratic speedup for unstructured search problems. For cryptographic hash functions, this means:

• A 256-bit hash that requires $2^{256}$ classical operations to brute-force requires $2^{128}$ quantum operations
• A 128-bit symmetric key that requires $2^{128}$ classical operations requires $2^{64}$ quantum operations

The mitigation is straightforward: double your security parameter. Use 256-bit hashes instead of 128-bit. Use AES-256 instead of AES-128. The performance impact is minimal and the quantum threat is fully neutralized.

This is exactly why STARKs are quantum-resistant. They rely on hash collision resistance, and the Grover's algorithm speedup is handled by choosing appropriate hash output sizes. SHA-256 with 128-bit classical collision resistance retains 128-bit security against Grover's. Keccak-256, used in UPP's STARK channel, provides the same margin.

Grover's algorithm does NOT provide a meaningful speedup against:

• Hash-based proof systems (STARKs)
• Symmetric encryption (AES-256-GCM)
• Hash-based signatures (SLH-DSA / SPHINCS+)
• Hash-based key derivation (HKDF, scrypt)

The quantum threat to blockchain is almost entirely about Shor's algorithm and its variants — not Grover's.

What Should Protocol Designers Do Now?

If you're building or maintaining a privacy protocol, here's a practical assessment of priorities.

Immediate (2026-2027)

1. Audit your elliptic curve exposure. Map every component that depends on ECDLP, ECDH, or pairing assumptions. Know exactly what breaks when Shor's algorithm scales.

2. Stop deploying on BN254. The Kim-Barbulescu reduction to ~100-bit security already puts BN254 below the NIST floor. New deployments should use BLS12-381 at minimum. We documented the migration process in detail.

3. Begin STARK integration. If you can't replace your entire proving system immediately, start with the highest-value operations. Implement STARK verification alongside existing SNARKs. The dual system approach lets you migrate incrementally.

4. Assess "harvest now, decrypt later" exposure. For any on-chain encrypted data — shielded notes, stealth address communications, encrypted memos — calculate the sensitivity window. If data shielded today must remain private for 10+ years, your system needs post-quantum encryption now, not later.

Medium-Term (2027-2030)

5. Implement post-quantum key exchange. Replace ECDH with ML-KEM (FIPS 203) for stealth addresses and note encryption. The key sizes are larger, but the NIST standards are finalized and libraries are available.

6. Plan for NIST IR 8547 compliance. The 2035 deprecation mandate applies to government systems first, but private-sector adoption follows. Financial infrastructure that interacts with regulated entities will need to comply.

7. Contribute to Ethereum's post-quantum transition. The EVM itself needs post-quantum signature verification. Advocate for EIPs that support ML-DSA or SLH-DSA verification precompiles.

Long-Term (2030-2035)

8. Complete migration. All elliptic curve dependencies removed. All proofs on hash-based or lattice-based systems. All key management on post-quantum primitives.

9. Historical data protection. For protocols that stored encrypted data on-chain during the pre-quantum era, develop migration tools that allow users to re-encrypt or re-shield under post-quantum schemes.

The Cost of Waiting

The counterargument to all of this is: "Quantum computers are years away. We'll migrate when we need to."

This argument fails for three reasons.

First: migration takes years. We migrated UPP from BN254 to BLS12-381 — a comparatively simple change (same proof system family, same circuit paradigm, different curve). It required rewriting nine circuits, one SDK, one Solidity hash implementation, and one verifier. For a codebase we built from scratch and understood completely, this took weeks. For a protocol with years of accumulated technical debt, deployed immutable contracts, and an existing user base, the migration to a fundamentally different proof system is an order of magnitude harder.

Second: the data is already exposed. Every pairing-based ZK proof published on Ethereum today embeds ephemeral elliptic curve public keys. Those keys are stored permanently in Ethereum's state history. When quantum computers reach sufficient scale, they'll be decryptable regardless of whether the protocol has since migrated. The data that exists today cannot be un-published.

Third: the timeline is uncertain in the wrong direction. Three papers in twelve months moved the goalposts by 10-100x. The next algorithmic breakthrough could move them again. Planning for the conservative estimate (2035-2040) while the aggressive estimate (2027-2033) accelerates means you might be caught mid-migration when the window closes.

NIST didn't spend eight years standardizing post-quantum algorithms because the threat is hypothetical. Google didn't publish responsible disclosure of ECC quantum vulnerabilities because they think it's decades away. The NSA didn't mandate CNSA 2.0 transition by 2030 for software systems because they're being cautious.

The organizations with the best intelligence on quantum computing timelines are the ones acting with the most urgency.

What We Believe

We designed UPP with two proof systems because we believe the following:

1. Pairing-based SNARKs will be broken within the operational lifetime of protocols being deployed today. The question is whether Q-Day arrives in 2030 or 2040 — not whether it arrives.

2. Privacy data has a longer exposure window than financial data. A stolen private key can be rotated. A deanonymized transaction history cannot. Privacy protocols face a uniquely devastating retroactive threat.

3. The answer needs to be deployed before it's needed. Migrating to post-quantum cryptography after quantum computers break your system is like buying flood insurance after the flood. The value of the protection is in having it before the event.

4. Users should choose their threat model. Not every transaction needs quantum resistance. Paying for coffee doesn't require a 20M gas STARK proof. But holding $10 million in a shielded position for three years does. Offering both systems — and letting users decide — is the honest approach.

5. The cost of STARKs will decrease. L2 execution, proof aggregation, EVM gas schedule updates, and hardware-accelerated verification will all reduce the gas premium for STARK verification over time. What costs 100x more today may cost 10x more in two years and 2x more in five. The architecture should be ready when the economics catch up.

We're not claiming to have solved the post-quantum problem completely. Our STARK circuits cover withdraw and transfer operations today. The remaining circuit variants (merge, joinsplit, merge-transfer) are next. Post-quantum key management is a future phase. And Ethereum's own signature scheme is outside our control.

But the first two phases are built, tested, and verifiable on Ethereum L1. The architecture exists. The path forward is concrete.

UPP is pre-audit and deployed on Sepolia testnet. We're not claiming production readiness. We're claiming that the engineering groundwork for post-quantum privacy on Ethereum has been laid — and that anyone building privacy infrastructure should be laying similar groundwork now.

---

For technical details on UPP's Circle STARK verifier, see our post-quantum documentation, FRI protocol implementation, and Keccak channel design. For a comparison of UPP and RAILGUN's architectural approaches, see UPP vs RAILGUN.

The SDK packages are available at @permissionless-technologies. If you're building privacy infrastructure, working on post-quantum cryptography, or operating a compliance service — get in touch.