L1 Blockchain (UTXO with Transparent + Shielded Pools: Sprout [deprecated], Sapling, Orchard [withdrawal-only], Ironwood)

All of the pools on Zcash rely on Elliptic Curve Discrete Logarithm Problem (ECDLP) primitives. Primitives which would break in the presence of a cryptographically relevant quantum computer (CRQC). (1)

Transparent t-address: Transparent address uses secp256k1 ECDSA, which is vulnerable to a CRQC. Any address that has been spent from will have its public key exposed permanently on-chain and be at risk of a CRQC deriving the associated private key. (2)

Sprout (deprecated) utilizes 3 cryptographic primitives which are ECDLP based and would be broken by a CRQC:

• EdDSA over Ed25519 which is utilized for spend authorization

• SHA-256 for note commitments

• Shared Sapling trusted setup which has the same toxic vulnerability as Sapling (3)

Sprout was essentially deprecated through ZIP 211, which was implemented in 2020, which prevented any additional deposits (4). The pool currently has 22,637 ZEC in deposits as of August 3 2026 (5). Additionally, ZIP 2003, which is proposed to be included in NU7, would prevent new spends from Sprout as it disables support for the v4 transaction type, the only remaining transaction type that supports Sprout transactions (6).

Sapling: Utilizes 3 cryptographic primitives which are ECDLP based and would be broken by a CRQC: (1)

• Groth16 over BLS12-381, which proves transaction validity and balance

• RedDSA over Jubjub which authorizes spending and address unlinkability

• ECIES over Jubjub which encrypts note contents to recipients

Additionally, the Groth16 trusted setup produced toxic waste, which can be recovered by a CRQC, which would allow for the creation of a permanent backdoor, which would allow the attacker to inflate the supply in the pool. (2)

Orchard (currently withdrawal only): Utilizes 3 cryptographic primitives which are ECDLP based and would be broken by a CRQC: (1)

• Halo 2 over Pallas/Vesta which proves transaction validity and balance

• RedPallas which authorizes spending and allows for address unlinkability

• DHAES over Pallas which encrypts note contents to recipients

Ironwood (active post NU6.3 upgrade): reuses the same cryptographic primitives as Orchard and shares the same ECDLP based vulnerabilities (7). Ironwood however does include a change to note derivation in which only lead byte 0x03 is accepted for Ironwood note plaintexts, which makes note commitments and incoming viewing key derivation post quantum recoverable assuming an associated recovery protocol is deployed. (8)

Transparent t-addresses use P2PKH and P2SH script types and as such any transparent address that has been spent from has its public key permanently exposed on-chain and vulnerable to a CRQC deriving the associated private key. This applies whether or not a balance remains, so an address that was fully swept and later refunded is still exposed (1). Approximately 12.38 million ZEC, roughly 73% of circulating supply, is in transparent addresses as of August 3 2026 (2).

Shielded addresses (Sprout, Sapling, Orchard, and Ironwood) are vulnerable to privacy-related attacks at rest but not attacks related to fund security. The specific privacy related risk is that if a CRQC knows a recipient's diversified address it could recover the incoming viewing keys via breaking ECDLP which would allow for the attacker to retroactively decrypt historical notes and link addresses. This vector would not expose the target's spending key. Fund security in the shielded pools is preserved unless soundness is also broken, which is addressed under Track 3. (1)

The risk of an on-spend attack is assessed to be very low. Google's Quantum AI paper estimates a success probability of less than 1 in 1,300 due to the blocktime of 75 seconds. (1)

Sapling and Sprout both utilize Groth16 over BLS12-381, which utilizes a trusted setup (4). This trusted setup produced toxic waste (secret scalar), which would allow for a CRQC to extract the scalar and give the CRQC a permanent and reusable backdoor to counterfeit notes (1). The impact of the counterfeiting would be constrained by the ZIP 209 turnstile, a consensus rule that prevents a negative balance in the pools, which would cap the max amount counterfeited/stolen to be the existing balance of the pool (2). A sophisticated attacker could attempt to avoid detection by operating within pool balance limits (3). As mentioned previously, Sprout is deprecated and sends from the pool are slated to be disabled in NU7 (5).

