Short of a published inventory. The 2026-07-20 roadmap names exact primitives for the TEE attestation surface (ES384 over P-384, RSAES-OAEP-SHA-256) and states the symmetric posture explicitly (AES-128 and SHA-256-class primitives treated as adequate), and the Vela repository README names its four classical key families outright. Against that, the roadmap's own Milestone 1 (H2 2026) is 'complete the protocol/Vela cryptographic inventory', so the chain says the inventory does not yet exist; no CBOM or per-layer signature-and-KEM register is published; and the post's attestation prose does not distinguish the AWS-controlled P-384 document signature from the secp256k1 signature the contract actually recovers or from the registered P-521 ECDH key. The roadmap's present-tense framing reads as though the attestation primitives are live and the P-521 key is registered and rotated on-chain. The chain's own documentation refutes that reading: Vela is deployed to no testnet or mainnet, so those primitives are named here as source-level. No BW6 pairing curve exists in the legacy library's curve directory, and its documented argument system uses a dlog polynomial commitment, so the specific deployed curve instantiation is not established from a public artifact.

Every signing and public-key encryption primitive in the stack is Shor-breakable; every hash and symmetric primitive is Grover-weakened only. The chain publishes its own coarse classification, splitting Shor-broken public-key surfaces (ECDSA, BLS, KZG-style commitments, TLS handshakes, RSA) from symmetric and hash primitives it deprioritizes, and framing the attestation-signature surface as trust-now-forge-later rather than harvest-now-decrypt-later. That classification is per-family, not per-primitive per-layer. Two tags rest on direct evidence: the legacy Zendoo SNARK is tagged discrete-log rather than pairing-based, since the documented construction uses a dlog polynomial commitment with no trusted setup, and the P-521 key is tagged as an ECDH key-agreement key rather than an ECDSA signing key, confirmed by the absence of any signing function on that key in the package. Vela primitives are tagged prospective, because the component is deployed on no public network.

Zero PQ-safe families deployed, which the v3.1 rubric scores at 0. The only PQ family Horizen names for itself is lattice-based key encapsulation, ML-KEM per FIPS 203, in hybrid TLS, announced and unselected. The hash-based leanXMSS lineage appears in the roadmap only as a description of Ethereum's validator plan that Horizen would inherit, and Horizen states it has no validator-set aggregation at the L3 layer today. Deployed diversity is zero and no second family is committed.

No NIST PQC-categorized primitive deployed. Classical primitives sit at standard classical strength with zero margin against Shor: secp256k1 near the 128-bit classical level, P-384 and SHA-384 at the 192-bit level, P-521 at the 256-bit level, RSAES-OAEP-SHA-256 at whatever modulus AWS KMS issues. Symmetric and hash primitives (AES, Keccak-256, SHA-256) retain roughly half their bits against Grover, which the chain's own roadmap treats as adequate.

Library provenance: the Zendoo zk-SNARK library is Horizen's own Rust code, archived; the recursive-SNARK library it depends on is archived with a last push in February 2024; the legacy mainchain client is a Bitcoin/Zcash-lineage C++ fork, also archived. Vela is in-house Go implementing AES, NIST P-521, secp256k1 and X25519, with no lattice, hash-based or code-based primitive file present. The on-chain Nitro attestation verifier is a fork of a third-party Solidity prover, stated as such in the repository's own README, so a security-critical verifier in the stack is externally authored and locally maintained. Post-relaunch the chain inherits Base and OP Stack tooling and Caldera's rollup engine. Poseidon is an algebraic hash at Tier 4 cryptanalytic maturity per the v3.1 tiering. The chain's public roadmap page records 'Token Claim Security Audits' in Q2 2025 for the migration contracts; no published third-party audit of the Zendoo library or of Vela was found, and no machine-checked formal verification is published.

