Zebra is a Zcash full node written in Rust

A full node for Zcash, in Rust

Zebra is described simply: a Zcash full node written in Rust, with the tagline Financial Privacy in Rust. It is maintained by the Zcash Foundation, the primary language is Rust, and the homepage is zfnd.org/zebra.

A full node validates the chain rather than trusting a server for it, which is the security property that matters for a privacy focused currency, and the reason a second implementation is valuable at all. The README's structure suggests a project that has moved from prototype to production infrastructure: there are badges for unit tests, lint, integration tests on GCP, codecov coverage, building the book, and deploying nodes to GCP.

The repository is a Cargo workspace with a dozen member crates, listed in the workspace manifest: zebrad, which is the node binary, plus zebra-chain, zebra-network, zebra-state, zebra-script, zebra-consensus, zebra-rpc, zebra-node-services, zebra-test, zebra-utils, tower-batch-control and tower-fallback.

The names tell you how the work is divided. The chain crate holds the consensus rules, the network crate the peer to peer layer, the state crate the state machine, the script crate the transaction script, the consensus crate the validation logic, the rpc crate the interface, and node-services the glue. The two tower crates are interesting: they are the batch control and fallback pieces of a request stack, which is how a node handles a burst of requests without making every peer connection wait for a full round trip.

The workspace package metadata sets rust-version 1.88 and edition 2021, with the resolver set to version 2 to match it.

Running a node from the Docker image

The easiest way to run Zebra is the published image, and the command in the README is short enough to memorise:

docker run -d \
  --name zebra \
  -p 8233:8233 \
  -v zebrad-cache:/home/zebra/.cache/zebra \
  zfnd/zebra:latest

The README explains both flags, and the reasoning behind them is the reason to run a node at all. The -p 8233:8233 flag exposes the P2P port so other Zcash nodes can connect to yours, which is what makes your node a participant in the network rather than an isolated observer. The -v flag persists the chain state across restarts, and the volume is named, zebrad-cache, mounted at the cache directory inside the image.

The same note covers Testnet, where the port is 18233. That detail is the kind of thing that separates a node that works from one that quietly fails to peer, because a Testnet node listening on the mainnet port connects to nothing.

The image is published under zfnd/zebra on Docker Hub, and the README points at the Docker documentation in the book for more.

For an organisation running nodes as a service, the book has a dedicated page on Zebra Health Endpoints, described as liveness and readiness checks for Kubernetes and load balancers. That is the piece to read before you put Zebra behind a load balancer, because a node that is up but not synced is a different failure from a node that is down, and only the readiness check distinguishes them.

Building from source, and the GCC 15 problem

A manual build needs Rust, libclang and a C++ compiler. The README gives the general instructions: install cargo and rustc, install libclang, which comes under various names such as libclang, libclang-dev, llvm or llvm-dev, install clang or another C++ compiler, g++ on all platforms or Xcode on macOS, and optionally protoc.

The Arch Linux recipe is one line:

sudo pacman -S rust clang protobuf

with the note that the clang package includes libclang as well.

Then there is the problem worth reading about. GCC 15, which is the default on many recent distributions including Arch Linux and Ubuntu 25 onwards, introduces a compiling failure in the version of the rocksdb dependency used by Zebra. The workaround is to export a flag before installing:

export CXXFLAGS="$CXXFLAGS -include cstdint"

That is a compilation failure inside a transitive dependency, which is the kind of problem that makes a source install a bad idea for a first attempt. A rocksdb build that fails on a toolchain default is a maintenance tax that lands on whoever is trying the project, and it is why the prebuilt binary path exists.

The build itself is then the standard cargo install, and the README also shows the GitHub form with an explicit tag:

cargo install --locked zebrad

cargo install --git https://github.com/ZcashFoundation/zebra --tag v6.0.0 zebrad

And the node starts with:

zebrad start

Signed binaries and a way to skip the build

On x86_64 or aarch64 Linux with glibc 2.34 or newer, the README says you can skip the build dependencies entirely and download a signed pre-built binary with cargo binstall:

cargo binstall zebrad

That is the path most people should take, because it avoids the libclang, C++ compiler and rocksdb problems entirely, and because the artefact is the one the project publishes.

