Skip to content

Commit 23d223e

Browse files
committed
WIP
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
1 parent 3dee517 commit 23d223e

4 files changed

Lines changed: 166 additions & 6 deletions

File tree

README.rst

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -233,6 +233,7 @@ be deleted.
233233
<tr> <th>Draft name</th> <th>Title</th> <th>Discussions-To</th> </tr>
234234
<tr> <td class="left">draft-arya-dairaemma-disable-addition-of-transparent-chain-value</td> <td class="left"><a href="zips/draft-arya-dairaemma-disable-addition-of-transparent-chain-value.md">Disabling Addition of New Value to the Transparent Chain Value Pool</a></td> <td class="left"><a href="https://github.com/zcash/zips/issues/1115">zips#1115</a></td>
235235
<tr> <td class="left">draft-arya-deploy-nu7</td> <td class="left"><a href="zips/draft-arya-deploy-nu7.md">Deployment of the NU7 Network Upgrade</a></td> <td class="left"><a href="https://github.com/zcash/zips/issues/839">zips#839</a></td>
236+
<tr> <td class="left">draft-dairaemma-nu6.3-consequences-for-wallets</td> <td class="left"><a href="zips/draft-dairaemma-nu6.3-consequences-for-wallets.md">NU6.3 Consequences for Wallets</a></td> <td class="left"><a href="https://github.com/zcash/zips/issues/1318">zips#1318</a></td>
236237
<tr> <td class="left">draft-ecc-authenticated-reply-addrs</td> <td class="left"><a href="zips/draft-ecc-authenticated-reply-addrs.md">Authenticated Reply Addresses</a></td> <td class="left"><a href="https://github.com/zcash/zips/issues/1230">zips#1230</a></td>
237238
<tr> <td class="left">draft-ecc-onchain-accountable-voting</td> <td class="left"><a href="zips/draft-ecc-onchain-accountable-voting.md">On-chain Accountable Voting</a></td> <td class="left"></td>
238239
<tr> <td class="left">draft-str4d-orchard-balance-proof</td> <td class="left"><a href="zips/draft-str4d-orchard-balance-proof.md">Air drops, Proof-of-Balance, and Stake-weighted Polling</a></td> <td class="left"><a href="https://github.com/zcash/zips/issues/1229">zips#1229</a></td>
@@ -250,7 +251,7 @@ Withdrawn, Rejected, or Obsolete ZIPs
250251
<tr> <td><strike>210</strike></td> <td class="left"><strike><a href="zips/zip-0210.rst">Sapling Anchor Deduplication within Transactions</a></strike></td> <td>Withdrawn</td>
251252
<tr> <td><strike>220</strike></td> <td class="left"><strike><a href="zips/zip-0220.rst">Zcash Shielded Assets</a></strike></td> <td>Withdrawn</td>
252253
<tr> <td><strike>230</strike></td> <td class="left"><strike><a href="zips/zip-0230.rst">Withdrawn Version 6 Transaction Format</a></strike></td> <td>Withdrawn</td>
253-
<tr> <td><strike>246</strike></td> <td class="left"><strike><a href="zips/zip-0246.rst">Digests for the Version 6 Transaction Format</a></strike></td> <td>Withdrawn</td>
254+
<tr> <td><strike>246</strike></td> <td class="left"><strike><a href="zips/zip-0246.rst">Digests for the Withdrawn Version 6 Transaction Format</a></strike></td> <td>Withdrawn</td>
254255
<tr> <td><strike>254</strike></td> <td class="left"><strike><a href="zips/zip-0254.md">Deployment of the NU7 Network Upgrade (Withdrawn)</a></strike></td> <td>Withdrawn</td>
255256
<tr> <td><strike>303</strike></td> <td class="left"><strike><a href="zips/zip-0303.rst">Sprout Payment Disclosure</a></strike></td> <td>Withdrawn</td>
256257
<tr> <td><strike>313</strike></td> <td class="left"><strike><a href="zips/zip-0313.rst">Reduce Conventional Transaction Fee to 1000 zatoshis</a></strike></td> <td>Obsolete</td>
@@ -330,7 +331,7 @@ Index of ZIPs
330331
<tr> <td>243</td> <td class="left"><a href="zips/zip-0243.rst">Transaction Signature Validation for Sapling</a></td> <td>Final</td>
331332
<tr> <td>244</td> <td class="left"><a href="zips/zip-0244.rst">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
332333
<tr> <td>245</td> <td class="left"><a href="zips/zip-0245.rst">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
333-
<tr> <td><strike>246</strike></td> <td class="left"><strike><a href="zips/zip-0246.rst">Digests for the Version 6 Transaction Format</a></strike></td> <td>Withdrawn</td>
334+
<tr> <td><strike>246</strike></td> <td class="left"><strike><a href="zips/zip-0246.rst">Digests for the Withdrawn Version 6 Transaction Format</a></strike></td> <td>Withdrawn</td>
334335
<tr> <td>250</td> <td class="left"><a href="zips/zip-0250.rst">Deployment of the Heartwood Network Upgrade</a></td> <td>Final</td>
335336
<tr> <td>251</td> <td class="left"><a href="zips/zip-0251.rst">Deployment of the Canopy Network Upgrade</a></td> <td>Final</td>
336337
<tr> <td>252</td> <td class="left"><a href="zips/zip-0252.rst">Deployment of the NU5 Network Upgrade</a></td> <td>Final</td>

