Zcash publicly names every primitive in active use across transparent and shielded pools, and ZIP 2005 now publishes a canonical per-primitive enumeration of exactly what breaks under a discrete-logarithm attack (commitment binding, proof soundness, signatures, note encryption, pool by pool).

Every signature, every shielded-proof soundness, and every note-encryption KDF input remains classical-EC; no NIST PQC primitive is deployed on mainnet. The two points credit the one genuine change: Ironwood's note-commitment recoverability binding (BLAKE3 H^qk, BLAKE2b H^rcm) is the first consensus-level Zcash construction whose quantum posture rests on hash security with a published QROM analysis rather than on discrete logs. That binding protects future recoverability of value only; it signs nothing and encrypts nothing.

0 PQ families on mainnet. All deployed primitives are EC-DL or pairings-based; symmetric primitives weakened by Grover. Cryptographic-Diversity Cap (lattice-monoculture) does not apply because no lattice family is deployed either.

ECDSA-secp256k1 ≈ 128-bit classical, broken by Shor (no NIST PQ category); Jubjub/Pallas/Vesta ≈ 128-bit classical, Shor-break; BLS12-381 ≈ 128-bit classical, Shor-break-via-pairings. No deployed primitive maps to a NIST PQ category 1-5.

NU5 (the halo2-based Orchard deployment) was reviewed by NCC Group and QEDIT at both specification and implementation levels, with no serious or critical issues reported. A community grant application (2026-03) to formally verify the five Orchard circuit gadgets and ZIP 224 in Lean 4 ($201,600 / 18 months) was declined (2026-05), so it earns no credit; what does stand is the dedicated first-party Ironwood formal-verification repository (Lean 4), active and in progress. constant_time: librustzcash/zebrad build field and point arithmetic over Pasta on the subtle constant-time trait ecosystem. library_provenance: zebrad (Zcash Foundation Rust node), librustzcash, halo2, orchard, zcash_note_encryption crates. Counterweight: ZIP 258 records that zcashd does not implement NU6.3, so full-validator provenance narrows from two independent implementations to one (Zebra only) at the same upgrade. Cryptanalytic tier: Tier 1-2 (ECDSA classical; Halo 2 IPA Tier 3 research-grade in proof-system terms).

Transparent ZEC pool uses ECDSA-secp256k1 with full pubkey reveal at spend (P2PKH). Mempool reveal is observable. Shielded spends do not reveal a public key per se, but the spending authorization signature is RedDSA over Pallas (Orchard) or RedJubjub (Sapling), both classical-DL, Shor-forgeable. Reused transparent addresses and any Sapling/Orchard spend lose forgery resistance post-Shor; ZIP 2005's own enumeration adds that a single discrete logarithm on the relevant curve suffices for Balance and Spend-authentication attacks against a shielded pool.

Shielded cold value gained a first shipped mitigation path: Orchard notes migrated into the Ironwood pool (NU6.3, mainnet 2026-07-28) carry a BLAKE3-derived recovery commitment that a future Recovery Protocol could use to restore value after a discrete-log break. The protocol itself is outline-only, so there is nothing to invoke today: dormant migrated value remains spendable, and Shor-forgeable, under the classical RedPallas path until a Recovery Protocol ships and the classical protocols are switched off. The point of movement is that recoverability of migrated cold notes is now a shipped mainnet property, not a proposal. Sapling-pool notes get no recoverable format, and per ZIP 318 migration residuals up to 0.01 ZEC per wallet stay permanently on the pre-Ironwood format. Transparent-pool cold exposure is unchanged (unmoved ZEC at P2PKH/P2SH under ECDSA-secp256k1 dating back to the 2016-10-28 launch), narrowed only by ZIP 2005's confirmation that P2PK and bare-multisig scripts were never supported by Zcash wallets, so the exposed-from-creation transparent bucket is smaller than Bitcoin-style analysis assumes.

Every historical Zcash signature back to genesis 2016-10-28 is forgeable post-Shor: transparent ECDSA, Sapling RedJubjub, Orchard RedDSA-Pallas, Sprout Ed25519. No SNARK-rescue mechanism is currently architected.

