When you send $ZEC or wait for a transaction to confirm, an important piece of infrastructure is working behind the scenes: nodes.
Nodes connect to the Zcash peer-to-peer network, download and validate blockchain data, enforce consensus rules, and relay transactions and blocks to other participants. In simple terms, they help keep everyone independently following the same Zcash blockchain.
But the software powering Zcash nodes has changed considerably over the years. It started with zcashd, expanded with the independently developed Zebra, and more recently gained another option with Zakura.
Here’s how we got here - and why you might want to run one yourself.
A full node independently verifies the blockchain instead of simply trusting another server to tell it what is valid.
When a new block arrives, nodes check it against Zcash’s consensus rules. They also communicate with other nodes, relaying transactions and blocks throughout the peer-to-peer network.
Nodes are also critical to mining, providing the network connection and blockchain data miners need to build and submit new blocks.
zcashd was the original Zcash full node.
Zcash was initially based on Bitcoin’s design, and zcashd originated from Bitcoin Core v0.11.2. From there, the projects diverged substantially as Zcash introduced its own consensus rules and privacy technology.
zcashd followed something of a “one-stop shop” approach. The same software combined the consensus node, peer-to-peer networking, wallet functionality, RPC interfaces, and mining support.
Its codebase was primarily C++, with some Rust components integrated over time. This approach served Zcash for years, but carrying forward a large codebase descended from Bitcoin also came with technical and maintenance costs.
On July 18th 2026, at block height 3,417,100, zcashd reached its planned End-of-Support halt, marking the end of the software that launched the Zcash network in 2016. Currently many options exist that still provide zcashd compatible interfaces for service providers such as ZECD and Zakura.
Zebra is not a rewrite or new version of zcashd.
It is an independent implementation of the Zcash protocol developed from scratch by the Zcash Foundation and written primarily in Rust.
That distinction is important. Two implementations can follow the same Zcash consensus rules without sharing the same underlying architecture or source code. As long as both correctly implement the protocol, they can communicate with each other and agree on the same blockchain.
Zebra also marked a major architectural shift from zcashd. While zcashd followed more of an all-in-one approach, Zebra removed the inherited C++ codebase entirely and separated wallet functionality from the consensus node.
Instead, Zebra focuses on the core responsibilities of a full node, including peer-to-peer networking, consensus validation, chain state, RPCs, and mining infrastructure, using a modular and asynchronous architecture built in Rust.
Rust also provides memory-safety guarantees that help prevent entire classes of memory-management vulnerabilities that can occur in languages such as C and C++.
The result was not simply another way to run Zcash. Zebra provided an independent implementation of the protocol and a modern foundation for Zcash node infrastructure.
In July 2026, Valar Group and Project Tachyon introduced Zakura.
Unlike Zebra, Zakura wasn’t written independently from scratch. It takes Zebra’s open-source codebase as its foundation and builds on it with different engineering and operational priorities.
The history can be summarized pretty simply:
zcashd → the original Bitcoin Core-derived Zcash implementation.
Zebra → an independent Rust implementation developed by the Zcash Foundation.
Zakura → a Zebra-derived implementation developed by Valar Group and Project Tachyon.
One of Zakura’s most interesting goals is reducing the friction involved in getting a node up and running.
Its features include faster initial synchronization, pruning, and snapshot bootstrapping. Faster sync can reduce the wait involved in bringing a node online, while pruning can lower storage requirements for operators who don’t need to retain the entire historical blockchain locally.
Snapshots provide another way to accelerate node setup.
However, using snapshots or pruning can involve trade-offs for operators who need complete historical blockchain data. Services such as indexers or light-wallet infrastructure may have additional requirements, so operators should consider their intended use before choosing how to bootstrap and configure their node.
These features make Zakura particularly interesting for people who want to run Zcash infrastructure but don’t necessarily want the traditional overhead associated with starting a full node from scratch.
Both ultimately serve the same fundamental purpose: independently validating and participating in the Zcash network.
The main difference is where they come from and what they prioritize.
It’s not necessarily a question of one being universally better than the other.
Zebra provides an independently developed and actively maintained implementation from the Zcash Foundation. Zakura builds on Zebra’s foundation while experimenting with ways to make node operation faster and more flexible.
For node operators, that means more choice.
You don’t need to run a node simply to use Zcash. But doing so gives you a more direct and independent relationship with the network.
Running your own node can allow you to:
Verify the blockchain yourself instead of relying entirely on someone else’s infrastructure.
Participate directly in the Zcash peer-to-peer network.
Run infrastructure you control for development, applications, services or experimentation.
Choose between different implementations depending on your needs.
And improvements such as Zakura’s faster synchronization, pruning and snapshots can make getting started more approachable than it has traditionally been.
Zcash’s node infrastructure has come a long way.
zcashd carried the network through its early years. Zebra showed that the Zcash protocol could be independently implemented with a modern Rust architecture. And Zakura is now building on that open-source foundation with a different set of performance and operational goals.
The important idea behind all three is simple: Zcash is the protocol, not one particular piece of software.
Today, operators have more than one way to independently participate in that protocol.
If you’ve only interacted with Zcash through a wallet, running Zebra or Zakura is a way to go one layer deeper, from simply using Zcash to operating a piece of the infrastructure that keeps it running.
And with Zakura focusing on faster synchronization and reducing some of the traditional friction of setting up a node, there’s never been a more interesting time to try running one yourself.
Zcash is built on independent participation, and running your own node is one of the most direct ways to be part of it.
Whether you choose Zebra or Zakura, you’ll be independently verifying the network while contributing to a more distributed and resilient Zcash ecosystem.
Don’t just use the network, be part of it.
Run Zebra or Zakura, verify Zcash independently, and help strengthen the infrastructure behind private money.