#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 $𝚛𝚔$ encoding the zero point on the Pallas curve caused a panic during proof verification. Both zcashd and zebra now reject $𝚛𝚔$ encoding ${𝒪}_{\mathbb{P}}$. This is a constricting consensus rule change, since the specification previously permitted $𝚛𝚔$ 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 $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸$ 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 $𝖬𝖠𝖷\_𝖬𝖮𝖭𝖤𝖸$, 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’:

• $𝗋𝗄$ MUST NOT be the zero point ${𝒪}_{\mathbb{P}}$.

In the same section, change the non-normative note

• $𝖼𝗏$ and $𝗋𝗄$ can be the zero point ${𝒪}_{\mathbb{P}}$. $𝖾𝗉𝗄$ cannot be ${𝒪}_{\mathbb{P}}$.

to

• $𝖼𝗏$ can be the zero point ${𝒪}_{\mathbb{P}}$. $𝗋𝗄$ and $𝖾𝗉𝗄$ cannot be ${𝒪}_{\mathbb{P}}$.

Add a non-normative note:

• The restriction $𝗋𝗄\ne {𝒪}_{\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 $𝚛𝚔$ encoding the zero point caused during proof verification, in both zcashd and zebra. The bug occurred in conversion of the $𝗋𝗄$ Pallas curve point to the corresponding circuit public inputs. The underlying circuit implementation did and does support $𝗋𝗄={𝒪}_{\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 $𝗋𝗄={𝒪}_{\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 $𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$. An Orchard action with $𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$ 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 $𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$ 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 $𝚟𝚊𝚕𝚞𝚎𝙱𝚊𝚕𝚊𝚗𝚌𝚎𝚂𝚊𝚙𝚕𝚒𝚗𝚐$ normalization. The v4 transaction deserializer accepted a transaction with no Spend descriptions and no Output descriptions, but $𝚟𝚊𝚕𝚞𝚎𝙱𝚊𝚕𝚊𝚗𝚌𝚎𝚂𝚊𝚙𝚕𝚒𝚗𝚐$ 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 $𝚑𝚊𝚜𝚑𝙱𝚕𝚘𝚌𝚔𝙲𝚘𝚖𝚖𝚒𝚝𝚖𝚎𝚗𝚝𝚜$ (via $𝚑𝚊𝚜𝚑𝙰𝚞𝚝𝚑𝙳𝚊𝚝𝚊𝚁𝚘𝚘𝚝$), not by $𝚑𝚊𝚜𝚑𝙼𝚎𝚛𝚔𝚕𝚎𝚁𝚘𝚘𝚝$. A body-derived rejection firing before the auth-commitment check could permanently mark an honest header invalid. zcashd now pre-checks $𝚑𝚊𝚜𝚑𝙱𝚕𝚘𝚌𝚔𝙲𝚘𝚖𝚖𝚒𝚝𝚖𝚎𝚗𝚝𝚜$ 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 $𝖾𝖿𝖿𝖾𝖼𝗍𝗂𝗏𝖾𝖵𝖾𝗋𝗌𝗂𝗈𝗇=4$ and there are no Spend descriptions or Output descriptions, then $𝚟𝚊𝚕𝚞𝚎𝙱𝚊𝚕𝚊𝚗𝚌𝚎𝚂𝚊𝚙𝚕𝚒𝚗𝚐$ MUST be $0$.

add the note:

zcashd prior to v6.12.1 misimplemented the rule that requires $𝚟𝚊𝚕𝚞𝚎𝙱𝚊𝚕𝚊𝚗𝚌𝚎𝚂𝚊𝚙𝚕𝚒𝚗𝚐=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, $𝚟𝚊𝚕𝚞𝚎𝙱𝚊𝚕𝚊𝚗𝚌𝚎𝚂𝚊𝚙𝚕𝚒𝚗𝚐$ refers to the value as encoded in the transaction, which is not normalized in this way; it does not refer to ${𝗏}^{\text{𝑆𝑎𝑝𝑙𝑖𝑛𝑔𝑃𝑜𝑜𝑙𝐵𝑎𝑙𝑎𝑛𝑐𝑒}}$.

#Various sections

Add a non-normative note in section § 7.5 documenting the invalid $𝖾𝗉𝗁𝖾𝗆𝖾𝗋𝖺𝗅𝖪𝖾𝗒$ 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.

Release	Date	Fixes
zcashd v6.12.0	2026-03-27	Sprout transaction verification
zcashd v6.12.1	2026-04-17	Orchard zero $𝚛𝚔$ / $𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$; chain value-pool accounting; integer-overflow / value-range hardening
zcashd v6.12.2	2026-05-06	Sapling valueBalanceSapling normalization; strengthened $𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$ check; block-body poisoning (initial)
zcashd v6.12.3	2026-05-07	CVE-2024-52911 use-after-free
zcashd v6.12.4	2026-06-01	block-body poisoning (structural); coinbase value-balance crash; out-of-range pool-value delta
zebra v4.2.0	2026-03-12	input-ordering validity fix
zebra v4.3.1	2026-04-17	Orchard zero $𝚛𝚔$ / $𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$
zebra v4.4.0	2026-05-01	coinbase Sapling spend; transparent input/output alignment; v5-verification
zebra v4.5.0	2026-05-28	preallocation / duplicate-delivery DoS
zebra v4.5.1	2026-05-29	P2SH input sigop count

#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 $𝚟𝚊𝚕𝚞𝚎𝙱𝚊𝚕𝚊𝚗𝚌𝚎𝚂𝚊𝚙𝚕𝚒𝚗𝚐$ and Orchard $𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$ cases, where the specification already required the relevant encodings to be rejected).

The exclusion of Orchard $𝗋𝗄$ = ${𝒪}_{\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. $𝗋𝗄$ is the spend authorization validating key randomized by $\alpha$. When, as specified, $\alpha$ is generated uniformly at random, $𝗋𝗄$ = ${𝒪}_{\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) ↩