Orchard and Ironwood pools do not have any exposure to this attack vector as Halo 2 does not require a trusted setup.

All shielded pools are at risk to potential harvest now decrypt later (HNDL) attacks. This is due to the fact that all shielded transactions publish an encrypted note ciphertext and an ephemeral public key which is used to derive the associated encryption key (1). The encryption used is quantum-resistant (ChaCha20/Poly1305) but the key itself is derived using ECDH (which is quantum vulnerable) from the recipient's incoming viewing key and private key (2). A CRQC that knows a recipient's diversified address can recover the encryption key and decrypt all historical notes to that address. However, if a diversified address was never shared or exposed there is no ECDLP target for the CRQC. (1)

1. Quantum Recoverability [ZIP-2005, deployed in NU6.3 on July 28, 2026] (1)(3)

2. Quantum Privacy (Project Tachyon and ML-KEM) [research/design phase] (2)

3. Quantum Soundness and Legacy Protocol Shutoff [discussion/research phase] (2)

THREE TRACKS: all three must be complete for Zcash to be genuinely post-quantum.

TRACK 1: QUANTUM RECOVERABILITY (ZIP-2005, Status: deployed Jul. 28, 2026)

ZIP-2005, Ironwood Quantum Recoverability (originally Orchard Quantum Recoverability), implements a rule requiring note plaintexts to use lead byte 0x03. This is a change to how note randomness (rcm) is derived, which makes the note commitment scheme post-quantum binding, and the same change applies to incoming viewing key derivation. While this itself does not make Ironwood notes post quantum it creates the preconditions for a future recovery protocol. A recovery protocol that would allow Ironwood note holders to prove ownership through a hash-based recovery statement rather than Halo 2 (which is quantum vulnerable). The exact recovery protocol itself has not yet been defined, and would need to be implemented prior to a CRQC coming online to offer protection. (1)

TRACK 2: QUANTUM PRIVACY (Project Tachyon and ML-KEM, Status: Research/design, no ZIP filed)

This track addresses Zcash's remaining quantum privacy vulnerability through two efforts, migrating shielded payments to out-of-band secret distribution (Project Tachyon), and replacing ECDH key exchange with ML-KEM, supported by a PIR-based address registry.

Tachyon:

Project Tachyon introduces oblivious synchronization and proof aggregation to scale shielded transactions (2)(3). A required component of this scaling is moving from in-band secret distribution to out-of-band channels. The removal of the in-band ciphertexts eliminates the HNDL attack surface area on note contents. With the idea being that once wallets have migrated, on-chain ciphertexts can be removed from the protocol entirely. Additionally, Tachyon removes ECDH-encrypted note data from the chain but does not replace ECDH as the encryption scheme. ML-KEM or another scheme is required to close the existing vector where a CRQC knowing a recipient's address could still recover the incoming viewing key via ECDLP in the off-chain channel (4)(5). One friction point introduced by Tachyon is that seed phrases alone can no longer be used for fund recovery, and view key sharing or public donation-style addresses would not be available without additional wallet infrastructure.

ML-KEM + PIR-Based Address Registry

This replaces the ECDH key exchange with ML-KEM-768 and introduces a PIR-based address registry and is a wallet level change and does not require a network upgrade. ML-KEM-768 removes the remaining HNDL vector that would allow for a CRQC to recover incoming viewing key and decrypt incoming payments and break address unlinkability. Due to the size of ML-KEM-768 public keys compared to previous keys, the PIR-based address registry is being introduced in parallel which would allow users to register their keys and receive a 32-byte hash as identifier. Senders would retrieve the recipient's full public key via Private Information Retrieval which would prevent the registry from learning which key was queried. (4)

