BenchmarksStack Ranking
APIsPricingDocsWhite PaperTokenBlogAboutSecurity Demo
Log InGet API Key
Post-Quantum · 11 min read

How to Make ZCash Post-Quantum—
And Why They're Running Out of Time

ZCash's entire privacy stack—Groth16 SNARKs, Halo 2, Ed25519 signatures, Diffie-Hellman key exchange—is quantum-vulnerable. Here's the three-layer fix using H33's STARK proofs, 3-Key signatures, and Kyber key exchange. Layer 1 ships in weeks.

4
Vulnerabilities
3
Fix Layers
291µs
3-Key Signing
0.059µs
STARK Verify

Table of Contents

  1. ZCash Has a Quantum Problem
  2. Harvest Now, Decrypt Later
  3. The Three-Layer Fix
  4. Layer 1: Wallet-Level PQ (No Protocol Change)
  5. Layer 2: Parallel STARK Proofs (Node Software Change)
  6. Layer 3: Full Replacement (Hard Fork)
  7. Why They're Running Out of Time
  8. The Fix Exists Today

ZCash Has a Quantum Problem

ZCash is the gold standard for blockchain privacy. Shielded transactions hide the sender, receiver, and amount using zero-knowledge proofs. It works. It's elegant. And every piece of it breaks under quantum computing.

Here's what's vulnerable:

Transaction Signatures: Ed25519 QUANTUM-VULNERABLE

Shor's algorithm computes the discrete log in polynomial time. Any quantum computer with ~2,000 logical qubits can forge any Ed25519 signature. Every ZEC transaction ever signed becomes forgeable retroactively.

Note Encryption: Diffie-Hellman Key Exchange QUANTUM-VULNERABLE

Same elliptic curve problem. Shor's breaks it. Every shielded note that was ever encrypted with DH can be decrypted. The “shielded” pool becomes transparent.

Zero-Knowledge Proofs: Groth16 SNARKs QUANTUM-VULNERABLE

Built on BLS12-381 elliptic curve pairings. Shor's breaks the pairing assumption. An attacker with a quantum computer can forge proofs—creating fake shielded transactions that look valid to the network.

Halo 2 (The Planned Replacement): Still Curves QUANTUM-VULNERABLE

ZCash is spending years migrating from Groth16 to Halo 2. Halo 2 eliminates the trusted setup (good), but it's built on Pasta curves (Pallas and Vesta). These are still elliptic curves. Shor's still breaks them. They solved the wrong problem.

The trusted setup was an inconvenience. Quantum is an extinction event for the entire privacy guarantee.

Harvest Now, Decrypt Later

This isn't theoretical. Nation-state actors are recording encrypted blockchain traffic today. Every shielded ZEC transaction is sitting in a database somewhere, waiting for a sufficiently powerful quantum computer to decrypt it.

The blockchain makes this worse than traditional network surveillance. Every ZCash transaction is permanently stored in a public ledger. An adversary doesn't need to intercept traffic in real time—they can download the entire chain at any point in the future and retroactively decrypt every shielded note, forge every signature, and fabricate every proof.

ZCash's entire value proposition is privacy. If that privacy has a retroactive expiration date, the protocol's fundamental promise is broken. Users who chose ZCash specifically for its privacy guarantees—journalists, activists, dissidents in authoritarian regimes, financial institutions with confidentiality requirements—are accumulating quantum-vulnerable records with every transaction they make today.

The harvest window is open right now. Every day that passes without post-quantum protection adds another day of vulnerable transaction history to the chain.

The Three-Layer Fix

We've spent the last year building the post-quantum cryptography stack that ZCash needs. Here's how we'd take ZEC fully post-quantum, in three layers of increasing depth—each independently deployable, each adding a stronger guarantee than the last.

L1
Wallet-level PQ
Ships in weeks
L2
Parallel STARKs
6–8 weeks
L3
Full replacement
3–4 months
0
Hard forks for L1
No governance needed

Layer 1: Wallet-Level PQ

No Protocol Change — Ships in Weeks

DEPLOYMENT: 2–3 WEEKS · NO HARD FORK · NO GOVERNANCE VOTE

This is the fastest path. No changes to ZCash consensus, no hard fork, no governance vote. Any wallet developer can integrate this today.

H33-3-Key co-signatures on every transaction. The wallet signs each transaction with Ed25519 (for current ZCash consensus) AND with H33-3-Key—three independent signature families with nested temporal binding:

The 3-Key signature is stored alongside the transaction. If quantum breaks Ed25519, the Dilithium + FALCON signatures prove the transaction was authentic. Two independent post-quantum families must both be broken to forge the signature. That's not happening.

Kyber-wrapped note encryption. Before transmitting a shielded note, the wallet wraps the DH-derived key in a Kyber (ML-KEM-768) encapsulation. The note is double-encrypted: once with the original DH key (for current ZCash compatibility), once with the Kyber key (for post-quantum protection). Harvest-now-decrypt-later attacks hit the Kyber layer and stop.

Integration: One API call. The wallet calls H33's API:

POST /api/h33-key/sign/3key Signs the transaction with 3-Key (291µs)
POST /api/h33-key/wrap Kyber-wraps the note encryption key

No changes to ZCash nodes. No protocol upgrade. No governance process. A ZCash wallet developer can ship this in 2–3 weeks using H33's existing production API.

