Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2

Preamble

ZIP

256

Title

Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2

Owners

Daira-Emma Hopwood

Status

Final

Category

Consensus / Network

Created

2026-06-09

License

MIT

Discussions-To

https://github.com/zcash/zips/issues/1294

Terminology

The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in BCP 14 ¹ 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. ²

The character § is used when referring to sections of the Zcash Protocol Specification. ³

The terms "Mainnet" and "Testnet" are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. ⁴

Abstract

This ZIP retrospectively documents the deployment and specification of several consensus and denial-of-service bug fixes that were applied to the Zcash node implementations, after the activation of NU6.1 ⁵, up to but not including the Orchard Temporary Vulnerability Mitigation and the NU6.2 network upgrade. The latter are documented in ZIP 257. ⁶.

Motivation

Between the activation of NU6.1 and that of NU6.2, several consensus enforcement bugs and denial-of-service vulnerabilities were reported and mitigated in the zcashd and zebra full node implementations. This period corresponded to a sudden spike in vulnerability reports, precipitated by the widespread use of capable AI models for vulnerability discovery and mitigation.

These vulnerabilities were fixed and deployed in zcashd releases v6.12.0 to v6.12.4 inclusive, and in zebra releases v4.2.0 to v4.5.1 inclusive.

This ZIP records the nature of those fixes, the releases in which they were deployed, and corresponding specification changes and clarifications, so that the behaviour of the network across this period is fully documented.

Specification

Consensus rule changes

The changes in this ZIP include the constricting consensus rule changes described here. The corresponding consensus changes in the Zcash Protocol Specification are described in that section.

Orchard identity rk

An Orchard action with $\mathtt{rk}$ encoding the zero point on the Pallas curve caused a panic during proof verification. Both zcashd and zebra now reject $\mathtt{rk}$ encoding $\mathcal{O}_{\mathbb{P}}$. This is a constricting consensus rule change, since the specification previously permitted $\mathtt{rk}$ to encode the zero point. It is enforced by zcashd from v6.12.1, by zebra from v4.3.1, and reflected in the orchard crate from version 0.13.0. ⁷

Changes to chain value balance accounting rules (ZIP 209)

As a consequence of the integer-overflow and value-range hardening described below for zcashd v6.12.1, the following change was made to ZIP 209.

In ZIP 209's Specification section, replace

If any of the "Sprout chain value pool balance", "Sapling chain value pool balance", or "Orchard chain value pool balance" would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.

with

If any of the Sprout chain value pool balance, Sapling chain value pool balance, Orchard chain value pool balance, transparent chain value pool balance, or deferred development fund chain value pool balance would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.

If the sum of these chain value pool balances (i.e. the total supply, computed without possibility of overflow) would become greater than $\mathsf{MAX\_MONEY}$ zatoshis in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.

The extension of the non-negativity rule to the deferred development pool balance had already been implemented for NU6 ^{8 9}.

The extension of the non-negativity rule to the transparent balance, and the rule on the total supply, were implemented in zcashd v6.12.1 ¹⁰, in response to weaknesses in zcashd's chain value pool balance accounting ⁷:

• Chain value pool balance-tracking reset. A duplicate block header could silently reset chain value pool balance-tracking fields, effectively disabling ZIP 209 ¹¹ turnstile enforcement for versions of zcashd from v6.0.0 (the first release in which the bug was triggerable on Mainnet) prior to v6.12.1. A variation on the attack could persist corrupted per-block chain value pool deltas. zcashd v6.12.1 onward defers pool-value initialization until after the duplicate-data check, adds a chain-supply checkpoint at NU6.1 activation covering all value pools, and recomputes shielded chain value pool deltas (since the checkpoint) from block data on startup.

• Chain value pool balance hardening. Complementary to the above fixes, zcashd v6.12.1 onward tightened its implementation of turnstile and lockbox accounting to more rigorously apply overflow/underflow checking, supporting local reasoning about the correctness of the accounting arithmetic.