Node-to-node gossip is the Bitcoin-derived cleartext P2P protocol: there is no transport encryption at the peer layer to harvest or to hybridize. Light-client links (lightwalletd gRPC) and operator RPC endpoints ride standard classical TLS. No hybrid PQ KEM deployed anywhere in the stack.

CRITICAL. Every shielded note from 2016 onward is a ChaCha20-Poly1305 ciphertext blob stored on-chain, with the symmetric key derived via ECDH on classical curves (Curve25519 for Sprout, Jubjub for Sapling, Pallas for Orchard and Ironwood) with BLAKE2b KDF. A future quantum adversary running Shor can decrypt historical shielded note ciphertexts, recovering note value, recipient diversifier, and memo field, for any shielded receiver address known to the attacker: ZIP 2005's own exposure enumeration conditions the note-plaintext privacy break on a known receiver address, and address knowledge is broad by design (every sender knows the address they paid, and addresses are published or held by exchanges), so the exposure is wide but not unconditional. Ironwood explicitly does not change the recipient-facing encryption scheme, and ZIP 2005 confirms note-plaintext privacy breaks for any current shielded pool, Ironwood included. The 'ML-KEM in active testing' framing for note encryption has no primary source behind it: a code search of the ZIP corpus returns no ML-KEM, ML-DSA, SLH-DSA, Dilithium, Kyber, or Falcon reference (zero results for all six), and the successor project's own proof-system core is ECDLP-based. What remains creditable is the announced ciphertext-removal concept (oblivious synchronization) as a structural mitigation direction, with active R&D code but no PQ note-encryption KEM announced, on testnet, or on mainnet.

Shielded pool (Orchard) hides sender, recipient, and amount via zk-SNARK proofs. Transparent pool exposes graph fully. Shielded-to-transparent boundary leaks amounts. Privacy is strong but optional at the protocol level: shielding is not mandatory, and a transparent pool remains part of consensus and in active use.

(i) Top-3 RPC: ECC/ZODL-operated and Zcash Foundation nodes, plus YWallet/Zashi-bundled servers. No published fraction; community-operated nodes exist. (ii) Mempool gossip: Bitcoin-derived cleartext gossip protocol, observable to peers; a Tor transaction-relay ZIP is in progress (open proposal in the ZIP repository, not shipped), and wallet-level Tor protection shipped in the first-party Android wallet 3.9.0. (iii) Node metadata retention: still no formal declared policy, but the sole full-validator client's 6.3.0 release shipped a peer-metrics design that deliberately excludes peer IPs and raw user agents as labels, a concrete, public metadata-minimization posture.

Zcash's native cross-chain swap surface is recent and small: THORChain merged Zcash support into its node software in stages (chain plumbing 2025-10-24, main integration 2026-03-03, ZEC trading fixes 2026-04-21), with native ZEC swaps live from spring 2026, and the THORSwap front-end states it has offered native ZEC cross-chain swaps since 2025-10-01 (integration-date divergence disclosed in source_disagreement). Swaps are non-custodial without wrapping; shielded-to-transparent unshield is required to enter swap liquidity, leaking that amount and timing. No mainstream wrapped-ZEC bridge in production.

CRITICAL FINDING. Halo 2 IPA over Pallas/Vesta is discrete-log-secure, not PQ-secure. A future quantum adversary breaks the soundness of every historical Orchard proof (enabling forgery; the proofs themselves stay zero-knowledge) and breaks the Diffie-Hellman-based public-key encryption protecting every Sapling/Orchard note ciphertext for any shielded receiver address known to the attacker, per ZIP 2005's own enumeration. Because address knowledge is broad by design (counterparties, published addresses, exchange records), the practical result is retroactive de-anonymization of shielded payments reaching back to the 2016-10-28 launch, wide but conditioned on address knowledge rather than unconditional. The Sapling protocol layer adds a second exposure: BLS12-381 pairings + Groth16 are also Shor-broken. The successor project's oblivious-synchronization design is the only mitigation under discussion, research-staged, no testnet.

