Zcash ZEC

Claim: Zcash has published a comprehensive cryptographic inventory and quantum threat model through the protocol specification, ZIP 2005, and contributor analyses (Sean Bowe, PostQuantum.com).

Coverage basis: Protocol specification, ZIP 2005, Sean Bowe blog post, secondary analyses

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Protocol specification is authoritative and current (2026-05-27). ZIP 2005 explicitly states: 'the note commitment algorithms used by the Sapling and Orchard shielded protocols are not post-quantum binding.' Sean Bowe's analysis is from a core contributor.

One of the most thorough quantum risk self-assessments in the blockchain space. ZIP 2005 explicitly acknowledges all major quantum vulnerabilities including discrete-log attacks on Pasta curves.

• https://zips.z.cash/protocol/protocol.pdf
• https://zips.z.cash/zip-2005
• https://seanbowe.com/blog/zcash-and-quantum-computers/

Claim: Evidence includes protocol specification sections, ZIP 2005 with formal cryptographic analysis, Sean Bowe's technical blog, GitHub issues, and secondary analysis by PostQuantum.com.

Coverage basis: Code references, protocol specification, formal ZIP, contributor analysis, third-party review

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Multiple independent sources corroborate the quantum-vulnerability assessment. Primary specification and ZIP are authoritative. GitHub issues provide historical context.

Evidence is well-organized and publicly accessible. The combination of protocol specification, formal ZIP, contributor analysis, and third-party review provides multi-source verification.

• https://zips.z.cash/protocol/protocol.pdf
• https://zips.z.cash/zip-2005
• https://github.com/zcash/zips/issues/1134
• https://seanbowe.com/blog/zcash-and-quantum-computers/

Claim: All spend authorization uses classical ECC: transparent uses ECDSA/secp256k1, Sapling uses RedJubjub, Orchard uses RedDSA/RedPallas.

Coverage basis: Protocol specification, ZIP 224 (Orchard), mainnet transaction evidence

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All spend authorization remains ECC-only across all address types. No PQC or hybrid-PQC signatures deployed on mainnet.

Assurance: Confirmed by authoritative protocol specification v2025.6.3 and ZIP 2005. No contrary evidence exists.

This is the single most impactful quantum vulnerability. A quantum adversary capable of solving ECDLP could forge spend authorization signatures for any address type, enabling theft of all ZEC.

• https://zips.z.cash/protocol/protocol.pdf
• https://zips.z.cash/zip-2005

Claim: Transparent addresses expose public keys on-spend (P2PKH model with reuse common); shielded addresses use ECC-based key derivation with diversified addresses linked to ECC-derived incoming viewing keys.

Coverage basis: Protocol specification, ZIP 32 (HD wallets), on-chain transparent address reuse patterns

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Transparent addresses follow Bitcoin's P2PKH model with long-exposure public keys. Shielded address derivation depends on ECC assumptions for viewing key security.

Assurance: Transparent pool represents ~69% of supply with fully exposed or derivable public keys per zkp.baby dashboard data (May 2026). Shielded address key derivation confirmed in protocol specification.

Transparent addresses face the same long-exposure quantum risk as Bitcoin. Shielded addresses have additional exposure through incoming viewing keys that are solutions to ECDLP on the relevant curves.

• https://zips.z.cash/protocol/protocol.pdf
• https://github.com/zcash/zips/blob/main/zips/zip-0032.rst

Claim: Zcash is a PoW chain with no validator set, no BLS threshold signatures, no VRF-based leader election, and no finality signatures.

Coverage basis: Protocol design — Equihash PoW with no validator or BLS consensus layer

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Protocol specification confirms PoW consensus with no validator authentication layer.

This is a genuine architectural N/A, not a gap. PoW chains do not have validator signature schemes in consensus.

• https://zips.z.cash/protocol/protocol.pdf

Claim: Nullifiers use quantum-resistant keyed PRFs; note commitments are not post-quantum binding; Halo 2 proof soundness relies on ECC assumptions.

Coverage basis: Protocol specification, ZIP 2005, Sean Bowe analysis

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Note commitments are not post-quantum binding (per ZIP 2005). Halo 2 proof soundness is quantum-vulnerable. A quantum adversary could forge note commitments and break proof soundness.

Assurance: Nullifier PQ resistance is confirmed by Sean Bowe (core contributor). Note commitment vulnerability explicitly acknowledged in ZIP 2005. Proof soundness vulnerability confirmed by multiple independent analyses.

