Zcash Orchard Protocol: Halo 2 and the End of Trusted Setup

Zcash's Privacy Evolution

Zcash launched in October 2016 with the Sprout protocol — the first real-world deployment of zk-SNARKs in a production blockchain. Sprout was a landmark achievement, but it was computationally slow and required significant memory, making shielded transactions impractical for everyday mobile use.

The Sapling upgrade in October 2018 addressed this. By redesigning the proving circuit and adopting the Groth16 proving system, Zcash reduced shielded transaction proving time from over 40 seconds (on powerful hardware) to under 7 seconds on a smartphone. This made shielded ZEC practical for the first time.

But Sapling had one remaining philosophical weakness: its Groth16 proving system required a trusted setup. The Orchard protocol, activated in Network Upgrade 5 (NU5) on May 31, 2022, resolved this — and introduced the most significant privacy advancement in Zcash's history.

The Trusted Setup Problem

Many zk-SNARK systems require a one-time setup ceremony where cryptographic parameters are generated. During this ceremony, participants contribute randomness that gets "baked into" the parameters. The danger: if any participant in the ceremony preserved their private random input (called "toxic waste"), that knowledge could theoretically be used to create forged proofs — generating ZEC from nothing without detection.

For Sapling, Zcash ran the "Powers of Tau" ceremony in 2017–2018, with over 90 participants from the global cryptography and Zcash community contributing randomness. The ceremony was designed so that only one participant needed to be honest for the parameters to be secure. With 90+ participants, collusion is extraordinarily implausible — but not mathematically impossible.

This theoretical residual risk bothered cryptographers. Trusted setup ceremonies introduce a philosophical impurity: users must trust not just the mathematics, but the integrity of specific humans at a specific moment in time.

Halo 2: Recursion Solves the Problem

Halo 2, developed by the Electric Coin Company's cryptography team, is the proving system underlying Orchard. Its key innovation: it achieves efficient zk-SNARKs without any trusted setup whatsoever.

The technique is called recursive proof composition. In Halo 2, proofs can verify other proofs. This creates a chain of verification where the security of the entire system bootstraps from well-studied mathematical hardness assumptions — specifically, the hardness of the discrete logarithm problem on elliptic curves — rather than from secret parameters generated by human participants.

No ceremony. No toxic waste. No trust in any individual or organisation. The security of Orchard transactions rests entirely on mathematics that has been studied by the cryptographic community for decades.

This is the cryptographic equivalent of going from "we trust the bank vault is secure" to "we've proven mathematically that no vault exists — the money is just... inaccessible by design."

What Orchard Changes in Practice

For users, Orchard transactions are accessed through Unified Addresses (UAs) — the new standard address format introduced in ZIP-316 alongside NU5. A Unified Address bundles multiple receiver types (Orchard, Sapling, transparent) into a single address, with wallets automatically routing to the most private supported type.

Key practical changes with Orchard:

• New shielded pool: Orchard is a separate pool from Sapling. ZEC shielded to Orchard enters a distinct anonymity set. The Orchard pool grows as more users migrate from Sapling.
• Stronger security assumptions: No trusted setup means no theoretical forging risk. Security is based purely on well-studied cryptographic hardness.
• Action-based transactions: Orchard uses "actions" rather than the separate spend/output note model of Sapling. Each action both spends an old note and creates a new one, improving efficiency.
• Unified Addresses by default: Wallets supporting NU5 generate UAs instead of plain z-addresses, simplifying the user experience and future-proofing address formats.

The Pasta Curves: Orchard's Elliptic Curve Foundation

Orchard uses a pair of elliptic curves called Pallas and Vesta (collectively: "Pasta curves"), specifically designed for efficient recursive proof composition. These curves were engineered by the ECC team to have properties that make Halo 2's recursive techniques practical at Zcash's performance requirements.

This is one reason why Orchard and Sapling are separate — the change of underlying curves means they are cryptographically incompatible. ZEC shielded with Sapling (zs-addresses) and ZEC shielded with Orchard (via UAs) exist in separate pools and cannot be combined in a single shielded transaction without an intermediate step.

Migration: Should You Move From Sapling to Orchard?

For new users, the answer is simple: always use Orchard (Unified Addresses) from the start. Use a wallet like Zashi or YWallet that defaults to Orchard.

For existing Sapling users: migrating your ZEC to the Orchard pool is recommended. YWallet makes this straightforward with a "Migrate to Orchard" option. The migration involves a z-to-z transaction (Sapling to Orchard), which itself is fully private but does require a small network fee. The privacy benefit of a larger Orchard pool growing over time is worth the minor cost.