# ZIP 256: Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2

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-0256) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0256.md) · [Discussion](https://github.com/zcash/zips/issues/1294)

Preamble

**ZIP**: 256

**Title**: Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2

**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/1294](https://github.com/zcash/zips/issues/1294)

<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"></a>
[3](#user-content-fn-protocol)

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 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 <a id="user-content-fnref-zip-0255"></a>
[5](#user-content-fn-zip-0255), up to
but not including the Orchard Temporary Vulnerability Mitigation and the
NU6.2 network upgrade. The latter are documented in ZIP 257. <a id="user-content-fnref-zip-0257"></a>
[6](#user-content-fn-zip-0257).

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

## 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.

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

## Specification

<a id="consensus-rule-changes"></a>

### 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](#consensuschangesinthezcashprotocolspecification)
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. <a id="user-content-fnref-zodl-v6.12.1-fixes"></a>
[7](#user-content-fn-zodl-v6.12.1-fixes)

#### 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 <a id="user-content-fnref-zcashd-lockbox-pr"></a>
[8](#user-content-fn-zcashd-lockbox-pr) <a id="user-content-fnref-zebra-lockbox-pr"></a>
[9](#user-content-fn-zebra-lockbox-pr).

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 <a id="user-content-fnref-zcashd-v6.12.1-pr"></a>
[10](#user-content-fn-zcashd-v6.12.1-pr), in
response to weaknesses in zcashd's chain value pool balance accounting <a id="user-content-fnref-zodl-v6.12.1-fixes-2"></a>
[7](#user-content-fn-zodl-v6.12.1-fixes):

- **Chain value pool balance-tracking reset.** A duplicate block header could
  silently reset chain value pool balance-tracking fields, effectively disabling
  ZIP 209 <a id="user-content-fnref-zip-0209"></a>
  [11](#user-content-fn-zip-0209) 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.

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

### Consensus changes in the Zcash Protocol Specification

This section includes only consensus changes; additional
[clarifications to the Zcash Protocol Specification](#clarificationstothezcashprotocolspecification)
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’ <a id="user-content-fnref-protocol-chainvalue"></a>
[12](#user-content-fn-protocol-chainvalue)
corresponding to the changes to ZIP 209. These mirror the changes described
above and are not spelled out here.

<a id="additional-consensus-node-implementation-conformance-fixes"></a>

### 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](#clarificationstothezcashprotocolspecification)
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 <a id="user-content-fnref-zcashd-v6.12.0-pr"></a>
  [13](#user-content-fn-zcashd-v6.12.0-pr).
  <a id="user-content-fnref-zodl-v6.12.0-fixes"></a>
  [14](#user-content-fn-zodl-v6.12.0-fixes)

- <a id="invalidephemeralkey"></a>
  [**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 id="user-content-fnref-protocol-actiondesc"></a>
  [15](#user-content-fn-protocol-actiondesc), 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) <a id="user-content-fnref-zodl-v6.12.1-fixes-3"></a>
  [7](#user-content-fn-zodl-v6.12.1-fixes). The fix was
  extended to all invalid encodings in v6.12.2 <a id="user-content-fnref-zcashd-v6.12.2-pr"></a>
  [16](#user-content-fn-zcashd-v6.12.2-pr).

- **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 <a id="user-content-fnref-protocol-txnconsensus"></a>
  [17](#user-content-fn-protocol-txnconsensus), so the malformed encoding would have caused
  a consensus split. zcashd now rejects it at deserialization, matching zebra.
  Fixed in zcashd v6.12.2 <a id="user-content-fnref-zcashd-v6.12.2-pr-2"></a>
  [16](#user-content-fn-zcashd-v6.12.2-pr).

- **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 <a id="user-content-fnref-zcashd-v6.12.2-pr-3"></a>
  [16](#user-content-fn-zcashd-v6.12.2-pr); structurally closed in v6.12.4 <a id="user-content-fnref-zcashd-v6.12.4-pr"></a>
  [18](#user-content-fn-zcashd-v6.12.4-pr).
  <a id="user-content-fnref-ghsa-ghc3-g8w4-whf9"></a>
  [19](#user-content-fn-ghsa-ghc3-g8w4-whf9)

- **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 <a id="user-content-fnref-zebra-v4.5.1-changelog"></a>
  [20](#user-content-fn-zebra-v4.5.1-changelog).

- **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 <a id="user-content-fnref-zebra-v4.2.0-changelog"></a>
  [21](#user-content-fn-zebra-v4.2.0-changelog).

- **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 <a id="user-content-fnref-zebra-v4.4.0-changelog"></a>
  [22](#user-content-fn-zebra-v4.4.0-changelog).

<a id="denial-of-service-and-node-crash-hardening"></a>

### 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. <a id="user-content-fnref-ghsa-ghc3-g8w4-whf9-2"></a>
  [19](#user-content-fn-ghsa-ghc3-g8w4-whf9)

- **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. <a id="user-content-fnref-ghsa-ghc3-g8w4-whf9-3"></a>
  [19](#user-content-fn-ghsa-ghc3-g8w4-whf9)

- **Use-after-free in `ConnectBlock`.** CVE-2024-52911, a use-after-free in the
  script verification path inherited from Bitcoin Core <a id="user-content-fnref-cve-2024-52911"></a>
  [23](#user-content-fn-cve-2024-52911). 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. <a id="user-content-fnref-zodl-v6.12.1-fixes-4"></a>
  [7](#user-content-fn-zodl-v6.12.1-fixes)

#### 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. <a id="user-content-fnref-zebra-v4.5.0-changelog"></a>
  [24](#user-content-fn-zebra-v4.5.0-changelog)

<a id="clarifications-to-the-zcash-protocol-specification"></a>

### 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](#invalidephemeralkey) 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.

<a id="deployment"></a>

### 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 $\mathtt{rk}$ / $\mathtt{ephemeralKey}$; chain value-pool accounting; integer-overflow / value-range hardening |
| zcashd v6.12.2 | 2026-05-06 | Sapling `valueBalanceSapling` normalization; strengthened $\mathtt{ephemeralKey}$ 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 $\mathtt{rk}$ / $\mathtt{ephemeralKey}$ |
| 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 |

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

### 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.

<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)

3. [Zcash Protocol Specification, Version 2025.6.3 or later](protocol/protocol.pdf) [↩](#user-content-fnref-protocol)

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

5. [ZIP 255: Deployment of the NU6.1 Network Upgrade](/zip/255) [↩](#user-content-fnref-zip-0255)

6. [ZIP 257: Deployment of the Orchard Temporary Vulnerability Mitigation and NU6.2 Network Upgrade](/zip/257) [↩](#user-content-fnref-zip-0257)

7. [Several Zcash Vulnerabilities Successfully Remediated (Zcash Open Development Lab, 2026-04-17; zcashd v6.12.1, zebra v4.3.1)](https://zodl.com/zcashd-zebra-april-2026-disclosure/) [↩](#user-content-fnref-zodl-v6.12.1-fixes) [↩2](#user-content-fnref-zodl-v6.12.1-fixes-2) [↩3](#user-content-fnref-zodl-v6.12.1-fixes-3) [↩4](#user-content-fnref-zodl-v6.12.1-fixes-4)

8. [Add lockbox funding streams and chain lockbox value pool tracking for NU6 (zcash/zcash#6912)](https://github.com/zcash/zcash/pull/6912) [↩](#user-content-fnref-zcashd-lockbox-pr)

9. [Track the balance of the deferred chain value pool (ZcashFoundation/zebra#8729)](https://github.com/ZcashFoundation/zebra/pull/8729) [↩](#user-content-fnref-zebra-lockbox-pr)

10. [zcashd v6.12.1 post-release merge (zcash/zcash#7141)](https://github.com/zcash/zcash/pull/7141) [↩](#user-content-fnref-zcashd-v6.12.1-pr)

11. [ZIP 209: Prohibit Out-of-Range Chain Value Pool Balances](/zip/209) [↩](#user-content-fnref-zip-0209)

12. [Zcash Protocol Specification, Version 2025.6.3 [NU6.1]. Section 4.17: Chain Value Pool Balances](protocol/protocol.pdf#chainvaluepoolbalances) [↩](#user-content-fnref-protocol-chainvalue)

13. [zcashd v6.12.0 post-release merge (zcash/zcash#7133)](https://github.com/zcash/zcash/pull/7133) [↩](#user-content-fnref-zcashd-v6.12.0-pr)

14. [Zcash Vulnerability Successfully Remediated (Zcash Open Development Lab, 2026-03-31; zcashd v6.12.0)](https://zodl.com/zcashd-sprout-verification-vulnerability/) [↩](#user-content-fnref-zodl-v6.12.0-fixes)

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

16. [Hotfix v6.12.2 (zcash/zcash#7157)](https://github.com/zcash/zcash/pull/7157) [↩](#user-content-fnref-zcashd-v6.12.2-pr) [↩2](#user-content-fnref-zcashd-v6.12.2-pr-2) [↩3](#user-content-fnref-zcashd-v6.12.2-pr-3)

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

18. [Zcashd release v6.20.0, which published the v6.12.4 security fixes (zcash/zcash#7174)](https://github.com/zcash/zcash/pull/7174) [↩](#user-content-fnref-zcashd-v6.12.4-pr)

19. [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) [↩](#user-content-fnref-ghsa-ghc3-g8w4-whf9) [↩2](#user-content-fnref-ghsa-ghc3-g8w4-whf9-2) [↩3](#user-content-fnref-ghsa-ghc3-g8w4-whf9-3)

20. [Zebra CHANGELOG — Zebra 4.5.1 (2026-05-29)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-451---2026-05-29) [↩](#user-content-fnref-zebra-v4.5.1-changelog)

21. [Zebra CHANGELOG — Zebra 4.2.0 (2026-03-12)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-420---2026-03-12) [↩](#user-content-fnref-zebra-v4.2.0-changelog)

22. [Zebra CHANGELOG — Zebra 4.4.0 (2026-05-01)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-440---2026-05-01) [↩](#user-content-fnref-zebra-v4.4.0-changelog)

23. [Bitcoin Core disclosure of CVE-2024-52911](https://bitcoincore.org/en/2026/05/05/disclose-cve-2024-52911/) [↩](#user-content-fnref-cve-2024-52911)

24. [Zebra CHANGELOG — Zebra 4.5.0 (2026-05-28)](https://github.com/ZcashFoundation/zebra/blob/main/CHANGELOG.md#zebra-450---2026-05-28) [↩](#user-content-fnref-zebra-v4.5.0-changelog)

## Citation relationships

Cites: [ZIP 200](https://zips.tools/zip/200), [ZIP 201](https://zips.tools/zip/201), [ZIP 209](https://zips.tools/zip/209), [ZIP 255](https://zips.tools/zip/255), [ZIP 257](https://zips.tools/zip/257)

Cited by: [ZIP 209](https://zips.tools/zip/209), [ZIP 257](https://zips.tools/zip/257), [ZIP 258](https://zips.tools/zip/258), [ZIP 374](https://zips.tools/zip/374)