Partial credit for quantum-resistant nullifiers (prevent transaction-graph linking by quantum adversary). However, note commitment binding and proof soundness remain fully quantum-vulnerable, enabling forgery and inflation.

• https://zips.z.cash/zip-2005
• https://seanbowe.com/blog/zcash-and-quantum-computers/
• https://zips.z.cash/protocol/protocol.pdf

Claim: Halo 2 zk-SNARK proofs and note encryption rely on ECC assumptions. Nullifiers are quantum-resistant. Some anonymity properties preserved against quantum adversaries.

Coverage basis: Protocol specification, Sean Bowe analysis, PostQuantum.com analysis

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Note encryption relies on ECC-based key agreement, enabling harvest-now-decrypt-later retroactive deanonymization. Halo 2 proof soundness is quantum-vulnerable.

Assurance: Sean Bowe confirms nullifiers use quantum-resistant keyed PRFs. Partial privacy preservation is credible for anonymity set but does not protect note contents or proof soundness.

Zcash's privacy design provides meaningful partial protection: quantum-resistant nullifiers prevent an adversary from linking spent notes. However, note encryption (amounts, memos) and proof soundness remain fully quantum-vulnerable. The harvest-now-decrypt-later threat is existential for a privacy coin.

• https://seanbowe.com/blog/zcash-and-quantum-computers/
• https://zips.z.cash/protocol/protocol.pdf

Claim: P2P node identity is not consensus, spend, bridge, or custody-critical for a PoW chain.

Coverage basis: Protocol architecture — P2P identity is separate from asset-spending authorization

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Protocol specification describes P2P layer; no evidence of consensus-critical dependency on P2P identities.

Per QRI Section 7, P2P is satisfied by design when P2P node identity is not consensus, spend, bridge, or custody-critical.

• https://zips.z.cash/protocol/protocol.pdf

Claim: No production PQ wallet paths exist. All wallets use ECC-based keys exclusively. V5_Qr is behind unstable feature flag.

Coverage basis: Wallet documentation, V5_Qr unstable feature status, absence of production PQ wallet features

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No production wallet supports PQ or hybrid-PQC spend authorization. V5_Qr is unstable-feature-gated prototype only.

Assurance: V5_Qr is explicitly noted as 'behind the unstable feature' and only affects Orchard change notes. It does not provide quantum-resistant signatures, encryption, or proofs.

The V5_Qr wallet construction-time selector exists in library code behind an unstable feature and only affects Orchard change notes. It is not a production wallet feature and does not provide quantum-resistant signatures.

• https://ethnews.com/zcash-is-building-quantum-recovery-into-its-shielded-protocol/
• https://zechub.substack.com/p/zcash-shielded-news-vol18-128

Claim: Approximately 0% of circulating ZEC is protected from quantum key-recovery attacks. All ~16.7M ZEC across transparent and shielded pools uses ECC-based spend authorization.

Coverage basis: Mainnet pool data (zkp.baby, May 2026), protocol specification

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Less than 25% coverage: approximately 0% of value is quantum-protected. Transparent pool (~11.5M ZEC, ~69%) uses ECDSA/secp256k1. Shielded pools (~5.1M ZEC, ~31%) use ECC-based RedDSA/RedJubjub spend auth.

Assurance: Pool distribution data from zkp.baby (May 2026): Transparent 11,517,447 ZEC; Orchard 4,523,398 ZEC; Sapling 598,945 ZEC; Sprout 25,409 ZEC. All spend authorization is ECC-only per protocol spec.

Even shielded-pool ZEC, while having partial privacy protection (quantum-resistant nullifiers), remains fully quantum-vulnerable for asset ownership due to ECC-based spend authorization.

• https://zkp.baby/
• https://zips.z.cash/protocol/protocol.pdf

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations) have migrated to PQ-protected paths. No PQ-native wallet paths exist.

Coverage basis: Protocol specification, wallet documentation, absence of any PQ wallet deployment

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No critical wallet migration exists or is possible with current production cryptography.

Assurance: Absence of any PQ wallet path confirmed by protocol specification and all available wallet documentation.

Exchanges holding ZEC, the Zcash Foundation, ZODL, and other ecosystem participants all rely on the same ECC-only production stack with no PQ alternative.

• https://zips.z.cash/protocol/protocol.pdf