This remains in the research and design phase. No ZIP has been filed and no activation height has been set.

TRACK 3: QUANTUM SOUNDNESS (Halo 2 replacement, Status: Unsolved research problem)

The final track, which has been termed "quantum soundness", addresses the risk associated with Halo 2 quantum vulnerability. Track 3 replaces Halo 2 with a post-quantum recursive SNARK proof system, which removes the risk of proof forgery, note counterfeiting, arbitrary supply inflation, and fund theft by a CRQC.

The replacement proof system has not been selected but LatticeFold+ is the leading research candidate to replace Halo 2 (4). Additionally there is no associated ZIP or activation height set.

Unaddressed: No existing track addresses the risk to funds held in transparent addresses. The only proposed solution so far would require moving these funds to Ironwood shielded pools.

No PQ signature scheme has been definitively selected or deployed yet for mainnet.

1. Quantum recoverability (Track 1): No PQ scheme needed. (1)

2. Quantum privacy (Track 2): ML-KEM-768 under evaluation for note encryption key encapsulation to replace ECDH key exchange. (2)

3. Quantum Soundness (Track 3): LatticeFold+ in discussion to replace Halo 2 proof. (2)

Mar 5 2025: Daira-Emma Hopwood presents Post-Quantum Zcash at ZconVI, public analysis of all three quantum attack vectors. (1)

Mar 31 2025: ZIP-2005, Quantum Recoverability, published by Daira-Emma Hopwood and Jack Grigg. (2)

Apr 2 2025: Sean Bowe publishes Tachyon blog, introduces oblivious synchronization and out-of-band payments. (3)

Apr 28 2026: ZIP-2005 reaches Proposed status. (2)

May 29 2026: Orchard zk-SNARK circuit soundness flaw disclosed privately by Taylor Hornby. Present since Orchard launch in 2022, permitting undetectable counterfeiting. (4)

Jun 3 2026: NU6.2 activates at block 3,364,600. ZIP 257, Orchard Temporary Vulnerability Mitigation. (5)

Jun 6 2026: Tachyon and Valar Group publish the Ironwood proposal. (6)

Jul 28 2026: NU6.3 activates at block 3,428,143. Ironwood pool live, Orchard withdrawal-only, ZIP-2005 recoverable notes deployed at consensus. (7)

Upcoming / Target Dates

2026+: ML-KEM integration targeting Tachyon shielded pool, contingent on PIR registry shipping first. (8)

Post 2027+: No date determined yet for quantum soundness / fully post-quantum.

1. Quantum Recoverability (ZIP-2005): note format deployed at consensus July 28 2026, block 3,428,143 (3). The Recovery Protocol is unspecified and has no date (2).

2. Post-quantum privacy (Tachyon + ML-KEM): No definitive target completion date shared yet.

3. Post-quantum soundness / Fully "Quantum Proof": Likely sometime after 2027. No credible timeline. (1)

Track 1: (Quantum Recoverability) ZIP-2005:

Quantum recoverability went live with the NU6.3 upgrade on Jul. 28, 2026. Users are able to deposit into Ironwood which enforces lead byte 0x03 for all Ironwood-pool note plaintexts. The implementation of the recovery protocol is TBD. (1)(2)

Track 2: Quantum Privacy (Tachyon + ML-KEM):

Tachyon will require one or more future network upgrades. ML-KEM, which requires the off-chain PIR registry infrastructure to ship first, is a wallet level change and does not require a network upgrade.

Track 3: Post-Quantum Soundness and Legacy Protocol Switch-Off:

Track 3 will require one or more future network upgrades which will implement the replacement for the Halo 2 proof system and disable legacy shielded pools. No timeline or activation height has been set.

Zcash protocol changes are governed by the ZIP process and activated at a predetermined block height once node software implementing the upgrade achieves sufficient adoption. Community sentiment polling informs but does not determine inclusion.