Quantum-Resistant Horizen, Part 1: The Chain and the Ecosystem

This is the first post in a series where we lay out Horizen Labs' roadmap for migrating our infrastructure to quantum-resistant (QR) cryptography. We start with the Horizen protocol - the chain and its ecosystem - and we will follow up with separate posts on Horizen Labs as an organization and on zkVerify.

Why we are writing this

At Horizen Labs we take quantum security seriously. We started by considering our own security posture, then we understood that there is a real urgency, and a dangerous lack of attention on the problem of quantum security, especially in the Web3 world. So we decided to make our knowledge available to help other companies navigate the tricky waters of post-quantum readiness.

The quantum security business we built avoids expensive pitfalls for enterprises who don’t really know where to start yet, by focusing on an initial assessment setting the path for a tailor-made transition. That assessment is what we call a Quantum Threat Assessment (QTA), and I'll say more about what it is (and what it deliberately is not) below.

The short version: before you spend six months and a small fortune producing a Cryptographic Bill of Materials that might or not be accurate and actionable enough to be actually useful, you should figure out where to look first. We ran a QTA across three domains (Horizen Labs the company, the Horizen protocol, and zkVerify) and this series reports what we found and what we plan to do about it.

We are not the first in this space to publish a quantum roadmap, and that's a good thing: Ethereum, Polkadot, and other serious infrastructure players are treating this as a concrete engineering problem with fork targets. We want to add our voice (and our plan) to that conversation.

A disclaimer before we start: this is a roadmap, not a solution. Several of the items below are open problems. The goal of this post is to map them honestly, prioritize them, and commit to investigating them, not to pretend we have all the answers today.

What is Horizen, and how does it work today

Horizen has been around since 2017 as ZenCash, and it has changed shape more than once. It started as an independent proof-of-work chain with strong privacy, expanded over the years through Zendoo (a zero-knowledge sidechain protocol) and EON (an EVM sidechain), and has recently completed a migration into the Ethereum landscape (this was the first time a live chain was migrated successfully this way). In its current incarnation (what you see referred to as Horizen 2.0) the ZEN token lives as an ERC-20 on Base, with the original 21-million cap preserved.

The architecture today is the part that matters for this post. The Horizen protocol is composed of three parts:

1. Horizen Vela: our confidential compute environment, the privacy engine (you may also see it referred to internally and in older material as the Horizen CCE, Confidential Compute Environment, PES (Privacy Execution System), or simply "the TEE". They're all the same thing).
2. Horizen Chain: an L3 chain that anchors to Base, which in turn settles to Ethereum.
3. The ZEN token and its claim path: ZEN itself is an immutable ERC-20 smart contract on Base, accompanied by an immutable contract that lets holders claim Horizen 1.0 ZEN by presenting an elliptic-curve signature. Flag the word immutable now, because it comes back to bite us in the threat model: a contract that can't be upgraded and that verifies EC signatures is, by construction, a surface you cannot migrate in place.

Concretely, Horizen Chain operates as an OP Stack L3 rollup. It publishes its transaction data and state commitments to Base's data-availability layer, and by finalizing on Base it inherits Ethereum's security and finality implicitly, through Base. So the trust stack, bottom to top, is: Ethereum (L1) -> Base (L2) -> Horizen (L3). The rollup itself is operated through Caldera's Rollup Engine (Caldera provides rollup-as-a-service, and their stack is built on the OP Stack). Cross-chain liquidity and messaging run through Stargate V2 / LayerZero.

The whole pitch of Horizen is privacy with compliance and auditability: privacy that institutions and regulators can rely on. That dual requirement (confidential by default, but auditable by authorized parties) is what drives the design of Vela.

What runs on Horizen, and a closer look at Vela

The ecosystem is growing: a five-year developer funding program is seeding privacy-first applications across DeFi, identity, and confidential data use cases. But the flagship application, and the one most relevant to a quantum discussion, is our own: Vela.

Here is how Vela works today. A user submits an encrypted request to the on-chain Horizen Vela smart contract. The application's WASM logic and its encrypted state are loaded from the Data Layer and handed to the Secure Processor Manager, which orchestrates execution inside a Trusted Execution Environment (TEE). The TEE acts as a stateless executor: it takes the encrypted input, runs the dApp logic, and produces a new encrypted state, along with a list of encrypted events and withdrawals. Crucially, it also produces a TEE-signed attestation confirming that the computation ran on verified hardware using authenticated code.

That attested payload (previous state root, new state root, encrypted events, withdrawals, and the TEE signature) is committed back on-chain. A contract called the TeeAuthenticator then performs an on-chain verification of the TEE's signature. This is the important part: we already verify a TEE signature on-chain, in Solidity, today. The compliance side works analogously: an AuthorityRegistry gates who may request de-anonymization, and every de-anonymization event is itself recorded on-chain for auditability.

Today, the TEE is AWS Nitro Enclaves, running on EC2. And this is where the first concrete quantum exposure shows up, but to explain why, I need to talk about the threat model.

The threat model today

What does Horizen rely on to be secure right now? Roughly, these assumptions:

• Ethereum (L1) is not compromised - its consensus and its cryptography hold.
• Base (L2) is not compromised - and, transitively, its settlement to Ethereum is sound.
• The Horizen L3 / OP Stack rollup behaves correctly - sequencing, state commitments, and the fraud-proof / settlement machinery operate as designed (this includes Caldera's operation of the rollup).
• Standard cryptographic assumptions hold - the hardness of the elliptic-curve problems underpinning ECDSA/BLS, the collision-resistance of the hash functions in use, and so on.
• The TEE is not compromised - AWS Nitro's hardware root of trust is sound, the enclave measurements (PCRs) are trustworthy, and the attestation signature is unforgeable.
• The cross-chain layer (LayerZero / Stargate V2) behaves correctly - bridge messages are authentic.

There are honest-majority assumptions baked into the underlying chains too (Ethereum's and Base's consensus), and there is a non-trivial trust placed in AWS as a hardware vendor. The whitepaper is upfront that the TEE-centric design is a pragmatic choice for delivering confidential compute today, with a longer-term vision of moving toward pure cryptographic guarantees (STARKs, MPC, verifiable computation over encrypted data).

The threat model tomorrow

Now consider the scenario when a cryptographically-relevant quantum computer is finally built, and we might not even know it exists.

That second clause is the one people skip, and it's the one that does the most damage.

What is genuinely at risk.

Public-key cryptography. Shor's algorithm breaks the elliptic-curve and RSA problems, which means: ECDSA (user wallets, the Nitro attestation signature, which is ES384 over P-384), BLS (Ethereum's validator aggregation), KZG-style commitments, and the asymmetric handshakes in TLS. This is the real exposure, and it is everywhere in the stack.

What is not meaningfully at risk, despite what you'll read.

Symmetric encryption and hash functions. The standard line is "Grover's algorithm halves your security bits, so AES-128 becomes AES-64, panic". This is wrong in practice: Grover's quadratic speedup does not parallelize the way Shor-relevant attacks do; the time and physical resources required are absurd, and the "halve the bits" figure is a worst-case theoretical bound, not an operational attack. AES-128 and SHA-256-class primitives are fine. So when we triage, we do not burn cycles worrying about our symmetric crypto, we save the energy for the public-key surface, where the actual fire is.

And now the part I keep banging on about: harvest-now-decrypt-later (HNDL) is not the only urgent threat, and arguably not even the most urgent one. The reflexive industry mantra - "HNDL is the emergency, signatures can wait, because signatures aren't subject to retroactive compromise" - does not survive contact with reality, for two reasons.

1. First, signature migration is usually more painful than encryption migration. Long-lived certificates, code-signing and firmware-signing keys, hardware with verification logic baked in, device fleets you can't easily reach, these are objects that are painful to migrate. For systems like Horizen, Ethereum, and Base, the signature surface (wallet keys, validator/consensus signatures, the TEE attestation key, bridge message authentication) is exactly the part that hurts.
2. Second, and more seriously: a quantum forgery capability is a dark threat. "Retroactive" presupposes you can observe the trigger: the arrival of the quantum adversary. But that capability is precisely the thing an adversary keeps secret. A quantum forgery is operationally indistinguishable from a key exfiltration, a library bug, or a plain classical break. You might see a forged attestation, a drained contract, a bogus validator signature, and you would have no way to attribute it to quantum cryptanalysis. There is no alarm bell: reactive migration against an unobservable trigger is impossible. You have to migrate before the trigger, because you will never see that trigger.

Just to be clear: I am not claiming that Trust-Now-Forge-Later (TNFL) is always more urgent than HNDL. The relative urgency is context-dependent. What I am claiming is that TNFL is badly underestimated, and for a system whose security rests on a chain of signatures and attestations, it deserves at least as much of our planning attention as confidentiality does. For Horizen specifically, both matter: the encrypted state and events are an HNDL target, and the attestation/consensus signatures are a TNFL target.

How we plan to work: two directions

Our migration philosophy splits cleanly along a single axis: does the fix depend on us, or on someone upstream?

(a) Things we control.

Where the cryptography is ours to change (Vela's own algorithms, our smart-contract verifiers, our own signing), we plan the action and execute it. This is worth stating plainly because it's a common misconception: even if Base and Ethereum go fully quantum-resistant beneath us, that does not automatically migrate our contracts. Any contract whose own logic verifies a classical signature stays vulnerable until we change it: the security of the layers below says nothing about the signature scheme our application code chooses to trust. And where that contract is immutable, "change it" isn't even on the table: the only options are to deprecate and replace it, or to wrap it behind something we can upgrade. That constraint needs to be identified early, which is why it lands in the Phase 1 inventory below.

(b) Things we don't control.

We do not get a say on when Ethereum finishes its quantum-resistant transition, or whether AWS adds PQC support to Nitro attestations, or when Caldera/OP Stack ship quantum-resistant primitives. For these, we do three things in order:

• (b1) Document and request. Write the issue up clearly and ask the upstream component to act, or to publicly commit to a migration pathway and timeline.
• (b2) Find a replacement. If (b1) is unsatisfactory (no commitment, or a timeline that doesn't work for us) we look for an alternative provider or design that we can control.
• (b3) Flag the limitation. If neither works yet, we explicitly mark the issue as an open, ongoing limitation awaiting a viable migration proposal.

This framing matters because it's easy to conflate upstream progress with your own readiness. We'd rather tell you plainly: here's what we'll fix, here's what we're waiting on, and here's what we'll do if the wait gets too long.

The Horizen Chain Considerations

Now the specifics. Several of these are genuinely open; they enter the roadmap as investigation items, not solved problems.

The Caldera / OP Stack dependency.

Horizen Chain runs on Caldera's Rollup Engine, which is built on the OP Stack. So quantum-resistance at the chain layer is, in large part, a (b)-type dependency: Caldera has to add QR support, and Caldera's ability to do so may itself depend on the OP Stack roadmap, which in turn tracks Ethereum. This is a chain of upstreams, and we'll be working it with documentation-and-request (b1) as the first move. Notice, however, that Horizen is an optimistic rollup, and the OP Stack's fault-proof mechanism is not a cryptographic proof scheme, but simply a re-execution of the disputed step on L1 in case of a dispute, with integrity resting on the honesty and data-availability guarantees of the layers below (and on hash commitments, which are symmetric primitives and therefore quantum-safe). So, at the chain layer, our quantum exposure is *purely* the signature surfaces (discussed below), not the proof system. With one caveat: the ecosystem is increasingly moving to ZK proofs pushed onto OP Stack chains for faster finality. If Horizen ever moved to a validity-proof model, that proof system would become a quantum-relevant surface, and we'd have to address it at that point.

Two levels of signatures.

As in any such system, there are (at least) two distinct signature surfaces, and they have different constraints:

• User / wallet account signatures. These are produced by people, who cannot be assumed to perform careful key-state management.
• Consensus / sequencer / validator signatures. These are produced by infrastructure operators, who can be expected to maintain state carefully.

This distinction drives scheme choice, and Ethereum's own roadmap is instructive here. The current Ethereum plan (per Vitalik's February 2026 roadmap and the Ethereum Foundation's PQ work) is as follows:

• For users / EOAs, the plan is signature agility via account abstraction (EIP-8141 is the relevant proposal, targeted around the second half of 2026 for consideration), plus a PQ-signature-verification precompile. Rather than mandating one user scheme, accounts opt into a PQ scheme without a disruptive network-wide "flag day".
• For validators / consensus, BLS aggregation is slated to be replaced by leanXMSS (a stateful hash-based scheme) with a minimal zk-based VM handling aggregation, since hash-based signatures are larger and aggregation needs to be restored for scalability.

The underlying rationale is: hash-based, stateful-ish schemes are well-suited to validators who can be trusted to manage state, whereas users need the flexibility (and the don't-shoot-yourself-in-the-foot safety) of agility.

For Horizen, the question becomes: how do these choices propagate down from Ethereum -> Base -> Caldera/OP Stack -> Horizen, and what, if anything, must we do at the L3 level versus inherit? That mapping is a Phase 1/Phase 2 investigation.

The sequencer and the upgrade keys.

The OP Stack sequencer is a single centralized actor; there is no validator-set aggregation to worry about at the L3 level today. Batches are posted to L1 by a single batcher EOA (its address lives in the L1 SystemConfig contract), signing with ordinary ECDSA. That batcher key is one quantum-exposed signature surface, but its compromise is a liveness/censorship concern bounded by the usual rollup escape hatches, not a way to forge state, and migrating a single operator-controlled key is about the easiest remediation on this whole list.

The more interesting target is upgrade control. Chain and contract upgrades are gated by smart-contract roles assigned to Gnosis Safe (multisig) addresses, which means the security of the whole system's upgradeability ultimately rests on a set of ECDSA keys. A quantum adversary able to forge against those keys could authorize a malicious upgrade, and that is the TNFL worry. The good news is that this is also where the ecosystem is already moving: Optimism has published its own PQ roadmap (a ~10-year deprecation of raw ECDSA EOAs in favor of PQ-aware smart accounts, a commitment to migrate sequencer infrastructure, and validator-level alignment with Ethereum). So for Horizen this is largely a (b)-type item (track and align with the Superchain timeline) with one (a)-type action firmly in our court: making sure our own upgrade multisigs migrate to PQ-capable signing on whatever schedule the tooling allows. Confirming exactly which roles map to which Safes, and what their migration path looks like, is a Phase 1 inventory item.

The Vela Frontier: verifying a quantum-resistant attestation

Here's the one that's most ours, and most interesting.

Vela's security rests on the TEE attestation signature being verified on-chain. Today that attestation is an AWS Nitro document: a CBOR-encoded object, signed with ES384 (ECDSA over P-384), with the KMS-side recipient encryption using RSAES-OAEP-SHA-256. Both of those are classical public-key crypto, and vulnerable to Shor’s algorithm. So the attestation chain is squarely a TNFL exposure - and remember, a forged attestation is exactly the kind of dark, unattributable event I described above.

The central question for Vela is therefore: can we verify a quantum-resistant signature emitted as a TEE attestation? This decomposes into two sub-problems.

1. Can the TEE even produce a PQC attestation? Does AWS Nitro support PQC attestation signatures? If so, which schemes? If not, are there alternatives - another TEE framework, or eventually a move away from vendor-hardware trust altogether (the Horizen whitepaper's longer-term VCOED/STARK direction)? This is a (b)-type dependency on AWS: we document and request (b1), and in parallel we begin scoping alternatives (b2). One thing working in our favor: the protocol already supports enclave rollover and re-attestation by design, which is exactly the mechanism you'd lean on to swap in a PQC-capable (or non-Nitro) TEE without disrupting dApp state.

2. Once we have a PQC attestation, how do we verify it on-chain? This is the (a)-type part (it's ours to solve) and there are several routes:

• (a) Native Solidity. Can the verification be done in Solidity today, for some PQC scheme? If yes, we write our own verifier. This depends heavily on the scheme (hash-based and lattice-based verification have very different gas profiles) and "can it be done" and "can it be done affordably" are different questions. Investigation item.
• (b) A precompile. If native Solidity is impractical (too expensive, or missing primitives), is there a precompile we can use? If not, can Caldera add one for us, or can we implement one for Caldera? This dovetails neatly with Ethereum's own "PQ-sig-verification precompile" direction, so there's a real chance the ecosystem converges here.
• (c) A bridge-based verifier. Alternatively, verify the PQC attestation off the critical path and bridge the result in. Simple, but the naive version is centralized, which is philosophically wrong for a privacy/trust-minimization protocol.
• (d) A bridge to a distributed verification network. The interesting version of (c): use a bridge that merely forwards the attestation to a purpose-built, distributed verification network. And here we have a natural candidate - zkVerify, where we are already lead contributors to the code. Adding a connector for PQC-attestation verification on zkVerify would be comparatively straightforward for us, and it keeps verification decentralized. This is, frankly, the option I'm most excited to investigate, but I'm flagging it as an option to investigate, not a decision.

Again: the goal of this post is not to pick (a) through (d) today. It's to commit to evaluating them.

The boring-but-important bits: RPC and Subgraph

Two pieces of infrastructure that don't make the headline but will absolutely bite us if ignored.

RPC nodes. The RPC endpoint (the one provided via Caldera) is how applications and users actually talk to the chain, and that connection runs over TLS. We need to verify whether that RPC TLS supports PQC key exchange (hybrid ML-KEM or otherwise), and if it doesn't, remediate or request it upstream. This is the HNDL-relevant corner of the stack - TLS session data harvested today could be decrypted later - so it's not optional.

Subgraph / indexing. Indexing (in our case via Goldsky) is not, strictly, a mandatory protocol service - but in practice it's crucial for almost every real application. So it gets the same treatment: assess its cryptographic exposure (transport security, any signing) and route findings through the (b) process.

Proposed roadmap

The single most important design principle for this roadmap: we are a downstream consumer of upstream PQC, not a producer of it. Almost none of the heavy cryptographic lifting is ours: it belongs to Ethereum, Base/the Superchain, AWS (or a TEE successor), and the NIST standards. Our job is to be ready to consume each upstream ingredient the moment it ships, and not a moment before. Migrating to immature crypto early can add more risk than it removes.

So this roadmap is deliberately pull-based, pegged to external milestones, with end-2029 as the target for "ready to flip the switch." The anchor is Ethereum's L1 PQ timeline, which on current drafts (strawmap.org, pq.ethereum.org) sketches roughly seven forks through 2029 at a ~6-month cadence, with the PQ-relevant ones sequenced as: a PQ key registry (I*), PQ signature-verification precompiles (J*) (the one that matters most for us) then PQ attestations + leanVM (L*) and PQ aggregation + PQ blobs (M*). We assume that by end-2029 the external ingredients we depend on are in place: Ethereum L1 PQ upgrades substantially delivered, Base/the Superchain tracking them (Optimism has committed to migrate sequencer infra and align validator-level changes with Ethereum), at least one production TEE supporting PQC attestation, and NIST standards stable. If those slip, we also slip with them, by design. If they accelerate (the EF explicitly flags AI-accelerated R&D as a compression risk), we can pull milestones forward because the prep work is already done.

Milestone 1: Assess & Inventory (H2 2026)

Goal: know exactly what we have and what we're waiting on.

• Complete the protocol/Vela cryptographic inventory: every signature and KEM surface, classified by who controls it (a-type vs b-type) and by HNDL vs TNFL exposure.
• Pin down the immutable-contract surfaces (ZEN ERC-20, the 1.0 -> 2.0 EC-signature claim contract) and confirm whether the claim path is time-bounded or indefinite - these can't be migrated in place, only deprecated/wrapped, so they need the earliest visibility.
• Map upgrade-control: which roles map to which Gnosis Safes, and who holds them (HL vs Caldera vs shared).
• Establish the upstream dependency register and open the (b1) conversations: file/track PQ-readiness asks with Caldera, AWS (Nitro/KMS PQC attestation roadmap), and the bridge stack (LayerZero/Stargate), and subscribe to the Ethereum/Superchain fork cadence.

Milestone 2: Track, Standardize & Prototype (2027)

Goal: de-risk the things we can do cheaply and reversibly, and turn upstream uncertainty into concrete requirements.

• Publish our "ideal requirements" doc for the underlying layers (what we need from Ethereum -> Base -> Caldera/OP Stack to inherit PQ security cleanly) and feed it into the relevant forums. We could do this e.g. by publishing EIPs.
• Harvest the HNDL low-hanging fruit that doesn't depend on anyone: ensure PQC-hybrid TLS (ML-KEM) on our own RPC/data-layer endpoints as soon as Caldera/our infra supports it; this is the harvest-sensitive surface, so it goes first.
• Stand up an off-chain prototype of a PQC attestation verifier (against whatever PQC schemes a candidate TEE or simulator can emit), to learn the gas/proof economics before committing to an on-chain route, without yet shipping anything to mainnet.
• Begin upgrade-multisig migration planning aligned to the Superchain's ECDSA-EOA deprecation track.

Milestone 3: Build the Verification Path (2028)

Goal: have a working, tested on-chain PQC attestation verifier, gated on the J* precompile.

• Track Ethereum's J* (PQ sig precompile) and decide our verification route on the evidence gathered in M2: native Solidity vs precompile vs bridge-to-zkVerify. (The J* precompile materially changes the cost calculus, which is why this decision waits for it.)
• Implement and testnet the chosen verifier as a migration of the existing TeeAuthenticator (not a greenfield build). Notice, this is the most distinctively-ours engineering deliverable.
• If a PQC-capable TEE exists by now, run end-to-end attestation -> verification on testnet; if not, keep the verifier scheme-agile and the (b2) alternative-TEE evaluation live.
• Ship at least one real PQC primitive upgrade somewhere non-critical on mainnet (a genuine production rehearsal, low blast radius).

Milestone 4: Integrate & Rehearse (H1 2029)

Goal: everything works together on testnet; only the upstream "go" signal is missing.

• Full dress rehearsal on testnet: PQC TEE attestation verified on-chain, PQC-hybrid transport throughout, upgrade multisigs on PQ-capable signing, bridge messaging on its PQ path.
• Execute the immutable-contract endgame: deploy PQ-aware replacement/wrapper for the claim path and any other immutable EC-signature surface, with a migration/sunset plan for the old ones.
• Final (b3) ledger: anything still blocked on an upstream that hasn't shipped is explicitly documented as a known limitation with its dependency named.

Milestone 5: Cutover (H2 2029 -> ready end-2029)

Goal: flip the switch in lockstep with Ethereum/Superchain PQ availability.

• As each upstream ingredient lands (Ethereum PQ forks, Base/Superchain propagation, production PQC TEE), promote the corresponding tested component from testnet to mainnet.
• Complete the consensus-/upgrade-key migration in step with the Superchain timeline.
• Declare Horizen QR-ready when the last dependency clears. Targeted for end-2029, explicitly contingent on the external stack being there.

Where this leaves us

If I had to compress the whole post into a few sentences: Horizen's quantum exposure is concentrated in its public-key and signature surfaces - wallet keys, consensus/validator signatures, the TEE attestation, bridge messages, and TLS - and not in its symmetric or hash primitives. The most distinctively-ours problem is verifying a quantum-resistant TEE attestation on-chain, and we have at least four credible routes to investigate, one of which (zkVerify) plays to our strengths. The most uncomfortable problems are the upstream dependencies (AWS, Caldera, OP Stack, Ethereum) where our best near-term move is to document, request, and, where necessary, be ready to replace.

We don't have all the answers yet. What we do have is an honest map of the open questions and a commitment to work them in priority order, in public, and we'll report progress as we go.

Next in this series: the Quantum Threat Assessment applied to Horizen Labs the organization, and after that, zkVerify.