Privacy coin leader crashes? Zcash reveals "faked" vulnerability

Author: David Christopher; Translation: Plain Blockchain

This article focuses on the latest disclosed Orchard vulnerability in Zcash: although the issue has been fixed, more troubling is that the vulnerability could allow attackers to forge ZEC within the privacy pool, and the privacy design itself makes it impossible to verify whether fake coins truly appeared in the past. Therefore, the focus of the event is no longer just "fixing a bug," but "rebuilding trust through a system-verifiable approach."

There are three key points worth noting: first, the market will not accept the assumption of "low probability of exploitation"; second, Zcash may need to migrate to a new shielded pool to simulate a "clean slate"; third, formal verification is shifting from an optional enhancement to a fundamental infrastructure at the protocol level. For projects emphasizing complex cryptography and privacy design, this is a very real warning.

Zcash hasn't had a good week.

On May 29, security researcher Taylor Hornby, while using Opus 4.8 to study the protocol for the independent Zcash support organization Shielded Labs, discovered a serious flaw in Orchard—the latest and largest shielded pool in Zcash. He then privately disclosed the issue to Zcash Open Developer Labs (ZODL), one of the core protocol teams, who confirmed and began responding within hours.

Because revealing too many details could be equivalent to handing the attack blueprint directly to potential attackers, the fix was implemented in phases:

June 2: An emergency soft fork canceled Orchard transactions.

June 3: NU6.2 hard fork re-enabled the pool and deployed the modified circuit—which predefines the rules for what constitutes a valid transaction.

On the surface, this looks like a story with a resolved ending: a serious vulnerability was discovered, fixed, and no exploitation was known to have occurred within the known scope.

But a full review of the events published yesterday completely rewrites the nature of this incident.

The review shows that this is actually a "forgery (counterfeit) vulnerability" , which in theory could allow attackers to infinitely mint fake ZEC inside Orchard; even worse, there is currently no way to verify whether this vulnerability was exploited before it was fixed.

Although the relevant team still believes that "the likelihood of the result being exploited is low," in this new context, the story has shifted from "Zcash fixed a bug" to "Zcash fixed a bug that could potentially create fake ZEC in Orchard, and the system currently has no formal way to prove that such an event never occurred."

What is Orchard, and where did the problem occur? Orchard is Zcash's latest shielded pool, a privacy layer that hides information about amounts, senders, and receivers.

Like other privacy systems, it relies on zero-knowledge proofs. Users can prove compliance with system rules without revealing specific details; these rules are embedded in circuits.

This vulnerability has existed since Orchard launched in May 2022, and theoretically could allow someone inside Orchard to forge ZEC and cause the network to treat these fake assets as real. Since Orchard hides amounts and invoices, these forged units could remain in the pool indefinitely without leaving traces on the public chain.

Currently, at least for now, because Orchard is public, people cannot directly review its history or conclusively prove: before the fix, no fake ZEC was ever created.

The team believes "the probability of prior exploitation is low," and this judgment is not unfounded: the vulnerability is deeply embedded, relatively easy to detect, and requires advanced skills to exploit.

But market pricing values not "probability estimates" but "verifiable proof." Until Zcash conclusively proves that no fake ZEC was minted, the protocol is essentially asking users to believe in something that cannot yet be proven.

What happens next? Zcash needs to find a way to either verify that Orchard does not contain excess copies of ZEC or forcibly move accounts into a state where fake ZEC can no longer hide.

Fixes are likely to come from two directions: first, auditing the subsidy; second, making such vulnerabilities harder to overlook in the future.

Regarding auditing, Zcash founder Zooko suggests migrating the current shielded supply to a new Orchard pool. The key mechanism here is "rotation gate auditing": a pool's value limit cannot exceed the boundary of the value that was legally input into it.

If all funds in Orchard are forced through this "rotation gate," then any formatted ZEC will inevitably hit a wall: attempts to surpass the value will exceed the real value that can be proven on-chain, based on previous inflows into the pool. Detailed guidance on this plan is expected next week.

As for the second approach, ZODL's Josh Swihart points to formal verification. Simply put, this involves translating system rules into machine-verifiable forms and then proving that circuits indeed adhere to these rules.

It cannot replace human judgment, but it advances the key issue from "trust that auditors have caught all problems" to "directly prove that key constraints exist."

Zcash currently has two possible paths for correction. One is to develop a new version of Orchard with formal verification as a transitional solution; theoretically, it could target the NU7 upgrade window at the end of July, but no official decision has been made yet.

A longer-term and clearer solution is Tachyon. It is a new generation of shielded protocol currently under design, with a simpler underlying structure and built around formal verification tools.

The goal is clear: reduce the complexity of Orchard, which is highly handwritten and difficult to reason about thoroughly, so that related circuits can undergo stricter validation. Before faster-than-light particles land, a verified Orchard pool could serve as an intermediate bridge.

Welcome to a new phase: Artificial intelligence has begun helping humans discover vulnerabilities in protocols.

The article also mentions that the "baby" (a metaphor for early-stage research) has already been triggered by discussions on how this issue was identified through a prompt-driven process. Regardless of the final details, this incident again reminds the market: the security assumptions of future protocols are being rewritten by more powerful automated research capabilities.

While we wait for further updates on whether "ZEC truly flowed into Orchard," a more important lesson may be: whether the project team has established close and high-quality collaboration with security researchers and engineers behind the scenes.

As implied by the quote from Tayvano in the article, Zcash might have had this layer of relationship with intermediaries that allowed it to discover the issue before attackers did. You may pray, but more importantly, verify the process itself.

This may sound like a repeated warning, but it’s worth reiterating: We are stepping into a new paradigm capable of breaking through the protections of protocols worth billions of dollars.