An intended effect of the latter hardening was to enforce the stricter consensus rules described above in zcashd. Zebra had already been using checked arithmetic consistently, representing each chain value pool balance as an amount required to be non-negative and at most $\mathsf{MAX\_MONEY}$, and constraining each intermediate value to its correct range.

Consensus changes in the Zcash Protocol Specification

This section includes only consensus changes; additional clarifications to the Zcash Protocol Specification are given in a later section.

rk-related changes

Add a consensus rule in § 4.6 ‘Action descriptions’:

• $\mathsf{rk}$ MUST NOT be the zero point $\mathcal{O}_{\mathbb{P}}$.

In the same section, change the non-normative note

• $\mathsf{cv}$ and $\mathsf{rk}$ can be the zero point $\mathcal{O}_{\mathbb{P}}$. $\mathsf{epk}$ cannot be $\mathcal{O}_{\mathbb{P}}$.

to

• $\mathsf{cv}$ can be the zero point $\mathcal{O}_{\mathbb{P}}$. $\mathsf{rk}$ and $\mathsf{epk}$ cannot be $\mathcal{O}_{\mathbb{P}}$.

Add a non-normative note:

• The restriction $\mathsf{rk} \neq \mathcal{O}_{\mathbb{P}}$ was enforced as a "soft fork", without a specific activation height, by zcashd from v6.12.1 and by zebra from v4.3.1 [ZIP-256]. It was introduced in response to a panic that $\mathtt{rk}$ encoding the zero point caused during proof verification, in both zcashd and zebra. The bug occurred in conversion of the $\mathsf{rk}$ Pallas curve point to the corresponding circuit public inputs. The underlying circuit implementation did and does support $\mathsf{rk} = \mathcal{O}_{\mathbb{P}}$, represented with coordinates $(0, 0)$, and that case would have been harmless had it been handled correctly, but excluding it was the simpler and safer response under the circumstances.

Also add a note to § 4.18.4 ‘Action Statement (Orchard)’ explaining that the case $\mathsf{rk} = \mathcal{O}_{\mathbb{P}}$ will not occur due to the above consensus rule.

ZIP 209-related changes

Make changes in § 4.17 ‘Chain Value Pool Balances’ ¹² corresponding to the changes to ZIP 209. These mirror the changes described above and are not spelled out here.

Additional consensus node implementation conformance fixes

Each of the following makes an implementation enforce a rule the protocol specification already defines, restoring agreement of zcashd and zebra to the specification and to each other.

No consensus rule change is introduced for these implementation flaws. Clarifications to the Zcash Protocol Specification relating to two of these flaws are given in that section below.

• Sprout transaction verification. A flaw in zcashd's verification of Sprout proofs on block connection could have allowed invalid Sprout transactions to be accepted. Fixed in zcashd v6.12.0 ¹³. ¹⁴

• Orchard invalid $\mathtt{ephemeralKey}$. An Orchard action with $\mathtt{ephemeralKey}$ encoding the zero point —or any other 32-byte string that does not encode a valid Pallas curve point— was accepted by zcashd but rejected by zebra as required by § 4.6 ¹⁵, a potential consensus split. zcashd now requires $\mathtt{ephemeralKey}$ to decode to a valid non-zero Pallas point. This was partially fixed in zcashd v6.12.1 (rejecting the zero Pallas point encoding) ⁷. The fix was extended to all invalid encodings in v6.12.2 ¹⁶.

• Sapling v4 $\mathtt{valueBalanceSapling}$ normalization. The v4 transaction deserializer accepted a transaction with no Spend descriptions and no Output descriptions, but $\mathtt{valueBalanceSapling}$ encoding a non-zero value. The value was normalized to zero during deserialization, so the consensus check that should have rejected it ran against the normalized zero and never fired. zebra rejected the encoding at deserialization as required by § 7.1.2 ¹⁷, so the malformed encoding would have caused a consensus split. zcashd now rejects it at deserialization, matching zebra. Fixed in zcashd v6.12.2 ¹⁶.

