Search for projects by name or address
Orchard is the shielded protocol (with its latest pool called Ironwood) of the Zcash PoW blockchain. Its circuit is proven with Halo 2, a PLONKish proof system with a transparent IPA commitment over the Pasta curves, and verified by every Zcash full node.
Verifiers
Verifiers N/A |
Orchard is the shielded protocol (with its latest pool called Ironwood) of the Zcash PoW blockchain. Its circuit is proven with Halo 2, a PLONKish proof system with a transparent IPA commitment over the Pasta curves, and verified by every Zcash full node.
Orchard is the shielded protocol of Zcash, activated with NU5 in May 2022. Every shielded spend and output is an Action whose validity is proven with Halo 2, a PLONKish proof system developed by the Electric Coin Company. Halo 2 uses an inner product argument (IPA) polynomial commitment over the Pasta curve cycle instead of a pairing-based commitment, so the Orchard circuit needs no trusted setup. The older Sprout and Sapling pools use Groth16 with parameters from multi-party ceremonies.
Proofs are verified by every Zcash full node as part of its consensus and there currently is no verifying smart contract light node or trust-minimized bridge on Ethereum.
The Orchard Action circuit proves, for one spent note and one new note, that the spent note exists in the note commitment tree, that its nullifier is derived correctly, that the spender holds the spend authority, and that the value commitments balance. It is implemented with the halo2_gadgets library over 2^11 rows, using custom gates and lookup arguments for Sinsemilla hashes, Poseidon and elliptic curve arithmetic.
Following ZIP 224, Orchard uses the Pasta curve cycle: Pallas is the application curve on which keys, commitments and RedPallas signatures are defined, and Vesta is the circuit curve whose scalar field (the base field of Pallas) is the native word type of the circuit. Polynomial commitments and the IPA opening proof are Vesta points. Verifying an IPA proof takes time linear in the circuit size. An Orchard transaction bundles all of its Actions into a single Halo 2 proof. The bundle also carries the RedPallas spend authorization and binding signatures.
Nodes such as zebra and zcashd derive the verifying key deterministically from the circuit description at startup, so unlike Sapling there are no proving or verifying parameters to download and trust. Because the circuit has changed twice, nodes keep three verifying keys and select one by block height: the original NU5 circuit for historical blocks, the fixed circuit from NU6.2, and the NU6.3 circuit that additionally enforces the cross-address restriction.
On 2026-05-29 a soundness bug was reported in the variable-base scalar multiplication gadget of halo2_gadgets: a missing copy constraint left the multiplication base under-constrained, which would have allowed creating counterfeit ZEC inside the Orchard pool. Orchard was disabled by an emergency soft fork at Mainnet block 3363426 and re-enabled with the corrected circuit at the NU6.2 activation, block 3364600, as documented in ZIP 257. The fix shipped in halo2_gadgets 0.5.0 and orchard 0.14.0.
NU6.3 (Mainnet block 3428143, 2026-07-28) created the Ironwood pool, which uses the Orchard protocol with quantum-recoverable notes, and restricted the legacy Orchard pool to same-address transfers so that value migrates to Ironwood. Both pools are proven with the same NU6.3 Action circuit and the same Halo 2 proving system.
[Disclosed vulnerability] Orchard Action circuit soundness bug
2026 Jun 3rd
A missing copy constraint in the halo2_gadgets variable-base scalar multiplication left the Orchard Action circuit under-constrained, allowing counterfeiting inside the pool. Orchard was disabled by an emergency soft fork at block 3363426 (2026-06-02) and re-enabled with a fixed circuit at NU6.2, block 3364600.
Transparent proving systems require no trusted setups and have no additional setup-related trust assumptions.
List of different onchain verifiers for this proving system. Unique ID distinguishes differents deployments of the same verifier from different verifiers (e.g. different versions).