The pre-relaunch ZEN proof-of-work chain used Bitcoin-style P2PKH and P2SH outputs over secp256k1. Post-relaunch, ZEN is an ERC-20 on Base and the Horizen L3 is an EVM chain, so every account reveals its secp256k1 public key implicitly on its first signed transaction. Two operationally critical keys are permanently exposed by design: the OP Stack batcher externally-owned account that posts batches, signing with ordinary ECDSA, and the Gnosis Safe multisig keys that gate chain and contract upgrades. All actively transacting accounts are Shor-forgeable.

The chain's own roadmap dates the project to 2017 as ZenCash, giving roughly nine years of balance accumulation before the migration. Quantified from public state rather than estimated: the ZendBackupVault claim contract on Base holds 1,498,115.07 ZEN unclaimed, 7.13% of the 21,000,000 ZEN supply, at Base block 50,192,679 on 2026-08-19; the EON vault holds zero. The chain's documentation confirms that the contract's balance is by construction the unclaimed total at any given time, so the figure is read directly rather than inferred. The balance is falling slowly as holders claim, so it is reported with its block anchor rather than as a fixed quantity. Redemption is not uniformly gated by a legacy secp256k1 public key and signature. The contract also exposes a direct-claim path requiring no legacy signature, for outputs derived deterministically from a Base address, so that portion is gated by a Base ECDSA secp256k1 account key instead of a legacy one; either way the gating key is ECDSA secp256k1 and Shor-forgeable, so exposure is unchanged. The claim window is not time-bounded in the deployed contract, and the roadmap's own remediation is scheduled for H1 2029. Quantifying the dormant balance improves the evidence, not the exposure.

All historical Schnorr signatures and dlog-commitment Zendoo SNARK proofs on the legacy sidechain certificate path, all secp256k1 ECDSA on the legacy mainchain, and all secp256k1 ECDSA on Base and the Horizen L3 are post-Shor forgeable. Nothing in the stack carries a PQ attestation layer, and the roadmap's own framing is that a quantum forgery would be operationally indistinguishable from a key compromise or a classical break, so there is no observable trigger for reactive migration.

Legacy node peer-to-peer transport used Bitcoin-style encryption over libsecp256k1 and AES. The live harvest-now-decrypt-later surface today is transport: RPC and data-layer TLS on a single Caldera-operated endpoint, plus Base and Ethereum transport below. The roadmap names TLS as 'the HNDL-relevant corner of the stack' and commits to verifying or obtaining hybrid ML-KEM key exchange there at its 2027 milestone; that commitment is conditioned on Caldera or the underlying infrastructure supporting it and has no code. Vela's own confidentiality primitives (RSAES-OAEP-SHA-256 at KMS, X25519 key agreement, a registered NIST P-521 ECDH key, AES) are present in source but deployed on no public network, so they are a prospective rather than a current harvest surface; the roadmap itself names the RSA layer as Shor-vulnerable. No hybrid PQ KEM is deployed anywhere. The live transport exposure is classical and unmitigated.

Pseudonymous transparent ledgers on both surfaces: the ZEN ERC-20 on Base and the Horizen L3, whose blocks and transactions are readable through the Caldera-operated explorer. The legacy mainchain was transparent by default but did run a Zcash Sprout shielded pool, deprecated and drained before the relaunch (see 3e). Vela would offer encrypted-state computation inside a TEE, but the chain's own documentation states it is not deployed to any testnet or mainnet environment, so it contributes no transaction-graph protection today.

Scored on measured evidence. (i) The Horizen L3 has a single public RPC endpoint, operated by Caldera, listed as exactly one entry against chain ID 26514 in the public chain registry, and the roadmap refers to it in the singular as 'the RPC endpoint (the one provided via Caldera)'; concentration is effectively 100% against a rubric that scores zero above 70%. (ii) The chain runs an OP Stack rollup with a single centralized sequencer, so there is no independent gossip entry point and ordering is sequencer-controlled; partial credit only for a public explorer and public JSON-RPC. (iii) No validator or operator metadata retention policy is declared for the L3, for the Caldera endpoint or for the Goldsky indexer, which scores zero by rule. The ZEN ERC-20 side inherits Base's broader public RPC provider set, which does not offset the L3's single endpoint.