• NU5-onward block-body poisoning. In NU5 and later, the authorizing data of v5 transactions is committed by the header's $\mathtt{hashBlockCommitments}$ (via $\mathtt{hashAuthDataRoot}$), not by $\mathtt{hashMerkleRoot}$. A body-derived rejection firing before the auth-commitment check could permanently mark an honest header invalid. zcashd now pre-checks $\mathtt{hashBlockCommitments}$ before any body-mutable check on the active-tip path, and treats the sidechain case as body-replaceable. This closes the class of vulnerabilities, including the bad-blk-sigops, bad-cb-length, and bad-blk-length trigger paths. Initial fix in zcashd v6.12.2 ¹⁶; structurally closed in v6.12.4 ¹⁸. ¹⁹

• P2SH input sigop count. zebra's P2SH input signature-operation count did not match zcashd; this was corrected to restore agreement. Fixed in zebra v4.5.1 ²⁰.

• Input ordering. zebra did not preserve the order of inputs in spent_outputs for transactions spending a mix of chain and mempool outputs, and so an input could be matched against the wrong spent output during validation. Fixed in zebra v4.2.0 ²¹.

• Other zebra validity fixes. zebra accepted coinbase transactions containing Sapling spends; did not validate transparent input/output alignment before script verification; and could treat a v5 transaction as verified on the basis of its mined transaction id alone. These were corrected in zebra v4.4.0 ²².

Denial-of-service and node-crash hardening

The following issues allowed remotely triggered crashes or unbounded resource use. They affect node liveness but do not change which blocks or transactions are valid.

Zcashd

• Coinbase shielded value-balance crash. A coinbase transaction with a positive Sapling or Orchard value balance would desynchronize chain-supply accounting from pool balances in ConnectBlock, triggering a node abort and a crash loop on restart. Fixed in zcashd v6.12.4. ¹⁹

• Out-of-range pool-value delta. A block whose aggregate per-pool value delta was out of monetary range left the sending peer unbanned, and re-wrote the body to disk on each replay. Fixed in zcashd v6.12.4. ¹⁹

• Use-after-free in ConnectBlock. CVE-2024-52911, a use-after-free in the script verification path inherited from Bitcoin Core ²³. Fixed in zcashd v6.12.3.

• Integer-overflow and value-range hardening. Chain value pool balance accumulation was hardened against undefined behaviour from signed integer overflow. Value range exceptions are now caught as consensus rejections. Fixed in zcashd v6.12.1. ⁷

Zebra

• Unbounded preallocation and duplicate-delivery DoS. The fix for this issue added caps on Vec::with_capacity reservations driven by peer-supplied counts; added caps on block::Hash and CountedHeader allocation; and removed rejected block hashes from SentHashes so that honest re-deliveries are not short-circuited. Fixed in zebra v4.5.0. ²⁴

Clarifications to the Zcash Protocol Specification

These clarifications do not change consensus rules.

§ 7.1.2 ‘Transaction Consensus Rules’

In reference to this rule:

If $\mathsf{effectiveVersion} = 4$ and there are no Spend descriptions or Output descriptions, then $\mathtt{valueBalanceSapling}$ MUST be $0$.

add the note:

zcashd prior to v6.12.1 misimplemented the rule that requires $\mathtt{valueBalanceSapling} = 0$ for a v4 transaction with no Spend descriptions and no Output descriptions. It incorrectly normalized the value to $0$ when no Spend or Output descriptions were present, with the consequence that the failure case for this rule was never reached. For clarification, $\mathtt{valueBalanceSapling}$ refers to the value as encoded in the transaction, which is not normalized in this way; it does not refer to $\mathsf{v}^{\textit{SaplingPoolBalance}}$.