No structural mix-network. The shielded pool itself is the anonymity set (commit-reveal-style anonymity via zk-SNARK), but is not a mix-network with cover traffic. No cMix-class IT-secure shuffling. Off-chain wallet-side mitigation is wallet-policy-level, not protocol-level: the first-party wallet's default behavior, including the transparent-address rotation feature on the developer organization's Q4 2025 roadmap (new transparent address after each receive).

Every Sapling/Orchard/Ironwood note is encrypted with ChaCha20-Poly1305 keyed via ECDH on classical curves (Jubjub or Pallas; Curve25519 for legacy Sprout notes) with BLAKE2b KDF, stored on-chain with indefinite retention; X_priv is effectively unbounded for everything already posted, with post-Shor decryption conditioned on the attacker knowing the receiver address (broad by design). Ironwood changes note-commitment binding, not note encryption. The 'ML-KEM active testing' framing for note encryption has no primary source behind it: no hybrid PQ note-encryption KEM is announced, on testnet, or on mainnet anywhere in the reviewed material, and no NIST PQC primitive is named anywhere in the ZIP corpus. The remaining credit is for the announced ciphertext-removal research direction (oblivious synchronization) only, which would protect future notes, never the ones already on-chain.

Zcash has now demonstrated three shielded-pool cryptosystem transitions across four generations: Sprout (BCTV14 zk-SNARK over BN-254, later migrated to Groth16/BLS12-381) → Sapling (Groth16 + BLS12-381 + Jubjub, NU2, activation block 419,200, 2018-10-29 UTC) → Orchard (Halo 2 IPA + Pasta, NU5, activation block 1,687,104, 2022-05-31) → Ironwood (quantum-recoverable note format, NU6.3, mainnet block 3,428,143, 2026-07-28). Each was a hard fork via the Network Upgrade Pipeline; NU6.3 is the first in that pipeline's history executed specifically to change note-format cryptography for a quantum-risk reason, and it activated eight weeks after the preceding consensus upgrade (on-chain timestamps 2026-06-03 and 2026-07-28). Hot-swap without hard fork is still not architected; every cryptosystem transition requires a new shielded pool.

No account-abstraction stack; PoW chain with viewing-keys + spending-keys architecture. What changed: client-layer migration machinery is now deployed with active volume. The first-party Android wallet shipped a guided 'Move to Ironwood' migration (3.9.0, with fixes through 3.9.3) offering a private time-split background transfer or an immediate transfer; an independent hardware wallet shipped dedicated firmware with batch PCZT signing; an open-source wallet SDK shipped a documented migration module; and an independent custodian shipped an Ironwood PSBT/PCZT flow. ZIP 326 further specifies a per-account key-derivation branch (use_qsk, the quantum-spending-key flag, all-or-nothing per account, forbidden before NU6.3 activation), a real spec-level agility primitive, though it selects between two classical derivation modes rather than classical vs a NIST PQC scheme. This is the exact plumbing a future PQ migration would ride; the destination format remains classical, which is why the score is mid-range, not high.

Ten network upgrades executed (Overwinter 2018 through NU6.3 2026-07-28) with no chain split at any activation, most recently NU6.2 (activated 2026-06-03) and NU6.3 Ironwood (activated 2026-07-28), roughly eight weeks apart, both coordinated after the January 2026 mass resignation of the core development team at ECC under the reorganized Zcash Open Development Lab (ex-ECC) plus Zcash Foundation (Zebra) structure. The activation was bracketed by dated node point releases including an activation-day release smoothing the branch-ID transition. The coordination-capacity concern recorded after January 2026 has been answered by execution.

No hybrid PQ deployment ratified. No ZIP proposes co-signing with classical + PQ, and no NIST PQC primitive is named anywhere in the ZIP corpus (code search, zero results). Ironwood demonstrates the chain can run old and new note formats side by side with a live migration path, which is hybrid-adjacent operational capability, but the new format is classical, and the successor project is a structural redesign rather than a hybrid, with its proof-system core ECDLP-based.

N/A by default credit (stateless schemes). All proposed PQ candidates so far (ML-KEM, ML-DSA, hash-based STARK) are stateless. No XMSS/LMS proposal in scope.

