The Zcash Dilemma: When Privacy Protocols Meet Quantum Migration

Every privacy protocol built on elliptic curve cryptography will eventually face the same question: how do you migrate to post-quantum security without destroying the privacy you had set out to protect?

Zcash is the clearest case study. A protocol that has been built by some of the most sophisticated applied cryptographers in the industry was designed in an era when elliptic curve assumptions were considered safe. Indeed, the architecture that made Zcash pioneering is now the source of a dilemma that has no clear solution.

This problem is not unique to Zcash, however. Any privacy protocol that places encrypted secrets on a public, immutable ledger using classical cryptography will face a similar problem to this.

The Quantum Attack Surface

Google's March 30 paper Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities provided an analysis of the quantum attack surface of elliptic curve-based blockchains [1]. The paper primarily focuses on Ethereum, where Google identified five independent attack vectors spanning account keys, smart contract admin keys, code-level vulnerabilities, Proof-of-Stake consensus, and Data Availability Sampling, all of which are rooted in the elliptic curve discrete logarithm problem (ECDLP) that Shor's algorithm solves [2].

Zcash's Orchard protocol is built on the same class of cryptographic assumption. Its note encryption derives keys from the elliptic curve Diffie-Hellman on the Pallas/Vesta curve cycle [3]. Its Halo 2 proof system relies on an Inner Product Argument whose soundness depends on discrete log hardness [4]. Its spend authorization and binding signatures use RedPallas, a Schnorr-like scheme on the Pallas curve [5]. Its diversified address unlinkability, which Google specifically discusses in the context of Zcash [6], depends on the discrete log relationship between curve points remaining unknown.

The same class of vulnerabilities that Google documented against Ethereum applies across Zcash's entire cryptographic stack: encryption, proofs, signatures, and address privacy. Each depends on elliptic curve assumptions that a cryptographically relevant quantum computer breaks. Google's paper explicitly highlights "Zcash's newest shielded pool's resilience against quantum attacks on protocol parameters" as an area of relative strength [7], but the underlying ECDLP dependency remains across the other components.

The Dilemma

The standard response is that Zcash can migrate. They've done it before in Sprout to Sapling and Sapling to Orchard. Each of these upgrades came with a new shielded pool and an upgraded ZK proving system [8].

But post-quantum migration for a privacy protocol is structurally different from a proving system upgrade. The mechanism that enables a migration is the same mechanism that undermines the privacy it is trying to enforce.

Zcash's architecture includes a safety feature called the Turnstile. It tracks total supply across shielded pools by requiring assets to pass through a transparent intermediary when moving between them [9]. In previous pool transitions, users who moved funds between Sprout and Sapling had to route through a transparent address, exposing their balances in the process [10].

A future migration from Orchard to a post-quantum pool is under discussion and the exact mechanism for how to do this is an open question. But any migration path must solve the same fundamental problem, i.e moving value out of a pool whose cryptographic assumptions are compromised. If the path requires transparency, as previous migrations have, every migrating user's balance becomes public. The privacy they were paying for is destroyed in the process of upgrading it.

This is the dilemma: the upgrade to better privacy may require first sacrificing all existing privacy.

The Design Constraints

Privacy is not the only constraint, a migration design must also carefully navigate a timing problem.

Zcash's spending keys in the Orchard pool are derived from elliptic curve cryptography [3]. A quantum attacker who can solve the discrete logarithm problem can derive spending keys, gaining the ability to spend other people's funds.

During any migration window, two things are true simultaneously: the old pool's keys are quantum-vulnerable, and users need time to move their funds to the new pool.

A long migration window creates a race condition. A quantum-equipped attacker has every spending key and can automate drainage, whereas legitimate users must manually initiate transactions. The advantage favors the attacker. Google's analysis of on-spend attack timing is relevant here: the probability of a successful on-spend attack on Zcash, whose target block time is 75 seconds, is less than one in thirteen hundred [1].

A short migration window which attempts to circumvent the quantum adversaries front-running attack does so by having the old pool frozen and the new pool activated simultaneously. But this risks stranding funds belonging to users who haven't pre-migrated. There is no graceful way to force millions of dollars in shielded value through a transition on a deadline.

The argument here is that these are not implementation details to be solved later. They are structural constraints that any post-quantum migration for a privacy protocol must address. No deployed solution has demonstrated a solution to both simultaneously.

Ongoing Mitigation Efforts

Zcash developers are aware of these constraints and are pursuing alternatives. Project Tachyon aims to eliminate on-chain ciphertexts entirely, which would remove the harvest-now-decrypt-later attack surface for future transactions [11]. Their cryptographers are exploring quantum recoverability techniques that could allow users to re-secure assets under post-quantum conditions without passing through a transparent pool [12].

