Zebra v6.2.0

Zebra 6.2.0 - 2026-07-17

Zebra 6.2.0 adds an experimental migration path for exchanges and custodial services that still depend on the zcashd wallet and RPC interfaces. Zebra handles Zcash networking and consensus while a constrained zcashd sidecar retains the existing wallet, RPC, and ZMQ surface. Existing Zebra deployments are unchanged unless zcashd-compat mode is enabled.

Update Priority

User Type	Priority	Reason
Exchanges and custodial services evaluating migration from zcashd	Medium	Adds the experimental zcashd-compat mode and migration tooling
General operators	Low	No required migration; existing node operation is unchanged

---

Added

• New experimental zcashd-compat mode (zebrad start --zcashd-compat or the [zcashd_compat] configuration section). Zebra faces the Zcash network while a hard-locked zcashd wallet runs as a sidecar connected only to the local Zebra node. Zebra can optionally download, supervise, and restart the SHA256-pinned sidecar. The release also includes an interactive installer with binary, Docker, and source-build modes, plus operational documentation and sync-check tooling (#10952). Credits to the Zakura authors for the major part of this implementation.
• New Regtest-only generatetoaddress RPC that mines blocks paying the coinbase to a caller-specified address. This allows test harnesses to fund multiple wallets from one Zebra node (#10952).

Fixed

• The installer's docker-supervised mode now configures the embedded sidecar source, so its generated command works with the published Zebra image (#11008).

---

How to Upgrade

Upgrading from Zebra 6.1.0 does not require a state migration or resync.

Docker

docker pull zfnd/zebra:6.2.0
# or update your compose file and:
docker compose pull && docker compose up -d

Binary

1. Stop zebrad (systemctl stop zebrad or Ctrl+C) and wait for a clean shutdown.
2. Replace the binary with zebrad-6.2.0-<arch>-unknown-linux-gnu.tar.gz from this release's assets, or run cargo binstall zebrad.
3. Start zebrad again.

Source

git fetch && git checkout v6.2.0
cargo build --release

Source builds require Rust 1.91 or newer, protoc, a C++ compiler, and libclang.

For installation and safety guidance, see zcashd-compat mode.

Compatibility

Component	Supported
Operating systems	Linux (prebuilt binaries: x86_64 and aarch64, glibc 2.34+); macOS and Windows via source build
Zcash protocol	All network upgrades through NU6.3 (Ironwood)
State database	Format 28.0.0; unchanged from Zebra 6.1.0, no resync required
Minimum Rust for source builds	1.91
zcashd compatibility	Experimental constrained-sidecar mode; review the safety guidance before production use
End of support	Block 3,537,960, approximately 105 days after release

Contributors

Thank you to everyone who contributed to this release. We couldn't make Zebra without you:

@arya2 and @gustavovalverde.

Zebra 6.1.0

Zebra 6.1.0 - 2026-07-17

Added

• Added the getstandardfee RPC, a parameterless method returning the
  recommended standard fee per logical action (the ZIP-317 marginal fee, 5000
  zatoshis) with a version field for future dynamic fee estimation
  (#10717).

Security

• Reserve space for the block header and transaction count when selecting block template
  transactions, so blocks mined from Zebra's templates can no longer exceed the consensus size
  limit (GHSA-95m2-vx53-v2jw).
• Avoid quadratic validation work when checking the remaining transparent value of blocks with
  many transactions (GHSA-4g24-549m-hp75).
• Prevent a peer from stalling chain synchronization by delivering a rejected
  block body that shares its header hash with a later valid block
  (GHSA-8gxx-hc65-vv82).
• Score misbehavior for peers that directly push consensus-invalid transactions, matching the
  treatment of peers that advertise them
  (GHSA-g7c4-2w6c-cr3r).

Zebra zcashd-compat preview 6.0.0-zcashd-compat.2 (Docker)

Second preview release of Zebra's zcashd-compat mode from the zcashd-compat branch (PR #10952). This is not a mainline Zebra release. See v6.0.0-zcashd-compat.1 for the mode overview and validation status.

What's new: a self-contained Docker image

This release publishes zfnd/zebra:6.0.0-zcashd-compat.2 — a single image bundling zebrad (with zcashd-compat support) and the hash-pinned zcashd wallet sidecar (zcashd + zcash-cli from ZcashFoundation/zcashd zebra-compat-v1.0.0), for the supervised sidecar configuration:

docker pull zfnd/zebra:6.0.0-zcashd-compat.2

# Supervised sidecar mode (Zebra spawns and supervises zcashd):
docker run -e ZEBRA_ZCASHD_COMPAT__MANAGE_ZCASHD=true \
  zfnd/zebra:6.0.0-zcashd-compat.2 zebrad start --zcashd-compat

# Or run it as a plain Zebra node:
docker run zfnd/zebra:6.0.0-zcashd-compat.2

See the Zebra Book chapter book/src/user/zcashd-compat.md on the branch for full configuration (data directories, RPC exposure, network selection), or use make compat-docker-start.

The image is linux/amd64 only (the sidecar release ships x86_64 binaries only).

Other artifacts

• install-zebra.sh — the interactive installer; its Docker modes now use the image above (binary mode still uses the v6.0.0-zcashd-compat.1 zebrad archive)
• zebrad binary archives are attached by CI after publication

Changes since v6.0.0-zcashd-compat.1

• The runtime-zcashd-compat Docker stage downloads and SHA256-verifies the sidecar inside the build — no externally prepared build context needed; docker build --target runtime-zcashd-compat . just works
• Branch releases publish that image to Docker Hub
• Installer Docker modes point at the published image

Zebra zcashd-compat preview 6.0.0-zcashd-compat.1

Preview release of Zebra's zcashd-compat mode from the zcashd-compat branch (PR #10952).

This is not a mainline Zebra release but does include fixes for zakura-core/zakura#198, zakura-core/zakura#199, zakura-core/zakura#200, and zakura-core/zakura#201.

What is this?

Zebra faces the Zcash network while a hard-locked zcashd wallet build runs as a P2P sidecar with a single outbound connection to the local Zebra node — for operators migrating from zcashd who still need its wallet and RPC surface. Zebra can optionally download (SHA256-pinned), spawn, and supervise the sidecar. See the Zebra Book chapter book/src/user/zcashd-compat.md on the branch for setup and operations.

Install

Download install-zebra.sh from this release, then:

chmod +x install-zebra.sh
./install-zebra.sh

The interactive installer offers binary, Docker, and build-from-source modes. Binary mode downloads the zebrad archive attached to this release and the sidecar zcashd from ZcashFoundation/zcashd zebra-compat-v1.0.0, both SHA256-pinned.

Artifacts

Asset	Description
install-zebra.sh	Interactive installer
zebrad-6.0.0-zcashd-compat.1-x86_64-unknown-linux-gnu.tar.gz	zebrad with zcashd-compat support, built from 954c928c6
...tar.gz.sha256	Archive checksum

The zebrad binary was built on Ubuntu 24.04 and requires glibc ≥ 2.39. No aarch64 build is provided for this preview.

Validation

• zcashd wallet RPC conformance harness passes end-to-end against the live pairing (single-node and 3-node shielded flows)
• Rust zcashd-compat integration suite: 26/26 pass against the shielded-first sidecar
• 500-iteration reorg churn soak: pass

Caveats

• Preview quality: PR #10952 is still under review.
• No Docker Hub images are published for this tag; the installer's Docker mode expects images that are not yet available — use binary or build-from-source modes.
• The sidecar zcashd is a shielded-first build: legacy transparent wallet RPCs (e.g. getnewaddress) are disabled; use the account / unified-address / z_* flow.

Zebra v6.0.0

Zebra 6.0.0 - 2026-07-10

This release activates NU6.3 (Ironwood) on Zcash Mainnet at block height 3,428,143 (~2026-07-28).

⚠️ All node operators must upgrade before the activation height.

It also fixes a mempool denial-of-service issue where non-standard transparent inputs
were rejected only after the more expensive script verification step
(GHSA-84j3-rw4c-gqmj).

Update Priority

User Type	Priority
All operators	Critical

Network Upgrade Details

Activation Height	3,428,143
Expected Date	~2026-07-28
Consensus Branch ID	0x37a5165b
Testnet Activation	Block 4,134,000 (active since v6.0.0-rc.0)

Implemented ZIPs

• ZIP 258: Deployment of the NU6.3 Network Upgrade
• ZIP 229: Version 6 Transaction Format
• ZIP 2005: Ironwood Quantum Recoverability
• ZIP 2006: Restricting Transfers into the Orchard Pool
• ZIP 318: Orchard to Ironwood Migration

---

Added

• NU6.3 (Ironwood) now activates on Mainnet at block height 3,428,143, matching
  zcash_protocol. Node operators must upgrade to this release before activation
  (#10938).

Changed

• Updated the zcash_* and orchard crates to their released NU6.3 versions
  (#10938).
• Updated rocksdb to 0.24. The bundled librocksdb-sys now always runs
  bindgen to generate its FFI bindings, so libclang is required at build
  time (in addition to protoc and a C++ compiler) even when linking a system
  RocksDB via ROCKSDB_LIB_DIR. Install libclang-dev (Debian/Ubuntu),
  clang (Arch), or the equivalent for your platform
  (#10922).
• Bumped the workspace (libraries) MSRV from 1.85.1 to 1.88. The zebrad binary
  MSRV is unchanged at 1.91. home is no longer pinned to 0.5.11, since 0.5.12
  builds on the new MSRV
  (#10927).

Fixed

• Keep the mempool active through transient sync-status noise. Once started, the
  mempool is no longer cleared and its queued transaction verification is no longer
  cancelled when a temporary signal (which lower-work forks or stale peers can
  trigger) reports Zebra is far from the tip; initial activation still waits until
  Zebra is near the chain tip
  (#10929).
• Don't disconnect from peers that return empty FindBlocks or FindHeaders
  responses when the local node is at or near the chain tip
  (#10732)
• Fix syncer restarts due to incorrect error downcasting
  (#10916).
• Fix a read-state syncer startup hang: a co-located consumer whose finalized state
  had caught up past the node's non-finalized root would re-subscribe endlessly
  instead of syncing, advancing only one block per newly mined block
  (#10841)
• Mempool transactions with non-standard transparent inputs are now rejected
  before script verification, to avoid the more expensive script verification
  and reduce DoS surface
  (GHSA-84j3-rw4c-gqmj).
  Thanks to @ouicate for reporting the issue.
• Related to the previous item, script verification now runs on the shared Rayon
  thread pool to avoid blocking the runtime.

---

How to Upgrade

Upgrading from 5.x or 6.0.0-rc.0 keeps your synced state: the first start migrates
the state database in place to format 28, with no resync.

Docker

docker pull zfnd/zebra:6.0.0
# or update your compose file and:
docker compose pull && docker compose up -d

Binary

1. Stop zebrad (systemctl stop zebrad or Ctrl+C) and wait for a clean shutdown
2. Replace the binary with zebrad-6.0.0-<arch>-unknown-linux-gnu.tar.gz from this
   release's assets (signed; Linux x86_64 and aarch64, glibc 2.34+), or run
   cargo binstall zebrad
3. Start zebrad again

Source

git fetch && git checkout v6.0.0
cargo build --release

Source builds need Rust 1.91+, protoc, a C++ compiler, and libclang (new in
this release).

Compatibility

Component	Supported
Operating Systems	Linux (prebuilt binaries: x86_64/aarch64, glibc 2.34+); macOS and Windows via source build
Zcash Protocol	All network upgrades through NU6.3 (Ironwood)
State database	Format 28.0.0; in-place upgrade from 5.x, no resync
Minimum Rust (source builds)	1.91
End of support	Block 3,528,960 (~105 days after release)

Contributors

Thank you to everyone who contributed to this release, we couldn't make Zebra without you:
@arya2, @conradoplg, @Cosmos-Harry, @dannywillems, @gustavovalverde, @jvff, @oxarbitrage, @upbqdn and @ValarDragon.

Zebra 6.0.0-rc.0

Added

• Support for the NU6.3 "Ironwood" shielded pool and v6 transaction format,
  activating on Testnet at height 4,134,000. The consensus parameters (v6 version
  group ID, consensus branch ID, and Testnet activation height) match
  zcash_protocol. No Mainnet activation height is set yet.
• The z_gettreestate, z_getsubtreesbyindex, and verbose getblock RPCs expose the
  Ironwood note commitment tree and its subtree roots from NU6.3 activation
  (#10888).
• Zebra now tags the coinbase input of every block it mines with a 🦓. The
  mining.extra_coinbase_data option is now limited to 86 bytes (was 94); Zebra
  refuses to start if it is exceeded.
• Pre-built zebrad binaries are attached to each GitHub release for Linux on
  x86_64 and aarch64, so operators can run a node without Docker or a source
  build, also installable with cargo binstall zebrad. Each .tar.gz carries a
  SHA-256 checksum, a Sigstore build-provenance attestation, and a Cosign signature
  over the checksum manifest (#10799)
• Added a Regtest configuration option, should_allow_unshielded_coinbase_spends,
  to forbid spending coinbase outputs into transparent outputs (the inverse of
  zcashd's -regtestshieldcoinbase). It defaults to allowing such spends, preserving
  existing Regtest behavior (#10698)
• When the indexer RPC is enabled, a co-located read-state consumer can follow the
  node more efficiently: the non-finalized block subscription resumes from the
  consumer's known chain tips instead of re-streaming the whole non-finalized state,
  and a new GetBlock indexer method lets the consumer fetch blocks it is missing
  while its finalized state catches up.
• New zebra-state read request ReadRequest::FindForkPoint (with response
  ReadResponse::ForkPoint) that returns the most recent block in a caller-supplied
  locator that is on the best chain — the fork point — for clients tracking chain
  reorganizations through a read-only state service.
• Added a [notify] block_notify_command option that runs a command on each best-chain-tip
  change, with %s replaced by the new block hash — Zebra's equivalent of zcashd's
  -blocknotify.

Changed

• The state database format is bumped to 28.0.0 for the NU6.3 "Ironwood" shielded
  pool. This is a major-version bump that is restorable in place from the previous
  major format version (no resync): an in-place migration backfills the genesis
  Ironwood note commitment tree and anchor, four new (initially empty) ironwood_*
  column families are created, and the chain value pool record is widened to include
  the Ironwood pool. The getblockchaininfo and getblock valuePools now include
  the (zero, until NU6.3 activates) ironwood pool.
• Opening a Zebra state read-only (for example, as a secondary instance over a
  running node's database) now fails with a clear error instead of panicking when
  the cache directory is missing or unreadable, when no database exists at the
  configured path, or when an ephemeral database is also configured (a read-only
  secondary must not delete the primary's files). The read-write open path is
  unchanged.
• Upgraded the librustzcash crate cohort to the NU6.3 pre-release wave (orchard
  0.15.0-pre.1, zcash_address 0.13.0-pre.0, zcash_history 0.5.0-pre.0, zcash_keys
  0.15.0-pre.0, zcash_primitives 0.29.0-pre.0, zcash_proofs 0.29.0-pre.0,
  zcash_protocol 0.10.0-pre.0, zcash_transparent 0.9.0-pre.0) for v6 transaction
  and Ironwood support (#10762).
• Bumped anyhow to 1.0.103, clearing RUSTSEC-2026-0190
  (#10849).

Fixed

• getblocktemplate now caches the built coinbase transaction per block, so repeated short-poll
  requests within the same block no longer rebuild it. This prevents CPU saturation and multi-second
  template latency when mining to a shielded (Sapling or Orchard) address
  (#10847)
• Released zebrad binaries report their source commit in zebrad version
  (#10798)
• Handle invalidateblock and reconsiderblock edge cases (chain-root and
  same-height sibling-tip invalidation, repeated reconsideration) without panicking
  (#10586)
• A timeout waiting for a transparent input UTXO during transaction verification is
  now treated as a missing input instead of an internal error, preventing a sync
  stall near the chain tip (#10810)
• The co-located read-state syncer (used by indexers like Zaino) no longer drops and
  re-creates its non-finalized block subscription every second while its view of the
  finalized state lags the node's
  (#10818)

Security

• Use constant-time comparison for RPC cookie authentication (#10567)
• Zebra's release Docker images are now reproducible: an independent rebuild of a
  published zebrad from the same commit produces the same binary. The Rust
  toolchain and the Rust and Debian base images are pinned by exact version and
  digest, and build paths and file timestamps are normalized, so two independent
  builds of the same commit produce the same binary. Release images are also built
  without the shared build cache, so a published image cannot inherit a layer from
  a lower-trust build
  (#10798)
• Release Docker images are signed and carry build provenance and a signed SBOM.
  Each production release gets a Cosign keyless signature, a signed SLSA provenance
  attestation, and a signed SBOM, so anyone can confirm an image came from Zebra's CI
  with cosign verify or gh attestation verify
  (#10798)
• Route directly pushed transactions (tx messages) through the same per-peer
  mempool admission accounting as advertised transaction IDs, so a single inbound
  peer cannot bypass the per-peer download cap by pushing full transactions
  instead of advertising them
  (GHSA-m9xx-8rcj-vmgp).
  This is the direct-push counterpart of the advertisement-path fix in
  GHSA-4fc2-h7jh-287c. Thanks to @SuplabsYi for reporting the issue.
• Fixed a panic in the getblock RPC at verbosity 2 for blocks not in the best
  chain: their transactions' confirmations are negative and were cast to an
  unsigned type
  (GHSA-x6v8-c2xp-928m).

Contributors

Thank you to everyone who contributed to this release, we couldn't make Zebra without you:
@andres-pcg, @conradoplg, @dannywillems, @emersonian, @gustavovalverde, @nuttycom, @syszery, @upbqdn and @zmanian.

Zebra 5.2.0

Zebra 5.2.0 - 2026-06-18

This release increases Zebra's local rollback window as a defence-in-depth measure
against sustained consensus splits.

Changed

• Increased Zebra's local rollback window (MAX_BLOCK_REORG_HEIGHT) from 99 to
  1000 blocks as a defence-in-depth measure against sustained consensus splits
  (#10650)

Zebra 5.1.1

Zebra 5.1.1 - 2026-06-11

This release reduces Zebra's end-of-support window ahead of the NU7 network upgrade
expected at the end of July 2026, so that nodes running outdated versions stop before
the upgrade activates.

Changed

• Reduced the end-of-support period from 105 to 44 days, and updated the estimated
  release height, ahead of the NU7 network upgrade
  (#10710)

Zebra 5.1.0

Zebra 5.1.0 - 2026-06-10

This release fixes a genesis-to-tip sync stall that could cause new nodes to hang
during initial block download, bumps the minimum network protocol version to NU6.2,
extends the getpeerinfo RPC, and includes several performance and correctness fixes.

Breaking Changes

• The minimum network protocol version is now NU6.2 (170150). Peers running protocol
  versions below NU6.2 will be disconnected. Update to Zebra 5.0.0 or later to remain
  compatible (#10692).

Added

• Extended getpeerinfo RPC with subver, version, services, lastrecv,
  banscore, and connection_state fields (#10443)

Fixed

• Fixed genesis-to-tip sync stall that could cause new nodes to hang during initial
  block download (#10679)
• Fixed mempool index being unnecessarily rebuilt per transaction in getrawmempool
  (#10599)
• Fixed dequeue_children by-height index handling in the state service
  (#10604)

Contributors

Thank you to everyone who contributed to this release:
@andres-pcg, @conradoplg, @gustavovalverde, @judah-caruso, @oxarbitrage, @syszery and @upbqdn

Zebra 5.0.0 (NU6.2)

Zebra 5.0.0 - 2026-06-02

This release activates the NU6.2 network upgrade. NU6.2 re-enables Orchard
actions (temporarily disabled by the 4.5.3 soft fork) using the fixed Orchard
Action circuit, which fixes a critical bug in the Orchard pool. NU6.2
activates at block height 3,364,600 on Mainnet and 4,052,000 on Testnet. We
recommend node operators update before the activation height.

If the activation height has passed and your node followed a fork, you will need
to sync from scratch. If you have a backed-up state before the activation
height, you can sync from that.

Added

• Activate the NU6.2 network upgrade (consensus branch id 0x5437f330) at height 3,364,600
  on Mainnet and 4,052,000 on Testnet. NU6.2 re-enables Orchard actions with the fixed
  Orchard Action circuit and routes Orchard proofs to a per-circuit verifying key
  (InsecurePreNu6_2 / FixedPostNu6_2).
• Advertise network protocol version 170150 for NU6.2 on Mainnet, Testnet, and Regtest.

Changed

• Set the default Testnet temporary Orchard-disabling soft-fork height to 4,048,500; the
  disable window runs until NU6.2 re-enables Orchard actions at height 4,052,000.

Security

• Add a consensus rule that rejects Orchard bundles whose proof has a non-canonical size,
  effective from the NU6.2 network upgrade (GHSA-jfw5-j458-pfv6).