# ZIP 257: Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade

Status: Final

Owners: Daira-Emma Hopwood

Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a

Source date: 2026-10-16T02:56:04+01:00

[Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a)

[Official source](https://zips.z.cash/zip-0257) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0257.md) · [Discussion](https://github.com/zcash/zips/issues/1293)

Preamble

**ZIP**: 257

**Title**: Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade

**Owners**: [Daira-Emma Hopwood](mailto:daira@jacaranda.org)

**Status**: Final

**Category**: Consensus / Network

**Created**: 2026-06-09

**License**: MIT

**Discussions-To**: [https://github.com/zcash/zips/issues/1293](https://github.com/zcash/zips/issues/1293)

<a id="terminology"></a>

## Terminology

The key words "MUST" and "MUST NOT" in this document are to be interpreted as
described in BCP 14 <a id="user-content-fnref-bcp14"></a>
[1](#user-content-fn-bcp14) when, and only when, they appear in all capitals.

The term "network upgrade" in this document is to be interpreted as described
in ZIP 200. <a id="user-content-fnref-zip-0200"></a>
[2](#user-content-fn-zip-0200)

The character § is used when referring to sections of the Zcash Protocol
Specification. <a id="user-content-fnref-protocol-2026.7.0"></a>
[3](#user-content-fn-protocol-2026.7.0)

The terms "Mainnet" and "Testnet" are to be interpreted as described in
§ 3.12 ‘Mainnet and Testnet’. <a id="user-content-fnref-protocol-networks"></a>
[4](#user-content-fn-protocol-networks)

<a id="abstract"></a>

## Abstract

This ZIP retrospectively documents the deployment of the Orchard temporary
vulnerability mitigation, and the NU6.2 network upgrade.

<a id="motivation"></a>

## Motivation

On 2026-05-29, security researcher Taylor Hornby, who had been tasked with an
AI-assisted security audit of the Orchard shielded protocol, reported a
soundness vulnerability in the
[Orchard Action circuit implementation](https://github.com/zcash/orchard).
Details of the vulnerability are described in Taylor's work log <a id="user-content-fnref-hornby2026"></a>
[5](#user-content-fn-hornby2026)
and in GHSA-ww9q-8r59-xv46. <a id="user-content-fnref-ghsa-circuit"></a>
[6](#user-content-fn-ghsa-circuit)

This vulnerability could have allowed balance violation and theft of funds.
Therefore, it was imperative to immediately disable use of Orchard, until a
corrected Orchard Action circuit could be deployed in the NU6.2 network
upgrade. (Disabling the vulnerable circuit and enabling the new one at the
same time was ruled out due to the risk of revealing the vulnerability
before it had been mitigated, and in order to close the vulnerability window
more quickly, while the fix was still being prepared and reviewed.)

<a id="specification"></a>

## Specification

<a id="orchard-temporary-vulnerability-mitigation"></a>

### Orchard temporary vulnerability mitigation

Consensus rule: From block height 3363426 (Mainnet) or 4048500 (Testnet)
onward, until the activation of NU6.2 on each network, v5 and later transactions
MUST NOT contain any Orchard Action descriptions, i.e. $\mathsf{nActionsOrchard} = 0$.

The Mainnet mitigation was deployed as an emergency hotfix in zcashd v6.12.5
and zebra v4.5.3. <a id="user-content-fnref-ghsa-zcashd"></a>
[7](#user-content-fn-ghsa-zcashd) <a id="user-content-fnref-ghsa-zebra"></a>
[8](#user-content-fn-ghsa-zebra) These releases did
not have the "until the activation of NU6.2" restriction; i.e. they disabled
Orchard until deployment of the subsequent releases. Note that zcashd v6.12.4
also deployed other security fixes described in ZIP 256 <a id="user-content-fnref-zip-0256"></a>
[9](#user-content-fn-zip-0256).

zcashd v6.12.4 had used a Mainnet activation height of 3363366, 60 blocks
earlier. Some mining pools failed to upgrade in time, so the activation was
re-attempted successfully at the height given above.

These emergency hotfixes enabled the soft fork on Mainnet only, leaving the
Testnet mitigation height unset. On Testnet, the soft fork instead took effect
through zcashd v6.20.0 and zebra v5.0.0, which set the Testnet mitigation height
to 4048500 and added support for NU6.2. Those releases had been published before
Testnet reached height 4048500. The disabling of Orchard, and the subsequent
re-enabling at NU6.2 (height 4052000), therefore occurred on Testnet as an
ordinary scheduled activation rather than an emergency response.

<a id="nu6-2-deployment"></a>

### NU6.2 deployment

The NU6.2 network upgrade re-enables the Orchard shielded protocol, with two
consensus changes relative to the original Orchard rules:

- The Orchard Action circuit's variable-base scalar multiplication gadget is
  corrected, fixing the soundness vulnerability. This changes the Orchard
  verifying key. Pre-NU6.2 Action proofs verify only under the historical
  (insecure) verifying key, and NU6.2-onward proofs only under the corrected
  one. The fix was published in halo2_gadgets v0.5.0 <a id="user-content-fnref-halo2-0.5.0"></a>
  [10](#user-content-fn-halo2-0.5.0) and
  orchard v0.14.0. <a id="user-content-fnref-orchard-0.14.0"></a>
  [11](#user-content-fn-orchard-0.14.0)

- From the activation of NU6.2, an Orchard Action proof MUST have the canonical
  length for the corrected circuit. Before NU6.2, this length was not enforced
  as a consensus rule. <a id="user-content-fnref-ghsa-zebra-2"></a>
  [8](#user-content-fn-ghsa-zebra)

From the activation of NU6.2, the temporary mitigation no longer applies.
Transactions containing Orchard Action descriptions MUST again be accepted,
with proofs subject to verification under the corrected circuit and the
canonical-length rule. NU6.2 was deployed in zcashd v6.20.0 and zebra v5.0.0.

The primary sources of information about NU6.2 consensus protocol changes are
the Zcash Protocol Specification <a id="user-content-fnref-protocol-2026.7.0-2"></a>
[3](#user-content-fn-protocol-2026.7.0) and this ZIP.

The network handshake and peer management mechanisms defined in ZIP 201
<a id="user-content-fnref-zip-0201"></a>
[12](#user-content-fn-zip-0201) also apply to this upgrade.

The following network upgrade constants <a id="user-content-fnref-zip-0200-2"></a>
[2](#user-content-fn-zip-0200) are defined for the
NU6.2 upgrade:

CONSENSUS_BRANCH_ID
: `0x5437F330`

ACTIVATION_HEIGHT (NU6.2)
: Testnet: 4052000
: Mainnet: 3364600

MIN_NETWORK_PROTOCOL_VERSION (NU6.2)
: Testnet: `170150`
: Mainnet: `170150`

For each network (Testnet and Mainnet), nodes compatible with NU6.2 activation
on that network MUST advertise a network protocol version that is greater
than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6.2) for that activation.

<a id="zcash-protocol-specification-changes"></a>

### Zcash Protocol Specification changes

The changes below to the Zcash Protocol Specification correspond to the two NU6.2
consensus changes described above. They are relative to version 2026.6.4 of the
specification <a id="user-content-fnref-protocol-2026.6.4"></a>
[13](#user-content-fn-protocol-2026.6.4), and are applied in version 2026.7.0 <a id="user-content-fnref-protocol-2026.7.0-3"></a>
[3](#user-content-fn-protocol-2026.7.0).

#### Consensus rule for the temporary vulnerability mitigation

Add a consensus rule to § 7.1.2 ‘Transaction Consensus Rules’ <a id="user-content-fnref-protocol-txnconsensus"></a>
[14](#user-content-fn-protocol-txnconsensus):

> [Pre-NU6.2] From block height 3363426 (Mainnet) or 4048500 (Testnet) onward,
> until the activation of NU6.2 on each network, if $\mathsf{effectiveVersion} \geq 5$
> then the transaction MUST NOT contain any Orchard Action descriptions, i.e.
> $\mathsf{nActionsOrchard} = 0$.

#### Orchard Action verifying key selection

The correction to the Orchard Action circuit changes the Orchard Action verifying
key after NU6.2 activation.

In § 4.1.13 ‘Zero-Knowledge Proving System’ <a id="user-content-fnref-protocol-abstractzk"></a>
[15](#user-content-fn-protocol-abstractzk), replace the
sentence

> We also omit subscripts on $\mathsf{ZKAction.Prove}$ and $\mathsf{ZKAction.Verify}$.

with

> Subscripts are not omitted on $\mathsf{ZKAction.Prove}$ and $\mathsf{ZKAction.Verify}$,
> since more than one version of the $\mathsf{Orchard}$ circuit has been deployed.

In § 4.6 ‘Action Descriptions’ <a id="user-content-fnref-protocol-actiondesc"></a>
[16](#user-content-fn-protocol-actiondesc):

Before "An Action description comprises", add:

> Let $\mathsf{vk}$ be the halo2 verifying key identified by the Orchard
> circuit version, as specified in the consensus rules below.

Replace the last consensus rule with the following three rules:

> - [NU5 to NU6.1 inclusive, pre NU6.2] $\mathsf{vk}$ MUST be the key identified by
>   $\texttt{OrchardCircuitVersion::InsecurePreNU6\_2}$.
> 
> - [NU6.2 onward] $\mathsf{vk}$ MUST be the key identified by
>   $\texttt{OrchardCircuitVersion::FixedPostNU6\_2}$.
> 
> - The proof $\pi$ MUST be valid for verifying key $\mathsf{vk}$ given a primary input
>   $(\mathsf{cv}, \mathsf{rt}^{\textit{OrchardPool}}, \mathsf{nf}, \mathsf{rk}, \mathsf{cm}_x, \mathsf{enableSpends}, \mathsf{enableOutputs})$ — i.e.
>   $\mathsf{ZKAction.Verify_{vk}}\big(\kern-0.1em(\mathsf{cv}, \mathsf{rt}^{\textit{OrchardPool}}, \mathsf{nf}, \mathsf{rk}, \mathsf{cm}_x, \mathsf{enableSpends}, \mathsf{enableOutputs}), \pi\big) = 1$.

In § 4.18.4 ‘Action Statement ($\mathsf{Orchard}$)’ <a id="user-content-fnref-protocol-actionstatement"></a>
[17](#user-content-fn-protocol-actionstatement),
add a vulnerability disclosure (styled similarly to the one for $\mathsf{BCTV14}$
in § 5.4.10.1):

> Vulnerability disclosure: The pre-NU6.2 Orchard Action circuit had a soundness
> bug in its variable-base scalar multiplication gadget <a id="user-content-fnref-ghsa-circuit-2"></a>
> [6](#user-content-fn-ghsa-circuit), which
> could have allowed balance violation. The bug is in the circuit implementation
> only; the Action statement specified above is as intended. The corrected circuit
> deployed at NU6.2 has a different verifying key, so pre-NU6.2 Action proofs
> verify only under the insecure pre-NU6.2 key, and NU6.2-onward proofs only
> under the corrected one. The two circuits differ only in the additional copy
> constraints added to ensure soundness <a id="user-content-fnref-halo2-commit"></a>
> [18](#user-content-fn-halo2-commit). The consensus rule specifying
> which key is used for verification is in § 4.6 ‘Action Descriptions’.

#### Canonical Orchard Action proof length

Add a consensus rule in § 7.5 ‘Action Description Encoding and Consensus’

> - [NU6.2 onward] The $\mathtt{proofsOrchard}$ field MUST have the canonical length
>   of $2720 + 2272 \cdot \mathtt{nActionsOrchard}$ bytes.

Add a non-normative note:

> - Before NU6.2, the length of the $\mathtt{proofsOrchard}$ field was not enforced
>   as a consensus rule. The canonical length is determined by the circuit, and is
>   the same for the pre-NU6.2 and post-NU6.2 circuits. See § 5.4.10.3
>   ‘Encoding of $\mathsf{Halo\;2}$ Proofs’ <a id="user-content-fnref-protocol-halo2encoding"></a>
>   [19](#user-content-fn-protocol-halo2encoding), where a
>   $\mathsf{Halo\;2}$ proof is encoded as the proof byte sequence itself.

<a id="backward-compatibility"></a>

### Backward compatibility

Prior to the network upgrade activating on each network, NU6.2 and pre-NU6.2
nodes are compatible and can connect to each other. However, NU6.2 nodes will
have a preference for connecting to other NU6.2 nodes, so pre-NU6.2 nodes will
be disconnected in the run up to activation. (In practice, this was limited by
the fix only initially being distributed to a subset of nodes before the
activation, due to time constraints.)

Once the network upgrades, even though pre-NU6.2 nodes can still accept the
numerically larger protocol version used by NU6.2 as being valid, NU6.2 nodes
will always disconnect peers using lower protocol versions.

<a id="references"></a>

## References

<a id="footnote-label"></a>

### Footnotes

1. [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14) [↩](#user-content-fnref-bcp14)

2. [ZIP 200: Network Upgrade Mechanism](/zip/200) [↩](#user-content-fnref-zip-0200) [↩2](#user-content-fnref-zip-0200-2)

3. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2]](protocol/protocol.pdf#2026.7.0) [↩](#user-content-fnref-protocol-2026.7.0) [↩2](#user-content-fnref-protocol-2026.7.0-2) [↩3](#user-content-fnref-protocol-2026.7.0-3)

4. [Zcash Protocol Specification, Version 2026.7.0 [NU6.2] or later. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) [↩](#user-content-fnref-protocol-networks)

5. [Taylor Hornby — work log for the Orchard counterfeiting vulnerability](https://drive.google.com/file/d/1SVK41y-ip3Vw9eB69E9QRy-Qn3idTOwV/view) [↩](#user-content-fnref-hornby2026)

6. [GitHub Security Advisory ww9q-8r59-xv46: Missing copy constraint in halo2_gadgets variable-base scalar multiplication allows under-constrained base, breaking Orchard Action circuit soundness](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-ww9q-8r59-xv46) [↩](#user-content-fnref-ghsa-circuit) [↩2](#user-content-fnref-ghsa-circuit-2)

7. [GitHub Security Advisory ghc3-g8w4-whf9: Urgent zcashd hotfixes v6.12.4 and v6.20.0](https://github.com/zcash/zcash/security/advisories/GHSA-ghc3-g8w4-whf9) [↩](#user-content-fnref-ghsa-zcashd)

8. [GitHub Security Advisory jfw5-j458-pfv6: Zebra vulnerability remediation for the soundness flaw in the pre-NU6.2 Orchard Action circuit](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-jfw5-j458-pfv6) [↩](#user-content-fnref-ghsa-zebra) [↩2](#user-content-fnref-ghsa-zebra-2)

9. [ZIP 256: Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2](/zip/256) [↩](#user-content-fnref-zip-0256)

10. [halo2_gadgets v0.5.0 release (zcash/halo2#888)](https://github.com/zcash/halo2/pull/888) [↩](#user-content-fnref-halo2-0.5.0)

11. [orchard v0.14.0 release (zcash/orchard#500)](https://github.com/zcash/orchard/pull/500) [↩](#user-content-fnref-orchard-0.14.0)

12. [ZIP 201: Network Peer Management for Overwinter](/zip/201) [↩](#user-content-fnref-zip-0201)

13. [Zcash Protocol Specification, Version 2026.6.4 [NU6.1]](protocol/nu6_1.pdf#2026.6.4) [↩](#user-content-fnref-protocol-2026.6.4)

14. [Zcash Protocol Specification, Version 2026.6.4 [NU6.1]. Section 7.1.2: Transaction Consensus Rules](protocol/nu6_1.pdf#txnconsensus) [↩](#user-content-fnref-protocol-txnconsensus)

15. [Zcash Protocol Specification, Version 2026.6.4 [NU6.1]. Section 4.1.13: Zero-Knowledge Proving System](protocol/nu6_1.pdf#abstractzk) [↩](#user-content-fnref-protocol-abstractzk)

16. [Zcash Protocol Specification, Version 2026.6.4 [NU6.1]. Section 4.6: Action Descriptions](protocol/nu6_1.pdf#actiondesc) [↩](#user-content-fnref-protocol-actiondesc)

17. [Zcash Protocol Specification, Version 2026.6.4 [NU6.1]. Section 4.18.4: Action Statement ($\mathsf{Orchard}$)](protocol/nu6_1.pdf#actionstatement) [↩](#user-content-fnref-protocol-actionstatement)

18. [zcash/halo2 PR 888, commit d8e48ef. halo2_gadgets: Anchor variable-base scalar-mul incomplete-addition base](https://github.com/zcash/halo2/pull/888/changes/d8e48efddbe4746d76eb2c8a843a6ddc2b9a727a) [↩](#user-content-fnref-halo2-commit)

19. [Zcash Protocol Specification, Version 2026.6.4 [NU6.1]. Section 5.4.10.3: Encoding of $\mathsf{Halo\;2}$ Proofs](protocol/nu6_1.pdf#halo2encoding) [↩](#user-content-fnref-protocol-halo2encoding)

## Citation relationships

Cites: [ZIP 200](https://zip-tools-web.harpocrates.workers.dev/zip/200), [ZIP 201](https://zip-tools-web.harpocrates.workers.dev/zip/201), [ZIP 256](https://zip-tools-web.harpocrates.workers.dev/zip/256)

Cited by: [ZIP 229](https://zip-tools-web.harpocrates.workers.dev/zip/229), [ZIP 256](https://zip-tools-web.harpocrates.workers.dev/zip/256)