Claim: All pools are well-identified (transparent, Sprout, Sapling, Orchard). ZIP 2005 identifies which pools can become recoverable. No deprecation, freeze, or migration is live.

Coverage basis: Protocol specification, ZIP 2005, mainnet pool data

Implementation score: 0.5 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: Pools are identified and measurable but no deprecation, freeze, burn, or migration mechanism is activated on mainnet.

Assurance: Pool balances are publicly measurable via mainnet explorers. ZIP 2005 explicitly addresses Orchard recoverability. Sapling requires manual migration to Orchard. Transparent pool has no announced path.

ZIP 2005 explicitly excludes Sapling from recoverability ('To reduce overall protocol complexity and analysis effort, we do not propose a similar change for Sapling'). Transparent addresses have no quantum mitigation plan at all.

• https://zips.z.cash/zip-2005
• https://zkp.baby/

Claim: Zcash has published ZIP 2005 (Orchard Quantum Recoverability), Tachyon project roadmap, and CEO-level public commitments (Consensus Miami, May 2026).

Coverage basis: ZIP 2005, Tachyon repository, Consensus Miami presentation, CoinDesk/Decrypt coverage

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: ZIP 2005 is a formal specification but remains Proposed/Draft. Tachyon is in active development but pre-testnet. CEO roadmap announcements are marketing-level confidence. No activation heights or consensus dates are committed.

The roadmap exists and is public, but is not activated. ZIP 2005 does not define deployment parameters (activation height is placeholder). Tachyon target is 'summer 2026' for initial deployment but full PQ is 12-18 months out.

• https://zips.z.cash/zip-2005
• https://github.com/tachyon-zcash/tachyon
• https://www.coindesk.com/tech/2026/05/08/zcash-to-roll-out-quantum-recoverable-wallets-within-a-month-go-quantum-proof-by-2027

Claim: V5_Qr exists behind unstable feature flag for Orchard change notes only. No PQ account creation, wallet tooling, user-facing warnings, or migration prompts exist in production.

Coverage basis: V5_Qr code in librustzcash, Zodl release notes, absence of production PQ features

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No production PQ/hybrid account creation or transaction path exists for any user. V5_Qr is prototype-level only.

Assurance: V5_Qr is explicitly noted as 'behind the unstable feature' and only affects Orchard change notes. It does not provide quantum-resistant signatures, encryption, or proofs.

The 'quantum-recoverable wallet' announced for June 2026 appears to correspond to this V5_Qr work, which enables wallet-level opt-in to recoverable note construction but does not change the underlying ECC-based cryptography.

• https://ethnews.com/zcash-is-building-quantum-recovery-into-its-shielded-protocol/
• https://zechub.substack.com/p/zcash-shielded-news-vol18-128

Claim: No enforcement mechanisms exist. No deprecation of legacy signing, no restricted withdrawals, no mandatory migration deadlines. No exchange/custody coordination for PQ migration.

Coverage basis: Absence of any enforcement mechanism in protocol specification, ZIPs, or network upgrades

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No enforcement, deprecation, freeze, or mandatory migration mechanism exists. Users can continue creating quantum-vulnerable addresses indefinitely.

Assurance: Protocol specification confirms all legacy address types remain fully operational with no deprecation. ZIP 2005 is voluntary ('wallets SHOULD move').

ZIP 2005 uses SHOULD language, not MUST. No deadline, sunset period, or enforcement mechanism is proposed. Transparent addresses have no migration or deprecation plan whatsoever.

• https://zips.z.cash/protocol/protocol.pdf

Claim: NU6.2 emergency response (June 2026) demonstrates strong general incident-response capability. No formal quantum-specific incident-response process is documented.

Coverage basis: NU6.2 incident timeline, Zcash Foundation governance documentation

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: NU6.2 demonstrates capable multi-stakeholder emergency coordination (disclosure May 29, soft fork June 2, hard fork June 3). However, the NU6.2 incident was a classical soundness bug, not a quantum-specific scenario. No quantum-specific playbook exists.

Per QRI Section 8.2, absence of a formal quantum-specific incident-response playbook does not by itself create a Readiness & Risk Cap. The NU6.2 response suggests the ecosystem can coordinate rapidly when needed.

• https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/
• https://github.com/zcash/zcash/releases/tag/v6.20.0

Claim: No PQC algorithms are deployed in production. Tachyon research is evaluating ML-KEM (Kyber) and ML-DSA (Dilithium) for future use.