Zcash is PoW (Equihash). No BLS aggregation in consensus. Crosslink (a proposed hybrid PoW+PoS finality layer led by an independent ecosystem organization, targeted at a future NU) would change this if shipped, but is in prototype. Per v3.0.1, 4f is N/A for non-aggregating-consensus chains. Excluded from the Dim 4 denominator rather than treated as a zero. Not scored, so it is left out of the dimension total rather than counted as a zero.

Zero. No PQ primitive on mainnet for signatures, KEM, or proof system. NU6.3 Ironwood (activated 2026-07-28) does not change this: everything it ships is built from RedPallas signatures, Halo 2 over Vesta proofs, ChaCha20-Poly1305 encryption, and BLAKE2b/BLAKE3 hashing, a discrete-log-preserving recoverability format, not PQC signing or KEM traffic under the methodology's definition.

No merged PQ code in the Zebra consensus path; the Ironwood code merged for NU6.3 implements the classical-primitive recoverability format, which does not qualify. The successor project's R&D organization holds active, dated repositories (core plumbing implemented and tested per its own README; note commitments, nullifiers, and proof creation explicitly stubbed), but it is a separate pre-production organization, not merged to any mainnet-facing client, and its proof-system core (Ragu) is ECDLP-based, not a PQ-safe construction.

PoW chain, no validators. Mining pools produce blocks via Equihash PoW; there is no consensus signature scheme to upgrade. N/A-equivalent under privacy-focused-chain rubric → score 0 (cannot earn PQ-key-adoption credit on a PoW chain). Not scored: there is no key-holding block producer here, so there is no validator key to adopt. Left out of the dimension total rather than counted as a zero. Post-quantum user-transaction signing is measured in 5a.

VOIDED to 0 per v3.1 (5a = 0). Pre-void context, recorded for the track-record ledger: the May 2026 corporate statement promised quantum-recoverable wallets within a month; NU6.3 wallet support shipped about eleven weeks later (first-party wallet 3.8.0, 2026-07-27, one day before mainnet activation) and the guided migration about thirteen weeks later (3.9.0, 2026-08-08), a slip-but-shipped record. The quantum-proof-by-2027 target has no ZIP, no activation height, and no enforcement mechanism, and the successor project's own page states all network upgrades require community approval before activation.

Announced PQC (trailing 12 months): quantum-proof-by-2027 corporate target with a 12-18 month successor-project timeline (May 2026, two outlets); official successor-project page claiming 'full post-quantum privacy'; ZIP 2005 quantum-recoverability naming; transparent-recoverability open issue; ciphertext-removal R&D framing. Shipped PQC: 0 bytes signed under any named NIST PQC primitive on mainnet. The gap is no longer only a timing gap: the successor's own proof-system core (Ragu) describes itself as an ECDLP-based recursive SNARK, so the 'full post-quantum privacy' framing is ahead of the architecture actually being built, a primary-sourced announced-vs-architected divergence. Offsetting credit: ZIP 2005's own text states plainly that Ironwood does not by itself make Zcash quantum-secure, and names exactly what stays breakable; the engineering-facing documentation remains honest even where the marketing-facing framing is not.

Undisclosed (no PQ signature scheme selected).

Top wallets: Zashi/Zodl (first-party; the developer organization renamed from Electric Coin Company to Zcash Open Development Lab in this window, same continuous repository), YWallet, Keystone hardware. What changed: shipped, dated wallet-side support for the chain's quantum-track upgrade is now real and multi-vendor. The first-party Android wallet shipped NU6.3 support (3.8.0, 2026-07-27) and a guided 'Move to Ironwood' migration (3.9.0, 2026-08-08, fixes through 3.9.3, 2026-08-17); an independent hardware-wallet vendor shipped a dedicated firmware release for the Ironwood upgrade with batch PCZT signing (2026-07-24); an open-source wallet SDK powering third-party wallets shipped documented migration modules and testing strategy. None of this is a PQC roadmap: it is Ironwood (classical-primitive recoverability) support, and no wallet vendor publishes a roadmap naming a NIST PQC primitive. No shielded-pool Ledger support has shipped (Ledger's ZEC support remains transparent-only; the developer organization's own late-2025 post frames the independent hardware vendor as the first hardware path for shielded withdrawals).