The legacy-to-ERC-20 claim path creates a permanent, one-way on-chain link between each legacy ZEN address and its new Base address: the claim contract emits an event carrying the claimer, the destination Base address and the 20-byte legacy address. Beyond that, ZEN is wrapped as a LayerZero OFT adapter for movement between Base and the Horizen L3, with deployment records published for both mainnet targets, so cross-chain ZEN movement depends on LayerZero and Stargate V2 message authentication. Standard Base bridges apply below that. Linkability between legacy holders and migrated holders is high and irreversible for every claimant.

Shor on secp256k1 reconstructs every private key behind the legacy mainchain, the Base ERC-20 and the Horizen L3, and on the legacy Zendoo path breaks the Schnorr signatures and the dlog polynomial commitments underpinning the Coboundary Marlin and Darlin proofs. Historical Zcash Sprout shielded transactions on the legacy mainchain rest on classical public-key primitives with no PQ confidentiality, so their unlinkability is not durable against a future quantum adversary. Poseidon-based commitments provide no PQ confidentiality by themselves, being a hash rather than an encryption layer.

The legacy Horizen mainchain did run a shielded pool: ZenIP-42204, created 2023-01-04, is titled 'Deprecating the Mainchain Shielded Pool' and proposed preventing shielding at consensus level, describing the technology as Zcash's Sprout; ZenIP-42207, created 2024-01-04, proposed complete removal, records that it builds on the deprecation path enacted by ZenIP-42204, and states that roughly 26,000 ZEN, about 0.18% of circulating supply, remained in the pool. It is sometimes stated that shielded functionality was never enabled in mainline ZEN, which the chain's own improvement proposals refute. The pool was deprecated and drained before the relaunch, and no on-chain mixer, shuffle or commit-reveal layer exists on Horizen contracts today.

No shipped-agility credit. What is genuinely demonstrated is architectural agility within classical cryptography at the network level: the legacy proof-of-work mainchain was frozen by hard fork at block 1807300 on 2025-07-23 and deprecated at block 1872068 on 2025-11-13, and the replacement L3 produced its genesis block on 2025-11-17 at 16:34:43 UTC, retiring the entire Zendoo SNARK construction in the process. What is not demonstrated is contract-level agility. The TeeAuthenticator contract does implement a four-step, owner-gated and attestation-verified rotation of the enclave signer address and its registered P-521 key, with an event recording the old and new values, but the chain's own documentation states Vela is not deployed to any testnet or mainnet environment, so this mechanism has never run on a public network and is source-level agility only. Written but not built: a design document specifies moving the three Vela contracts to UUPS upgradeable proxies per ERC-1822 with EIP-1967 storage slots, and states plainly that all three are currently deployed as plain non-proxied contracts. The chain identifies the immutable claim contract as its own agility blocker with a dated H1 2029 remediation. No PQ-specific agility mechanism exists anywhere.

The account-abstraction-plus-PQ-signature-verification-precompile path is described in the 2026-07-20 roadmap as Ethereum's plan, with the relevant proposal named as EIP-8141, a frame-abstraction proposal that the registry confirms is Draft, Standards Track Core, created 2026-01-29 and dependent on EIP-7702, targeted for consideration in the second half of 2026. The roadmap then asks how those choices propagate down to the L3 and books the answer as a Phase 1 or Phase 2 investigation. It designates no Horizen user-migration path. On capability, a direct test settles it: EIP-7702 is not available on the Horizen L3 because the chain is pre-Isthmus, shown by its latest block header carrying the empty-trie withdrawals root and no requests hash, while the L2ToL1MessagePasser storage root is a different, non-empty value; under Isthmus those two would coincide. Base, where the ZEN ERC-20 and the claim contract live, carries a populated withdrawals root and a requests hash and does expose the EIP-2537 precompile, which the Horizen L3 does not. Contract-account patterns work on any EVM chain, but no key-rotation primitive exists at the user-account layer on either surface, and no PQ account path is documented anywhere. Recorded without scoring effect: the upstream OP Stack operator's published roadmap does commit the Superchain to PQ-aware smart accounts, but Horizen has not adopted the fork that would make that path available on its own chain.