Coverage basis: Tachyon repository, CoinDesk research article, ZK14 presentation

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No NIST-standardized or broadly-reviewed PQC algorithms are deployed in production for any critical layer.

Assurance: ML-KEM and ML-DSA are identified as candidates in research materials but no implementation exists in production code. Tachyon's PCS replacement for post-quantum soundness is described as lattice-based but specific algorithm selection is not finalized.

Research-level engagement with NIST PQC standards is a positive indicator, but no production deployment exists.

• https://github.com/tachyon-zcash/tachyon
• https://www.coindesk.com/research/encryption-supremacy-zcash-and-privacy-in-the-age-of-scale

Claim: Zebra NU6.1 audit exists (node software, scope-mismatched for quantum crypto). Orchard circuit received independent review (Taylor Hornby, May 2026) but not PQ-focused. No PQ-specific audit exists.

Coverage basis: Zcash Foundation audit publication, NU6.2 incident report

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: The NU6.1 audit covers Zebra node software, not quantum-critical cryptographic primitives. Taylor Hornby's Orchard circuit review (May 2026) is independent and current but focused on classical soundness, not quantum resistance. No audit covers PQ migration designs.

Per QRI Section 6.4, scope-mismatched audits support only the audited component and limit confidence for the unaudited production scope.

• https://zfnd.org/zebra-nu6-1-audit/
• https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/

Claim: All Zcash protocol code, specifications, and ZIPs are open-source under MIT/Apache 2.0 licenses.

Coverage basis: GitHub repositories, protocol specification, ZIP repository

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: All repositories are publicly accessible with permissive licenses. Protocol specification is versioned and publicly hosted. Tachyon repository is Apache 2.0 / MIT.

Zcash's open-source posture is exemplary. The full protocol specification, all ZIPs, and multiple independent node implementations (zcashd, Zebra) are publicly available.

• https://github.com/zcash/zcash
• https://github.com/zcash/zips
• https://github.com/zcash/librustzcash
• https://github.com/tachyon-zcash/tachyon
• https://zips.z.cash/protocol/protocol.pdf

Claim: ZIP 2005 is explicitly designed to not commit to any particular PQ proving system. Tachyon architecture is designed for PCS swap. Network upgrade mechanism (ZIP 200) exists.

Coverage basis: ZIP 2005, Tachyon ZK14 presentation, ZIP 200

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: ZIP 2005 explicitly states 'No particular choice of post-quantum proving system or commitment tree hash should be assumed.' Tachyon's modular architecture with PCD toolkit is designed for cryptographic agility. These are design-level claims not validated in production.

The network upgrade mechanism (ZIP 200) has been used successfully for multiple upgrades including the recent NU6.2 emergency response, demonstrating practical upgrade capability. However, the PQ upgrade path remains at the design stage.

• https://zips.z.cash/zip-2005
• https://github.com/tachyon-zcash/tachyon

Claim: No stateful PQ signatures are deployed. Tachyon and ZIP 2005 design discussions acknowledge hardware wallet and FROST compatibility considerations.

Coverage basis: ZIP 2005 FROST and hardware wallet sections

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: ZIP 2005 includes detailed analysis of FROST threshold signing compatibility, hardware wallet options (Option A/B for qsk storage), and quantum adversary threat models for custody. This is design-level analysis, not production implementation.

No stateful PQ signatures (XMSS/LMS) are planned or deployed, so anti-reuse controls are not applicable to current design. ZIP 2005's hardware wallet analysis is thoughtful but the Recovery Protocol itself is not implemented.

• https://zips.z.cash/zip-2005

Claim: Tachyon analysis includes preliminary PQ performance estimates (~660 TPS with PQ crypto, ~1.5 KB transaction sizes). CoinDesk research discusses PQ key sizes.

Coverage basis: Messari report, CoinDesk research, ZK14 presentation

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Performance estimates are preliminary and based on projected PQ parameters. No production benchmarking exists. ML-KEM public keys (~800 bytes–1 KB) represent a significant increase over current ECC keys.

The proposed ID-based system for handling large PQ public keys (referencing keys via short hashes with PIR retrieval) is an innovative approach but remains at the design concept stage.

• https://messari.io/report/zcash-building-encrypted-money-at-planetary-scale
• https://www.coindesk.com/research/encryption-supremacy-zcash-and-privacy-in-the-age-of-scale