Ripple CTO emeritus David Schwartz has offered a measured reassurance to Zcash holders after the disclosure of a critical flaw in the network’s Orchard shielded pool. His point was narrow: passive holders should not automatically lose access to their coins if the vulnerability was never exploited.
That reassurance, however, does not remove the deeper problem facing Zcash. Because Orchard is designed to hide transaction details, the network cannot simply look backward and prove through public ledger data that counterfeit ZEC was never created.
If there was no exploit, everyone is safe whether they move their coins or not. They'll eventually be a bit lonely in the deprecated pool, but they'll still be safe and accessible.
— David 'JoelKatz' Schwartz (@JoelKatz) June 7, 2026
Orchard Bug Leaves a Verification Problem
The vulnerability was discovered on May 29 by security researcher Taylor Hornby during work commissioned by Shielded Labs. The flaw sat inside the Orchard zero-knowledge circuit and involved an under-constrained element in an elliptic-curve multiplication check, meaning a crafted proof could pass validation when it should have failed.
Shielded Labs said the bug was real and exploitable in testing. With assistance from Anthropic’s Opus 4.8 during a targeted review, Hornby built a local exploit that could generate unlimited, undetectable counterfeit ZEC in a test environment, making the issue a supply-integrity threat rather than a routine wallet bug.
The window of exposure stretched back to Orchard’s activation in May 2022. Emergency coordination across Zcash development teams, miners and infrastructure providers led to a June 2 soft fork that temporarily disabled Orchard transactions, followed by the NU6.2 hard fork on June 3, which re-enabled Orchard with a corrected circuit. The forward-looking exploit path has been closed.
What remains unresolved is the historical question. Shielded Labs has said it believes prior exploitation was unlikely, but it also acknowledged that there is no definitive cryptographic way to prove that from Orchard data alone. That is the core tension: Zcash’s privacy protections also limit retrospective supply auditing.
Ironwood Becomes the Next Confidence Test
Schwartz’s comments addressed a practical user concern: what happens to coins that are not moved during a future migration? His answer was that, assuming no prior exploit, coins left in a deprecated pool should remain safe and accessible, even if they become isolated from normal network activity. That is a consensus-rule argument, not a guarantee that the vulnerability was never abused.
The proposed Ironwood upgrade is meant to solve the broader verification issue. It would create a new shielded pool using the corrected Orchard design, block new outputs in the old Orchard pool, and let users verify circulating supply by summing balances across active pools. The goal is to make supply integrity independently checkable again.
Ironwood could also create evidence about whether Orchard was previously exploited. If no excess ZEC attempts to leave the old pool, that would strengthen the case that no counterfeiting occurred; if excess funds do try to exit, the turnstile accounting mechanism would prevent them from entering the active supply. Either outcome would reduce the current dependence on trust-based reassurance.
The market reaction shows why that matters. ZEC sold off sharply after the disclosure, and prominent crypto investor Arthur Hayes said he exited his position because the privacy-coin thesis depends on a level of assurance that “probably fine” cannot fully provide. For Zcash, the reputational damage is tied as much to uncertainty as to the patched bug itself.
For now, the clean reading is cautious. Zcash has patched the Orchard flaw, passive holders have received conditional reassurance, and Ironwood offers a proposed route toward restored supply verification. But until that upgrade is built, tested and activated, the network remains in a confidence-repair phase rather than a fully resolved postmortem.