Multiple coordinated consensus changes on the legacy chain, documented through the ZenIP process and the client's own release notes, including the sidechain platform launch and the EON EVM sidechain whose first release was published 2023-10-02. The 2025 migration executed to a published schedule: a transaction-freeze hard fork at block 1807300 on 2025-07-23 around 04:30 UTC and mainchain deprecation at block 1872068 on 2025-11-13 around 06:00 UTC, both stated in advance in the client release notes published 2025-07-01, with the replacement L3 genesis on 2025-11-17, inside the Q4 2025 window the chain's own roadmap page advertised. The same release notes show the freeze fork was activated on testnet first, at block 1700420 around 2025-06-16, before mainnet. No contested forks. The relaunch deprecated the legacy chain outright, heavy-handed but coordinated.

No hybrid classical-plus-PQ composition is deployed or specified. The single hybrid intention Horizen states for itself is hybrid ML-KEM TLS on its own RPC and data-layer endpoints at the 2027 milestone, and the roadmap conditions it on Caldera or the underlying infrastructure supporting it first, with no combiner construction, no specification and no code. On the signature side the roadmap commits only to implementing and testnetting a verifier for some future PQC attestation as a migration of the existing TeeAuthenticator, with the scheme unnamed and the route decision explicitly deferred to the 2028 milestone pending an Ethereum PQ signature-verification precompile. Part of the attestation chain, the AWS-controlled ES384 document signature, is outside Horizen's unilateral control. Minimal credit for a named hybrid intention on a surface Horizen at least partly controls.

No stateful hash scheme deployed. Default 15/15 per the v3.1 rule. leanXMSS appears in the roadmap as a description of Ethereum's validator plan, not as a Horizen scheme selection, and Horizen states it has no validator-set aggregation at the L3 layer. If Horizen were later to inherit a stateful hash-based validator scheme from upstream, state-management scoring under this sub-score and the Stage-5 ninety-day state-management operational-record prerequisite would apply.

The Horizen L3 has no signature aggregation at consensus: the roadmap states the OP Stack sequencer is a single centralized actor, that there is no validator-set aggregation to worry about at the L3 level today, and that batches are posted by a single batcher externally-owned account signing with ordinary ECDSA. The chain's Shor-exposed aggregation therefore sits two layers below, in Ethereum L1's BLS12-381 consensus, which Horizen inherits through Base and cannot change. Re-confirmed here: Horizen is sometimes credited with declaring a PQ aggregation path of its own, citing leanXMSS with a zk-based aggregation VM; the roadmap presents that as Ethereum's plan. Horizen declares no aggregation path of its own, and the rubric scores an undeclared path at zero. Flagged for consolidation with the rubric text that governs it: the v3.1 4f rule directs that chains using non-aggregating signature schemes at consensus score N/A with the weight redistributed across 4a to 4e, and a single-sequencer rollup with no validator set arguably falls inside that carve-out, which would raise Dim 4 materially and would also disapply the 4f Stage-5 cap. Scoring it as declared-nothing is the conservative reading and is carried here rather than resolved during a verification pass. Not scored, so it is left out of the dimension total rather than counted as a zero.

Zero. No PQC primitive appears in mainnet signing traffic on the legacy chain, on the ZEN ERC-20 on Base or on the Horizen L3.

No PQ primitive in the legacy mainchain client, the legacy sidechain SDK, the migration contracts or the post-relaunch stack. At code level, a GitHub code search across the organization's indexed repositories returns zero results for each of quantum, leanXMSS, ML-KEM, ML-DSA, SLH-DSA, post-quantum, Dilithium, Kyber, Falcon, XMSS, SPHINCS and lattice, against control queries in the same repositories returning 83 for secp256k1, 96 for TeeAuthenticator and 37 for ECDSA, which is what makes the zeros meaningful rather than an artefact of a broken query. Direct file reads confirm the same conclusion where search does not reach: Vela's crypto package contains exactly AES, NIST P-521, secp256k1 and X25519 key files and no PQ primitive file, and the repository README lists those four families explicitly. The scope limit is recorded in the source-disagreement block: code search does not index archived repositories, and every legacy cryptographic repository here is archived, so those codebases are covered by file reads rather than by search.

