Orchard in Zcash: The Modern Shielded Pool

Key Facts

• Orchard activated with NU5 at Zcash block 1,687,104 on May 31, 2022.
• Orchard uses Halo 2 instead of the Groth16 proving system used by Sapling.
• An Orchard receiver is distributed inside a Unified Address, not as a standalone address string.
• Orchard and Sapling are separate shielded pools with separate privacy sets.

Orchard is a protocol, a pool, and a migration path

Orchard is the shielded payment protocol introduced by Zcash Network Upgrade 5. The upgrade activated at block 1,687,104 on May 31, 2022 and added both Orchard and Unified Addresses. Those pieces belong together: a wallet normally gives the user one Unified Address, then selects the Orchard receiver when both sides support it.

Calling Orchard an address type is incomplete. It defines how shielded notes are created and spent, how keys are derived, how commitments and nullifiers work, and how the network verifies an Orchard transaction without learning the protected payment details. The Orchard pool is also a distinct accounting pool on the Zcash chain, separate from Sapling and the earlier Sprout pool.

Halo 2 verifies rules without publishing the payment

An Orchard spend carries a Halo 2 zero-knowledge proof. The proof convinces Zcash nodes that the private transaction satisfies the protocol rules: the notes being spent exist, the spender is authorized, values balance, and the same note is not being spent twice. The proof does not need to publish the sender, receiver, or amount inside the shielded transfer.

Sapling uses Groth16 and depended on a multi-party parameter ceremony. Orchard uses the Halo 2 proving system with a PLONK-like circuit design, removing the need for a new trusted setup for this pool. That is a cryptographic architecture change, not a promise that every piece of wallet or network metadata disappears. Wallet behavior, network connections, receiver selection, and cross-pool transfers still shape the user's privacy.

Orchard actions hide simple transaction shape

An Orchard bundle contains actions. Each action combines one spend and one output, with either side allowed to be a dummy. A single Halo 2 proof covers the actions in the bundle. This structure gives Orchard better arity hiding than a design that exposes one proof for every real spend or output, because an observer cannot read the proof count as a direct list of the transaction's economic inputs and recipients.

The chain still receives the data required for consensus: commitments, nullifiers, signatures, encrypted note ciphertexts, and the proof. Nullifiers let nodes reject double spends without revealing which earlier note was consumed. Commitments let a recipient later prove that an owned note belongs to the append-only Orchard commitment tree.

Unified Addresses keep receiver choice out of the user's hands

There is deliberately no standard standalone text encoding for an Orchard payment address. Orchard receivers are carried in Unified Addresses, which can bundle compatible Orchard, Sapling, and transparent receivers. A supporting wallet chooses the best receiver it can use instead of forcing the sender to identify cryptographic pool prefixes.

That abstraction is useful only when the wallet handles it honestly. A Unified Address does not guarantee that every sender will use Orchard. The sender's wallet may choose another receiver because of its own capabilities or the transaction path. Before relying on a shielded workflow, verify what the sending wallet actually selects and what the receiving wallet supports.

Moving between pools can reveal the transfer value

Orchard is a separate privacy set. Transfers entirely within Orchard contribute to and draw from that set, while moves between Orchard and another Zcash pool cross a visible value boundary. ZIP 224 warns that spending Orchard funds to a non-Orchard address reveals the value moving across that boundary, even though the internal Orchard notes remain shielded.

This is why pool migration and wallet defaults matter. A larger Orchard set helps users blend with more shielded activity, but one user's transaction does not become private merely because the word Orchard appears in the interface. Staying shielded end to end, avoiding unnecessary cross-pool movement, and using a wallet that explains receiver selection are more useful than chasing a protocol label.

What Orchard improves and what it does not

Orchard modernizes the proving system, simplifies several protocol components learned from Sapling, makes every diversifier produce a valid address, and gives Zcash a foundation designed with future scalability in mind. It also supports encrypted memos and incoming or full viewing authority through Unified Viewing Keys.

It does not make spending authority recoverable, hide a transparent leg of a payment, protect a memo after a user shares sufficient viewing authority, or conceal network-layer metadata by itself. Orchard is the strongest current Zcash-native payment path when the complete wallet flow uses it correctly; it is not a substitute for understanding the path.

FAQ