Zcash’s Orchard Vulnerability Leaves Users Unable to Verify ZEC Circulating Supply, Says Zooko Wilcox

TLDR:

• Zooko Wilcox confirms users cannot independently verify if ZEC supply was hit by the Orchard flaw.
• The Ironwood upgrade would create a new shielded pool using the patched Orchard circuit upon activation.
• Turnstile mechanisms will block any excess ZEC from exiting the old Orchard pool after Ironwood activates.
• Wilcox says exploitation is unlikely but users should not rely on Shielded Labs’ assessment alone.

Zcash co-founder Zooko Wilcox has confirmed that users currently cannot independently verify whether ZEC’s circulating supply was affected by the recently disclosed Orchard counterfeiting vulnerability.

Wilcox, alongside Jason McGee and Taylor Hornby of Shielded Labs, published a proposal for the Ironwood network upgrade.

The upgrade would restore user-level supply verification through consensus rules. No deployment timeline has been announced.

Wilcox: Privacy Properties of Orchard Block Independent Verification

The Orchard vulnerability was patched through an emergency network upgrade completed on June 2. That fix closed the security gap, but it did not resolve a separate problem.

The privacy architecture of the Orchard pool makes it impossible for users to confirm whether the vulnerability was exploited before the patch.

Wilcox acknowledged that Shielded Labs believes exploitation was unlikely. However, he was direct about the limits of that position.

Users should not have to rely on the team’s assessment when verifying the integrity of the ZEC supply, he stated in the published proposal.

The proposed Ironwood upgrade addresses this gap at the protocol level. It would create a new shielded pool using the corrected Orchard circuit.

Simultaneously, any transaction attempting to create new outputs in the existing Orchard pool would be rejected as invalid.

Once Ironwood activates, users would gain immediate, trustless verification of the circulating supply. They would simply sum the balances across active pools by running a node, with no need to reason about other parties’ actions or wait for fund migrations to complete.

Ironwood’s Two-Outcome Framework Targets On-Chain Evidence of Counterfeiting

Wilcox and his co-authors structured Ironwood around what happens when users begin migrating funds out of the old Orchard pool. The migration process creates conditions that may surface evidence of whether counterfeiting occurred.

Any counterfeiter holding excess ZEC in the old pool would face two options. Moving those funds into the new pool would expose their existence on-chain. Leaving them behind would risk permanent inaccessibility as legitimate users complete their migrations.

Wilcox outlined two resulting outcomes. Under the first, no excess ZEC attempts to exit the old pool. That result would serve as strong on-chain evidence that the vulnerability was never exploited.

Under the second, excess ZEC attempts to cross the turnstile and gets blocked by the protocol, destroying those funds while creating publicly verifiable proof of counterfeiting.

Turnstiles, Zcash’s existing cross-pool accounting mechanism, enforce these rules automatically. They track the total ZEC entering each pool and reject any withdrawal attempt that exceeds the legitimate balance. This prevents excess ZEC from escaping into other pools regardless of outcome.

Wilcox recommended that all wallets supporting the existing Orchard pool add support for the new one ahead of activation.

Existing Orchard addresses would remain valid after Ironwood activates, with incoming ZEC automatically received in the new pool. The team noted that the transition from zcashd to the Zebra node client may affect the upgrade’s timing.