No PQ keys are registered by any operator. The legacy chain was proof-of-work with no validator key registration. The Horizen L3 has a single sequencer and a single batcher externally-owned account signing with classical ECDSA, and upgrade control rests on Gnosis Safe multisigs over classical ECDSA keys. The only rotatable operator key in the codebase, the Vela enclave signer address and its registered P-521 key, is classical on both halves and belongs to a component the chain's documentation states is deployed on no testnet or mainnet.

Voided per the v3.1 rule: 5a = 0, so milestone publishing earns no credit until some mainnet PQC traffic ships. Recorded for reference: the 2026-07-20 roadmap publishes five named, dated milestones, being Assess and Inventory in H2 2026, Track, Standardize and Prototype in 2027, Build the Verification Path in 2028, Integrate and Rehearse in H1 2029, and Cutover in H2 2029 targeting ready end-2029. None is protocol-enforced and the plan states it is pull-based, pegged to external milestones, and that if upstream slips Horizen slips with it by design. Milestone-delivery track record relevant once 5d unlocks: the chain's own roadmap page advertised a Confidential Compute Environment for Q1 2026 and a builder-preview privacy product for Q4 2025, and the chain's documentation states that component is not deployed to any testnet or mainnet environment as of.

Five PQ commitments announced in the trailing twelve months with a shipped count of zero, so the ratio exceeds the 1.5 threshold and the 10-point Dim 5 deduction lands here. No narrative-only tag: the post is explicitly self-critical, stating that this is a roadmap and not a solution, labelling several items open problems, describing the organization as a downstream consumer of upstream PQC rather than a producer of it, warning that migrating to immature crypto early can add more risk than it removes, and claiming nothing as shipped. The announced-versus-shipped gap is disclosed by the chain itself.

No PQ signature is deployed on any Horizen surface and no per-block signature-footprint multiplier or benchmark is published, which the rubric scores at zero. No aggregation credit is carried: the leanXMSS-with-zk-aggregation model sometimes cited here is Ethereum's plan as reported in the roadmap, not a Horizen aggregation plan, and Horizen states it has no validator-set aggregation at the L3 layer to aggregate. No PQ transaction-weight de-penalization is documented either.

Legacy wallet estate, archived: the project's own desktop and mobile wallets, a Trezor integration and earlier wallet clients, all carrying archived status in the organization's repository list. One migration-era Ledger signing tool for the claim path remains unarchived. Post-relaunch, holders use standard EVM wallets on Base and the Horizen L3. No wallet in either estate publishes a Horizen-specific PQC roadmap, and the 2026-07-20 roadmap does not list wallet vendors among the dependencies it tracks.

Three distinct bridge surfaces, all classical. The legacy-to-ERC-20 claim portal is Horizen-operated and one-way, verifying secp256k1 signatures on its signature-bearing paths. ZEN is wrapped as a LayerZero OFT adapter, with deployment records published for Base mainnet, Base testnet and the Horizen mainnet and testnet targets, so cross-chain ZEN movement depends on LayerZero and Stargate V2 message authentication, which the roadmap itself lists as an upstream dependency it can only request action from. Standard Base bridges apply below that. No PQC roadmap on any of them.

ZEN is held at centralized exchanges and custodians on both the legacy chain and Base. No Horizen-specific PQC migration timetable is published by any custodian, and the roadmap does not list custodians among the dependencies it tracks. Specific institution names are not carried, because none was verified against a primary source.