zips/zip-0229.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -508,6 +508,6 @@ treating the note commitment tree anchor as authorizing data rather than effecti
508508

509509
[^draft-zodl-valargroup-ironwood-migration]: [Wallet Considerations for NU6.3 and Migration to the Ironwood Pool (draft)](draft-zodl-valargroup-ironwood-migration.md)
510510

511-
[^zcash-ironwood]: [GitHub repository zcash/ironwood: Formal Verification of the Zcash Protocol and Documentation for the Ironwood Pool](https://github.com/zcash/ironwood)
511+
[^Ironwood-book]: [The Ironwood Book](https://zcash.github.io/ironwood/)
512512

513513
[^penumbra]: [The Penumbra Protocol](https://protocol.penumbra.zone/main/index.html)

zips/zip-0257.md

Lines changed: 159 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,159 @@
1+
2+
ZIP: 257
3+
Title: Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade
4+
Owners: Daira-Emma Hopwood <daira@jacaranda.org>
5+
Status: Proposed
6+
Category: Consensus / Network
7+
Created: 2026-06-09
8+
License: MIT
9+
Discussions-To: <https://github.com/zcash/zips/issues/1293>
10+
11+
12+
# Terminology
13+
14+
The key words "MUST" and "MUST NOT" in this document are to be interpreted as
15+
described in BCP 14 [^BCP14] when, and only when, they appear in all capitals.
16+
17+
The term "network upgrade" in this document is to be interpreted as described
18+
in ZIP 200. [^zip-0200]
19+
20+
The character § is used when referring to sections of the Zcash Protocol
21+
Specification. [^protocol]
22+
23+
The terms "Mainnet" and "Testnet" are to be interpreted as described in
24+
§ 3.12 ‘Mainnet and Testnet’. [^protocol-networks]
25+
26+
27+
# Abstract
28+
29+
This ZIP retrospectively documents the deployment of the Orchard temporary
30+
vulnerability mitigation, and the NU6.2 network upgrade.
31+
32+
33+
# Motivation
34+
35+
On 2026-05-29, security researcher Taylor Hornby, who had been tasked with an
36+
AI-assisted security audit of the Orchard shielded protocol, reported a
37+
soundness vulnerability in the
38+
[Orchard Action circuit implementation](https://github.com/zcash/orchard).
39+
Details of the vulnerability are described in Taylor's work log [^Hornby2026]
40+
and in GHSA-ww9q-8r59-xv46. [^GHSA-halo2]
41+
42+
This vulnerability could have allowed balance violation and theft of funds.
43+
Therefore, it was imperative to immediately disable use of Orchard, until a
44+
corrected Orchard Action circuit could be deployed in the NU6.2 network
45+
upgrade. (Disabling the vulnerable circuit and enabling the new one at the
46+
same time was ruled out due to the risk of revealing the vulnerability
47+
before it had been mitigated, and in order to close the vulnerability window
48+
more quickly, while the fix was still being prepared and reviewed.)
49+
50+
51+
# Specification
52+
53+
## Orchard temporary vulnerability mitigation
54+
55+
Consensus rule: From block height 3363426 (Mainnet) or 4048500 (Testnet)
56+
onward, until the activation of NU6.2 on each network, transactions MUST NOT
57+
contain any Orchard Action descriptions, i.e. $\mathsf{nActionsOrchard} = 0$.
58+
59+
The Mainnet mitigation was deployed as an emergency hotfix in zcashd v6.12.5
60+
and zebra v4.5.3. [^GHSA-zcash-hotfix] [^GHSA-zebra-hotfix] These releases did not have the "until the
61+
activation of NU6.2" restriction; i.e. they disabled Orchard until deployment
62+
of the subsequent releases.
63+
64+
zcashd v6.12.4 had used a Mainnet activation height of 3363366, 60 blocks
65+
earlier. Some mining pools failed to upgrade in time, so the activation was
66+
re-attempted successfully at the height given above.
67+
68+
These emergency hotfixes enabled the soft fork on Mainnet only, leaving the
69+
Testnet mitigation height unset. On Testnet, the soft fork instead took effect
70+
through zcashd v6.20.0 and zebra v5.0.0, which set the Testnet mitigation height
71+
to 4048500 and added support for NU6.2. Those releases had been published before
72+
Testnet reached height 4048500. The disabling of Orchard, and the subsequent
73+
re-enabling at NU6.2 (height 4052000), therefore occurred on Testnet as an
74+
ordinary scheduled activation rather than an emergency response.
75+
76+
## NU6.2 deployment
77+
78+
The NU6.2 network upgrade re-enables the Orchard shielded protocol, with two
79+
consensus changes relative to the original Orchard rules:
80+
81+
- The Orchard Action circuit's variable-base scalar multiplication gadget is
82+
corrected, fixing the soundness vulnerability. This changes the Orchard
83+
verifying key. Pre-NU6.2 Action proofs verify only under the historical
84+
(insecure) verifying key, and NU6.2-onward proofs only under the corrected
85+
one. The fix was published in halo2_gadgets v0.5.0 [^halo2-0.5.0] and
86+
orchard v0.14.0. [^orchard-0.14.0]
87+
88+
- From the activation of NU6.2, an Orchard Action proof MUST have the canonical
89+
length for the corrected circuit. Before NU6.2, this length was not enforced
90+
as a consensus rule. [^GHSA-zebra-hotfix]
91+
92+
From the activation of NU6.2, the temporary mitigation no longer applies.
93+
Transactions containing Orchard Action descriptions MUST again be accepted,
94+
with proofs subject to verification under the corrected circuit and the
95+
canonical-length rule. NU6.2 was deployed in zcashd v6.20.0 and zebra v5.0.0.
96+
97+
The primary sources of information about NU6.2 consensus protocol changes are
98+
the Zcash Protocol Specification [^protocol] and this ZIP.
99+
100+
The network handshake and peer management mechanisms defined in ZIP 201
101+
[^zip-0201] also apply to this upgrade.
102+
103+
The following network upgrade constants [^zip-0200] are defined for the
104+
NU6.2 upgrade:
105+
106+
CONSENSUS_BRANCH_ID
107+
: `0x5437F330`
108+
109+
ACTIVATION_HEIGHT (NU6.2)
110+
: Testnet: 4052000
111+
: Mainnet: 3364600
112+
113+
MIN_NETWORK_PROTOCOL_VERSION (NU6.2)
114+
: Testnet: `170150`
115+
: Mainnet: `170150`
116+
117+
For each network (Testnet and Mainnet), nodes compatible with NU6.2 activation
118+
on that network MUST advertise a network protocol version that is greater
119+
than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6.2) for that activation.
120+
121+
## Zcash Protocol Specification changes
122+
123+
TODO follow similar pattern to ZIP 2005
124+
125+
## Backward compatibility
126+
127+
Prior to the network upgrade activating on each network, NU6.2 and pre-NU6.2
128+
nodes are compatible and can connect to each other. However, NU6.2 nodes will
129+
have a preference for connecting to other NU6.2 nodes, so pre-NU6.2 nodes will
130+
be disconnected in the run up to activation.
131+
132+
Once the network upgrades, even though pre-NU6.2 nodes can still accept the
133+
numerically larger protocol version used by NU6.2 as being valid, NU6.2 nodes
134+
will always disconnect peers using lower protocol versions.
135+
136+
137+
# References
138+
139+
[^BCP14]: [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)
140+
141+
[^protocol]: [Zcash Protocol Specification, Version 2025.6.3 or later](protocol/protocol.pdf)
142+
143+
[^protocol-networks]: [Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks)
144+
145+
[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst)
146+
147+
[^zip-0201]: [ZIP 201: Network Peer Management for Overwinter](zip-0201.rst)
148+
149+
[^orchard-0.14.0]: [orchard v0.14.0 release (zcash/orchard#500)](https://github.com/zcash/orchard/pull/500)
150+
151+
[^halo2-0.5.0]: [halo2_gadgets v0.5.0 release (zcash/halo2#888)](https://github.com/zcash/halo2/pull/888)
152+
153+
[^Hornby2026]: [Taylor Hornby — work log for the Orchard counterfeiting vulnerability](https://drive.google.com/file/d/1SVK41y-ip3Vw9eB69E9QRy-Qn3idTOwV/view)
154+
155+
[^GHSA-halo2]: [Missing copy constraint in halo2_gadgets variable-base scalar multiplication allows under-constrained base, breaking Orchard Action circuit soundness (fixed in zcashd v6.20.0 and zebra v5.0.0)](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-ww9q-8r59-xv46)
156+
157+
[^GHSA-zcash-hotfix]: [Urgent Zcash hotfixes v6.12.4 & v6.20.0 (zcashd, affected v5.0.0–v6.13.0)](https://github.com/zcash/zcash/security/advisories/GHSA-ghc3-g8w4-whf9)
158+
159+
[^GHSA-zebra-hotfix]: [GHSA-jfw5-j458-pfv6 title — fill from GitHub once published› (zebrad; soft-fork disable in v4.5.3, NU6.2 proof-size rule in v5.0.0)](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-jfw5-j458-pfv6)

zips/zip-2005.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -322,9 +322,9 @@ graph BT
322322

323323
Once this proposal is deployed, wallets SHOULD move all of the funds they
324324
control (including transparent, Sprout, and Sapling funds) into recoverable
325-
*Ironwood-pool* notes as soon as practically possible. This does not depend on support
326-
from other wallets for receiving recoverable notes, because wallet-internal
327-
addresses can be used.
325+
*Ironwood-pool* notes as soon as practically possible. Other wallets are
326+
REQUIRED, as part of supporting the NU6.3 upgrade, to be able to receive
327+
these notes.
328328

329329
Non-recoverable funds may be received after existing funds have been made
330330
recoverable. Wallets SHOULD therefore treat the movement of funds to

0 commit comments

Comments
 (0)