Top: THORChain (native ZEC swaps, non-custodial, no wrapping; protocol-level Zcash integration merged 2026-03-03 with ZEC trading fixes through 2026-04-21; the THORSwap front-end states native ZEC swaps offered since 2025-10-01). No mainstream wrapped-ZEC bridge in production. THORChain has no published PQC roadmap; a public THORSwap retroactive grant application for the integration exists (2026-05-13), with funding status not verified.

Top: a tier-1 US custodian (transparent ZEC), Kraken, Binance, Anchorage, BitGo. What changed: BitGo shipped a dedicated Ironwood PSBT/PCZT module with dated commits from mainnet-activation day (2026-07-28) through 2026-08-13, including shielding-transaction signing support, independent custodian-side engineering for the quantum-recoverability format, not an announcement. Still no custodian publishes a ZEC-specific PQ custody or MPC roadmap naming a NIST PQC primitive; a US exchange enabled direct shielded (Orchard-pool) ZEC withdrawals in November 2025, predating Ironwood, with no PQC statement.

RPC: ZF-operated zebrad nodes, ECC-operated zcashd nodes (deprecated), wallet-bundled servers. No major Infura/Alchemy-class third-party RPC. HSM: Ledger transparent-only. No TEE attestation chains specific to Zcash. No PQC roadmap from any.

PoW Equihash. Top mining pools: leading pool ~31-32%, second ~16-19%, third ~7%, fourth ~5% (figures dated 2026-05-01, disclosed in source_disagreement). Nakamoto coefficient ≈ 2-3 by hash rate. Reduced one point for client diversity: ZIP 258 records that zcashd does not implement the NU6.3 consensus changes, making Zebra the only full-validator implementation able to follow the chain from activation onward; full-validator client diversity dropped from two implementations to one at the same upgrade that shipped Ironwood.

Ten Network Upgrades, no chain split at any activation. The cadence evidence strengthened materially in this window: NU6.2 and NU6.3 (Ironwood) activated as consensus-changing mainnet upgrades roughly eight weeks apart (on-chain activation timestamps 2026-06-03 and 2026-07-28), within months of the January 2026 mass resignation of the core development team at ECC, with the activation bracketed by five dated node point releases including an activation-day release. The post-resignation coordination-capacity concern is answered by demonstrated execution; NU7 scope remains unsettled.

Named technical lead is publicly established: the NU6.3 deployment ZIP, the Ironwood quantum-recoverability ZIP, and the wallet-consequences ZIP share a single named owner-author (with a named credited contributor on the recoverability ZIP), with 40+ dated spec commits publicly tracked from late 2025 through past mainnet activation. Corporate lead re-established: Electric Coin Company renamed to Zcash Open Development Lab (same continuous organization and repositories), CEO Josh Swihart, corroborated by two independent outlets and repository metadata. Multi-org structure persists (Zcash Foundation maintains the sole full-validator client but shows no independent public PQC statement on its homepage as of this evaluation, a static-fetch-limited negative finding; an independent ecosystem organization leads the Crosslink finality work; the ZSA shielded-assets ZIPs are owned by a third-party engineering firm), so a single named lead with a published chain-wide PQC mandate still does not exist.

Multiple historical dev-fund disputes (2020 ZIP-1014 process). The January 2026 mass resignation of the core development team at ECC, attributed in contemporaneous community reporting to internal governance conflicts, was a significant adversarial-internal-coordination event; the ecosystem's subsequent shipping of two consensus upgrades within about seven months (NU6.2 activated 2026-06-03, NU6.3 2026-07-28), including the quantum-recoverability upgrade, is a demonstrated recovery-under-internal-adversity precedent and earns one point of movement. Zcash has still not coordinated a crypto change under active external attacker pressure.

None published. No quantum tripwire, no rate-limiting Hourglass equivalent, no canary cell embedded in consensus. The pre-existing ZIP 209 turnstile (shielded-pool value-conservation audit) is cited by ZIP 2005 as the only constraint on an undetected balance violation before the pre-quantum protocols are switched off; it is a value-conservation check, not a rate-limited-spending rule or legacy-key-exposure monitor, and does not meet the 7e definition.