The infrastructure dependencies are named precisely, which raises the specificity of the exposure without raising readiness. The trusted execution environment is AWS Nitro Enclaves on EC2, with attestation documents signed under ES384 and verified against a hardcoded AWS Nitro Enclaves Root-G1 CA certificate, and KMS recipient encryption under RSAES-OAEP-SHA-256, all classical; the chain's own documentation states this component is not deployed to any testnet or mainnet environment, so it is a prospective dependency rather than a live one. The live infrastructure dependencies are the L3's single Caldera-operated RPC endpoint and rollup engine and a single third-party subgraph indexing service. The roadmap flags AWS Nitro's own PQ attestation migration, plus Base and the Superchain, Caldera and the LayerZero bridge stack, as external dependencies it can only document and request action on. No PQ attestation or transport roadmap for the AWS Nitro, Caldera or indexing dependencies could be located from a primary source; the upstream rollup-stack roadmap covers account and sequencer signatures, not these tiles.

The legacy chain was proof-of-work with a documented four-way block-reward split of 20% treasury, 10% super nodes, 10% secure nodes and 60% miners, giving a stake-like operator tier; an earlier claim that its mining concentration was modest is unsupported and stays dropped. The current chain is materially more concentrated, not less: the roadmap states the OP Stack sequencer is a single centralized actor, batches are posted by a single batcher externally-owned account, chain and contract upgrades are gated by Gnosis Safe multisigs, and a single provider operates the RPC and rollup engine. Settlement-side decentralization is inherited from Base and Ethereum, three and two layers below, and is not Horizen's.

The migration itself executed to published block heights and dates: transaction-freeze fork at block 1807300 on 2025-07-23, mainchain deprecation at block 1872068 on 2025-11-13, L3 genesis 2025-11-17, all inside the windows the chain's own roadmap page advertised, and with the freeze fork rehearsed on testnet in June 2025 first. The EON sidechain shipped its first release in October 2023. No contested forks. The deduction is driven by the confidential-compute slip: the chain's public roadmap page dates that environment to Q1 2026 and a builder-preview privacy product to Q4 2025, and the chain's own documentation states the component is not deployed to any testnet or mainnet environment, roughly seven months past the advertised date, while the roadmap page still lists it as forward-looking, does not mention the product by its current name, and carries a prior-year copyright notice.

A named, credentialed lead owns PQC specifically: Tommaso Gagliardoni, Head of Cryptography and Quantum Security at Horizen Labs, with a published mandate in the form of the five-milestone roadmap and a stated background covering a doctorate on the quantum security of cryptographic primitives, a postdoctoral position at a corporate research lab, a cryptography tech lead role in industry, and publications at the major cryptography conferences. General chain leadership remains with Horizen Labs. The team's standing engagement with the cryptographic research community is corroborated independently of Horizen's own claims by a Silver-tier sponsorship listing for the 2026 flagship European cryptography conference on a page the academic association controls, alongside four other Silver-tier sponsors. The improvement-proposal repository was last updated in April 2024, which on its own reads as a dormant process. The process is live and has moved venue, with approved proposals going to token-holder votes on an off-chain snapshot platform under published quorum and majority thresholds. The finding that no PQC-related improvement proposal exists is scoped to the repository, which returns zero hits for quantum; the voting spaces were not enumerated.

The legacy proof-of-work chain suffered a 51% attack in 2018, and the team responded by shipping a delayed-block-submission penalty into the mainchain client: a fork-choice rule that assigns a growing delay penalty to any chain whose blocks arrive more than five blocks behind the active chain height, holding back its acceptance until it catches up. The mechanism is present in the client source with a 2018 copyright, with the threshold constant set to five and the penalty computed from the height difference. The fix is sometimes described as Modified Satoshi consensus checkpoints, which the source code does not support. This is genuine crisis-response coordination under active attack, but on fork choice rather than on a cryptographic primitive, and it predates any quantum consideration.

No published rate-limit canary, no cryptographic tripwire, no equivalent early-warning mechanism. The 2026-07-20 roadmap introduces none, and its own threat-model section argues that a quantum forgery would be unattributable and would fire no alarm, which makes the absence of a tripwire more consequential rather than less.