Various sections

Add a non-normative note in section § 7.5 documenting the invalid $\mathsf{ephemeralKey}$ issue and the versions of zcashd it affected.

Wherever else Pallas curve points are decoded, add cross-references to § 5.4.9.6 ‘Pallas and Vesta’, and include implementation notes on validation in that section. Similarly, wherever points on other elliptic curves are decoded, add cross-references to the relevant sections.

Deployment

These fixes were enforced immediately on upgrade in each release below; none was gated on a block height or network-upgrade activation.

Backward compatibility

Most of these fixes tighten validity checks or harden the node, rejecting inputs that were already invalid under the specification but were previously accepted (or mishandled) by one or both full node implementations. Honest blocks and transactions remain valid, so upgraded nodes do not diverge from each other. Where one implementation previously accepted a malformed encoding, the fix restores agreement with the other (for example the Sapling $\mathtt{valueBalanceSapling}$ and Orchard $\mathtt{ephemeralKey}$ cases, where the specification already required the relevant encodings to be rejected).

The exclusion of Orchard $\mathsf{rk}$ = $\mathcal{O}_{\mathbb{P}}$ is a soft fork: it removes transactions from the valid set rather than adding any, so it cannot cause an upgraded node to reject a block that conforming miners produce. $\mathsf{rk}$ is the spend authorization validating key randomized by $\alpha$. When, as specified, $\alpha$ is generated uniformly at random, $\mathsf{rk}$ = $\mathcal{O}_{\mathbb{P}}$ only with negligible probability — so in practice no honest transaction is affected.

The changes to chain value balance accounting would only affect consensus in the event of another violation of intended consensus security properties.

The denial-of-service hardening changes do not affect block or transaction validity.

References

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" ↩

2. ZIP 200: Network Upgrade Mechanism ↩

3. Zcash Protocol Specification, Version 2025.6.3 or later ↩

4. Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 3.12: Mainnet and Testnet ↩

5. ZIP 255: Deployment of the NU6.1 Network Upgrade ↩

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

7. Several Zcash Vulnerabilities Successfully Remediated (Zcash Open Development Lab, 2026-04-17; zcashd v6.12.1, zebra v4.3.1) ↩ ↩² ↩³ ↩⁴

8. Add lockbox funding streams and chain lockbox value pool tracking for NU6 (zcash/zcash#6912) ↩

9. Track the balance of the deferred chain value pool (ZcashFoundation/zebra#8729) ↩

10. zcashd v6.12.1 post-release merge (zcash/zcash#7141) ↩

11. ZIP 209: Prohibit Out-of-Range Chain Value Pool Balances ↩

12. Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 4.17: Chain Value Pool Balances ↩

13. zcashd v6.12.0 post-release merge (zcash/zcash#7133) ↩

14. Zcash Vulnerability Successfully Remediated (Zcash Open Development Lab, 2026-03-31; zcashd v6.12.0) ↩

15. Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 4.6: Action Descriptions ↩

16. Hotfix v6.12.2 (zcash/zcash#7157) ↩ ↩² ↩³

17. Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 7.1.2: Transaction Consensus Rules ↩

18. Zcashd release v6.20.0, which published the v6.12.4 security fixes (zcash/zcash#7174) ↩

19. Urgent Zcash hotfixes v6.12.4 & v6.20.0 (zcashd, affected v5.0.0–v6.13.0) ↩ ↩² ↩³

20. Zebra CHANGELOG — Zebra 4.5.1 (2026-05-29) ↩

21. Zebra CHANGELOG — Zebra 4.2.0 (2026-03-12) ↩

22. Zebra CHANGELOG — Zebra 4.4.0 (2026-05-01) ↩

23. Bitcoin Core disclosure of CVE-2024-52911 ↩

24. Zebra CHANGELOG — Zebra 4.5.0 (2026-05-28) ↩