Layer 2: Parallel STARK Proofs

Node Software Change — 6–8 Weeks

DEPLOYMENT: 6–8 WEEKS · NODE UPDATE · NO CONSENSUS CHANGE

The Groth16 proof system is the core of ZCash's privacy. Replacing it is Layer 3. But you can protect it now by running STARK proofs alongside Groth16.

Every shielded transaction produces a Groth16 proof (~200 bytes, fast verify, quantum-vulnerable). With Layer 2, the wallet ALSO produces a STARK proof of the same statement.

Groth16 (Current)
FoundationBLS12-381 curves
Trusted setupRequired (Powers of Tau)
Proof size~200 bytes
Verify time~3 ms
Quantum-safeNo
H33 STARK (Layer 2)
FoundationSHA3-256 hashes
Trusted setupNone required
Proof size~18 KB
Verify time0.059µs (cached)
Quantum-safeYes

H33's STARK proofs are hash-based (SHA3-256)—no elliptic curves, no pairings. Shor's algorithm is irrelevant. No trusted setup, unlike Groth16's Powers of Tau ceremony. Verified in 0.059µs cached—50,000x faster than Groth16's ~3ms verify time. The trade-off is size: ~18KB per proof versus Groth16's 200 bytes. That's the cost of post-quantum security.

The STARK proof is stored alongside the Groth16 proof in the transaction. ZCash nodes verify Groth16 for consensus (no change). The STARK proof sits there as insurance.

When quantum arrives: one flag flip. Nodes verify STARKs instead of Groth16. The proofs are already in the chain. No emergency migration. No loss of privacy history.

The engineering work is mapping ZCash's Orchard circuit—spend authority validation, note commitment derivation, nullifier computation—into H33's AIR constraint system. The STARK engine exists. The circuit translation is the work: 6–8 weeks.

STARK-IQ auto-routing selects the right engine: Lookup STARKs for the standard spend/output proofs (precomputable state space), AIR STARKs for the more complex Orchard logic. The wallet doesn't choose—STARK-IQ routes automatically.

Layer 3: Full Replacement

Hard Fork — 3–4 Months Engineering

DEPLOYMENT: 3–4 MONTHS · HARD FORK · GOVERNANCE REQUIRED

Replace Groth16 and Halo 2 entirely with H33 STARKs. Every proof in the system becomes hash-based and post-quantum.

This eliminates:

The trade-off: 18KB proofs vs 200-byte Groth16 proofs. Transaction sizes increase ~90x. On a privacy chain where transactions are already heavy and block times are 75 seconds, this is manageable. The bandwidth cost is real but bounded—and it's a permanent fix, not a band-aid.

The real obstacle isn't engineering—it's governance. ZCash's upgrade process requires community consensus, ZIP proposals, and coordination across wallet implementers. That takes 6–12 months regardless of how fast the code ships.

The alternative: fork ZEC. The code is open source (MIT license). Ship a post-quantum ZCash variant with H33 STARKs as the native proof system. Every ZEC holder with quantum concerns migrates. The market decides which chain carries more value.

Why They're Running Out of Time

ZCash has been working on Halo 2 for years. It's a genuine engineering achievement—recursive proofs without a trusted setup. But it's built on curves. The moment a cryptographically relevant quantum computer exists, every Halo 2 proof ever generated becomes forgeable.

They're spending years solving trusted setup while ignoring quantum. That's like fireproofing a house that's built on a flood plain.

Meanwhile:

The harvest-now-decrypt-later window is open. Every shielded ZEC transaction created today with Groth16 proofs and DH note encryption is a future liability. The on-chain record is permanent. The vulnerability is permanent. Only the protection can change—and that requires action now, not after quantum arrives.

Every day without post-quantum protection adds another day of retroactively vulnerable transaction history to a permanent, public ledger. Unlike traditional network traffic that might be lost, blockchain data never expires and never gets deleted. The attack surface only grows.

The Fix Exists Today

Layer 1 is a production API call. It works right now. A ZCash wallet that calls H33's 3-Key signing and Kyber wrapping is post-quantum at the transaction level in weeks, not years.

Layer 2 adds STARK proofs alongside Groth16—insurance that activates when needed. The proofs accumulate in the chain today and become the primary verification path tomorrow.

Layer 3 replaces the entire proof system. Clean, permanent, no curves.

2.17M
Auth/sec (sustained)
38.5µs
Per authentication
0.059µs
STARK verify (cached)
291µs
3-Key sign+verify

ZCash doesn't need to build post-quantum cryptography from scratch. We already built it. 2.17 million authentications per second. 38.5 microseconds per auth. SHA3-256 STARKs verified in 0.059µs. H33-3-Key signatures across three independent mathematical families. All production. All open for integration.

The question isn't whether ZCash goes post-quantum. It's whether they do it before the harvest window closes.

Links

Make Your ZCash Wallet Post-Quantum

Get your API key and integrate H33-3-Key signing and Kyber key wrapping. Layer 1 protection ships in weeks, not years.

Get Free API Key
API Documentation H33-3-Key Product Page ZK-STARK Proofs

Build With Post-Quantum Security

Enterprise-grade FHE, ZKP, and post-quantum cryptography. One API call. Sub-millisecond latency.

Get Free API Key → Read the Docs
Free tier · 10,000 API calls/month · No credit card required
Verify It Yourself