In a whiteboard session posted on April 3, 2026, @ebfull and @zkDragon walked through a full post-quantum migration plan covering three workstreams [15]. The nearest-term is Quantum Recoverability, a wallet-only update requiring no hard fork that adds post-quantum binding to Orchard note commitments. If a cryptographically relevant quantum computer arrives the pool is frozen and funds are recovered in place rather than routed through a transparent intermediary [15]. For key exchange the team is building a private information retrieval (PIR) registry that lets users share a 32-byte digest instead of a full 1KB ML-KEM public key, decoupling the payment protocol from on-chain size constraints. A prototype is appearing first in a voting protocol with payment integration targeted for summer 2026 [15]. The third cryptographic upgrade is a migration to a recursive proof-carrying-data architecture that replaces IPA with FRI and RedPallas with post-quantum signatures [15], [16].

These are serious research efforts from talented cryptographers, but they face real world challenges. The strategies being contemplated are unproven at protocol scale. They require cryptographic innovations and social consensus that have not been demonstrated in production and must be designed, implemented, audited, and deployed across a network with real user funds. This is a process that historically takes years and can cause implementation errors that can be as dangerous as the threats they aim to prevent.

Even Justin Thaler, who argues most blockchains do not need to rush post-quantum signatures, makes an explicit exception for privacy chains identifying them as the one category where harvest-now-decrypt-later attacks create real urgency. He writes: "The exception as of today is privacy chains, many of which encrypt or otherwise hide recipients and amounts. That confidentiality can be harvested now and retroactively deanonymized once a quantum computer can break elliptic-curve cryptography" [13]. But he also warns that rushing a migration introduces implementation risks that may be worse than the quantum threat itself in the near term, recommending that teams "prioritize implementation security" over quantum threat mitigation [13]. This is the trap. Urgency is real, but so is the danger of moving too fast.

The question is whether a protocol with billions in shielded value is willing to bet on a migration process that may or may not produce a successful result before quantum hardware reaches cryptographic relevance. Balance this with the fact that every year of delay is another year of ciphertext accumulating on a public ledger under classical encryption.

What Migration Cannot Fix

Even if Zcash executes a flawless migration, i.e. where every user successfully moves to a quantum-safe pool, no funds lost, no race conditions exploited, three categories of damage are permanent:

• Retroactive decryption of note payloads: This attack requires both a CRQC and the possession of the target's payment address. Without the address, Zcash's shielded transactions are completely indistinguishable on-chain [14]. The specific vulnerability is the ECDH key exchange used in Zcash's in-band secret distribution [3] whose security depends on elliptic curves. A quantum adversary who breaks the key exchange can decrypt note payloads to reveal transaction amounts and memos, but only for addresses they already possess before the migration completes. A nation-state that has collected payment addresses through surveillance, subpoenas, or exchange KYC records can pair those addresses with decrypted note payloads to reconstruct transaction histories. Since the ciphertext is already on-chain, cannot be recalled and will be available to a quantum adversary. This targeted deanonymization requires off-chain identification paired with a CRQC and is not blanket decryption of all on-chain data.
• Historical counterfeiting: Zcash's Halo 2 proof system relies on an Inner Product Argument whose soundness depends on discrete log hardness over the Vesta curve [4]. A quantum computer breaks this assumption. With soundness compromised, an attacker could in theory construct valid-looking proofs for false statements, including proofs that claim ownership of funds that do not exist. Though the practical gap between a theoretical soundness break and successfully minting undetectable tokens in production involves significant additional engineering.
• Address linkability: Zcash allows users to generate unlimited diversified addresses from a single viewing key, so that no observer can tell whether two addresses belong to the same person. A quantum computer derives the incoming viewing key from any diversified address, linking all of a user's addresses together and destroying pseudonymity for every address ever created under the old key structure. Google's paper specifically discusses this vulnerability in the context of Zcash, classifying it as an attack on confidentiality via "attacks on unlinkability of diversified addresses" [6]. The spending key is not recovered through this attack vector resulting in deanonymization without enabling theft, but the privacy damage is permanent.

Privacy Has a Problem

This is not just a Zcash problem. Every privacy protocol built on elliptic curve cryptography will eventually face some version of this dilemma. The specifics vary of course. Different proving systems, different encryption schemes, different migration architectures, but the structural problem is the same.

For most blockchains, "migrate when the time comes" is a reasonable position. Digital signatures can be upgraded. Historical transactions remain secure. The damage model is forward-looking.

Privacy protocols are different. The damage model is backward-looking. The encrypted data is already on a public ledger, the proofs are already committed and addresses are already linked to keys. Migration protects the future but cannot repair the past.

The industry needs to reckon with a difficult question: is post-quantum migration even possible for protocols where the surface area for attack begins before a CRQC arrives? Or does the architecture of a privacy protocol on public ledgers require quantum safety from the start?

Start building on Bonsol today:

Website | Docs | GitHub | X | Telegram | Discord