Valar Group

Run the state-of-the-art Zcash node

Zakura

Alpha

Primary mode

Zakura

Overview

Zakura is a Valar Group's implementation of a Zcash node. It is an evolution of Zebra. Zakura's network stack is interoperable with zcashd. Zakura implements all the features required to reach Zcash network consensus including the validation of all the consensus rules.

  • QUIC-based P2P: a new layer running alongside today's legacy TCP network, giving Zakura lower-latency peer communication without breaking compatibility. Includes native peer discovery, service discovery, header sync, structured tracing, and protections against malformed or abusive peers.
  • Consensus updates: updated difficulty adjustment rules, shielded action limits, a larger reorg window, and faster mempool crawling, keeping Zakura reliable as Zcash moves toward shorter block times.
  • Future-ready: faster networking, better sync foundations, stronger observability, and consensus changes aligned with the next generation of Zcash protocol upgrades.

Install and Run Zakura

Download and run the standalone Zakura installer from the latest Zebra GitHub release. It guides native, Docker, and build-from-source setup modes and downloads only Zebra binaries. 

curl -fsSL https://github.com/valargroup/zebra/releases/latest/download/install-zakura.sh | bash

Zcashd compatibility mode

zebra-zcashd-compat Mode

Use this mode to run Zebra for consensus and P2P while preserving the zcashd wallet API during migration.

Integration Summary

Zebra is responsible for consensus and P2P. zcashd is kept for wallet and zcashd-compatible RPC surfaces, and ingests chain and mempool data from Zebra over authenticated RPC. By default, operators run Zebra and zcashd as separate processes; supervised mode can be enabled when Zebra should manage the zcashd child process. The primary purpose of this integration is to allow exchanges to smoothly migrate to Zebra node without disrupting their existing zcashd setup.

  • Trust boundary: zcashd trusts the configured Zebra node for block source and transaction forwarding.
  • Transport: zcashd talks to Zebra over RPC only (no zcashd P2P in compat mode).
  • Auth: keep Zebra cookie auth enabled and avoid exposing RPC publicly.
  • Deployment: deploy zcashd and Zebra on the same machine.
  • Lifecycle: externally managed mode is the default: start Zebra with --zcashd-compat, then run zcashd yourself. Managed mode is an opt-in supervisor that manages the zcashd process lifecycle at runtime. For container builds, zcashd artifact fetch and SHA verification happen outside the Dockerfile before image build.

Pre-requisites

Since alongside your zcashd wallet API there is also a Zebra node, the hardware requirements are increased. Please ensure that you provision the recommended hardware before restarting from the updated binary.

Hardware requirements

  • CPU: 8 logical CPUs available to the process.
  • RAM: 32 GiB effective memory.
  • Disk: at least 1 TiB combined capacity across the filesystems used by Zebra state and zcashd datadir.

Startup fails below the minimums: 4 logical CPUs, 16 GiB RAM, 300 GiB per data volume (600 GiB if Zebra state and the zcashd datadir share a filesystem). Bypass only with --unsafe-low-specs. Linux x86_64 only.

Downloads

Binaries:

Snapshots:

Install zcashd-compat

  1. Run Installer

    Download and run the installer from the latest Zebra GitHub release. It guides the setup flow and uses the release-published zcashd-compat assets. 

    curl -fsSL https://github.com/valargroup/zebra/releases/latest/download/install-zcashd-compat.sh | bash

    The installer is uploaded as a release asset and included in the release SHA256SUMS.txt alongside the zcashd-compat artifacts.

FAQ

  • How do I preserve my original zcashd configuration?

    Point Zebra at your existing zcashd data directory with zcashd_datadir, and pass any required zcashd CLI arguments through zcashd_extra_args. These settings can be provided in Zebra configuration, or through equivalent runtime overrides where supported. See the full instructions for details. Remove peer-directing options (bind=, whitebind=, connect=, addnode=, seednode=) from your existing zcash.conf first. Startup fails validation if they are present.

  • If my original hardware is below the recommended specification, do I have to provision more resources?

    Yes. Because this mode runs Zebra alongside the zcashd wallet API, nodes below the minimum specification fail startup preflight; between minimum and recommended, Zebra starts with warnings but is not supported for production. Provision hardware that meets the requirements in this guide before restarting with the updated binary.

  • I have a restricted setup that does not allow IPC and also restricts networking. What do you recommend?

    Build from source and configure the components manually. This gives you direct control over how Zebra and zcashd communicate in your restricted environment.

  • How is my old zcashd config managed?

    Even if present, the system force-disables the following zcashd config parameters: p2p, listen, dnsseed, listenonion, as p2p is unused. Otherwise, zcashd would fail to start.

  • What happens if I do not have a prior config?

    For externally managed zcashd, create the one-line acknowledgement shown above before starting zcashd. In supervised mode, Zebra creates a minimal zcash.conf for the managed child if one is missing. See the full instructions for details about location.