The same binaries are attached to each GitHub release, and the README is specific about what comes with them: a SHA-256 checksum, a Sigstore build-provenance attestation, and a Cosign signature. That combination is worth a moment of attention, because it is what turns a download into a verifiable one. The checksum tells you the file is intact, the Cosign signature tells you the project signed it, and the Sigstore provenance attestation tells you where the build came from, which is the piece that a checksum alone cannot give you.

The project also publishes a supply-chain directory in the repository, alongside a Cargo.lock, a deny.toml for cargo-deny, a .changie.yaml for changelog entries, a release-plz.toml and a release.toml for release automation, and a rust-toolchain.toml pinning the toolchain. Those are the artefacts of a project that treats reproducibility as part of the product, which fits a project whose entire point is that you do not have to trust anybody's word about state.

The documentation is split the same way: the Zebra Book for general, user and developer documentation, the public API documentation on docs.rs for the released crates, and internal API documentation for the main branch of the monorepo.

The zcashd compatibility layer and its Make targets

The Makefile in the repository is not a general build file. It includes make/zcashd-compat.mk and its help target lists a single group of targets, all about zcashd compatibility.

That is a deliberate engineering decision with a clear rationale. The original Zcash node, zcashd, is the C++ implementation, and a large amount of tooling in the ecosystem expects it: monitoring that scrapes its RPC, scripts that call its specific methods, operational runbooks. A new implementation that replaced it without a compatibility path would be a clean break for everyone who depends on the old one.

The targets are fine grained. There is compat-docker-build to build the zcashd-compat image, compat-zcashd-prepare to fetch and verify the sidecar artifact for tests, compat-docker-start to start the sidecar with mounted snapshots, compat-zebrad-start-supervised and compat-zebrad-start-unsupervised to run zebrad with zcashd supervision enabled or disabled, compat-zcashd-start-standalone to run the sidecar as its own process, compat-zebrad-status and compat-zcashd-status to check liveness and RPC health, and compat-status-sync to run both status checks and enforce a maximum drift between them.

That last target is the interesting one. Running zcashd and zebrad side by side, and then measuring whether the two agree, is how you validate a new consensus implementation without asking anyone to trust it. The drift check is the mechanism, and it is the kind of test that only exists in projects where the old implementation is still around to compare against.

The repository also has a zebra-scan/ and a zebra-fuzz/ directory alongside the workspace members, which are not in the workspace list, and a deploy/ directory for the GCP node deployment that the badges refer to.

Releases, CI and the licence split

The release history is short versions with a clear major version story. v6.4.1 was published on 2026-09-23, v6.4.2 on 2026-09-25, and v7.0.0-rc.0 on 2026-10-02, with the last push to the repository on 2026-10-20. A release candidate rather than a final 7.0.0 is the current headline, which is the signal to read the changelog before planning an upgrade.

The CI/CD section of the README is unusually detailed about what the pipeline does. It runs automated tests on every pull request and commit, manages deployments to various environments, handles cross-platform compatibility checks, and automates the release process, with a separate documentation file describing the architecture including workflow diagrams.

The badges are worth mapping to their workflows, because they tell you what is actually checked. Unit tests and lint run on every change, integration tests run on GCP, which tells you the integration suite needs real cloud infrastructure, and there is a separate workflow that deploys nodes to GCP.

On the licence, the README says Zebra is distributed under the terms of both the MIT licence and the Apache License version 2.0, and that some crates are distributed under the MIT licence only, because some of their code was originally from MIT licensed projects. The repository carries LICENSE-APACHE and LICENSE-MIT, and the workspace metadata records the licence as MIT OR Apache-2.0. The project record for the repository lists Apache-2.0, so the per-crate split is the detail to check if you are vendoring a single crate rather than the whole node.

For support, the README points at the issue tracker for bugs, a known issues list in the troubleshooting section of the book, and a zebra-support channel in the Zcash Foundation Discord. It also has a responsible disclosure policy in SECURITY.md, which the README asks security researchers to follow.

Editorial conclusion

Adopt Zebra if you run a Zcash node, want a Rust implementation with reproducible builds and signed release artefacts, and need the zcashd compatibility sidecar to keep existing tooling working. Do not adopt it if you need a stable, pinned release with a predictable upgrade path, since the current line is a 7.0.0 release candidate and the README does not describe a rollback. Before you upgrade, read the CHANGELOG.md and the release notes for the version you are moving to, and check the health endpoints documentation, which is what the project points load balancers and Kubernetes at.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ZcashFoundation/zebra on GitHub