Zcash Nodes

Key Facts

• The official zcashd support guide sets an automatic end-of-support halt at block 3,417,100 and says zcashd will not support NU6.3.
• The Node Transition Console compares that policy height with a dated ZcashInfo primary-chain snapshot; it cannot observe a local daemon, wallet, RPC service, or migration result.
• Zebra is the Zcash Foundation's Rust full-node implementation. It validates and relays Zcash chain data, but it is not a wallet and does not hold spending authority.
• The Zebra Book lists a 300 GB disk baseline, 8233 TCP as the mainnet peer-to-peer port, and optional health endpoints when an operator configures them.
• The zcashd project directs node-only operators toward Zebra, while legacy wallet users are directed to test Zallet, whose documentation currently labels it alpha software.

The halt height is an operational boundary, not a migration result

A documented software halt is easy to misunderstand. It does not mean every machine made a clean transition, nor does it prove that a wallet file can be opened elsewhere. It says that a particular legacy implementation has a policy boundary at a particular chain height. The official zcashd support material names block 3,417,100, says the daemon will not support NU6.3, and separates node-only operators from users who also depend on the old wallet.

The Zcash Node Transition Console compares that policy height with the primary-chain snapshot captured for this build. Its observed height is a network fact with a source timestamp. The comparison is deliberately narrow: when the observed chain is beyond the policy height, the page can say that the public policy boundary has passed. It cannot say whether your zcashd process stopped, whether it was configured differently, or whether a downstream application still depends on its RPC behavior.

That distinction matters because migration is not a trophy. An exchange, explorer, payment service, research stack, or personal machine may each use the old daemon differently. The useful question is not simply whether a replacement binary has been downloaded. It is which responsibility the legacy process carried, which caller depended on it, and what evidence would demonstrate that the replacement has taken over that responsibility without exposing recovery material.

Start with the role, not a replacement binary

A node-only deployment has one class of problem: consensus validation, peer connectivity, synchronized chain state, operational interfaces, monitoring, and every application that calls them. A zcashd instance that also manages wallet data has another: keys, encrypted wallet files, address types, transaction history, passphrases, backups, recovery procedures, and the behavior of the software that builds transactions. Treating those roles as one migration is how an infrastructure change becomes a custody incident.

For a node-only service, inventory the calls before choosing a cutover. List RPC methods, authentication, startup flags, index assumptions, health checks, log collection, alerting, reverse proxies, and restart behavior. A full node reaching the chain tip is useful evidence, but it is not evidence that a dependent application handles the new process correctly. Run parallel checks where the architecture permits, compare the exact responses the caller needs, and give the failure path as much attention as the happy path.

For a wallet-bearing service, freeze the impulse to copy files around first. Establish where recovery material lives, whether it is encrypted, what version created it, and how recovery can be tested locally without supplying it to a website or support contact. A legitimate guide can point to local official documentation. It never needs a seed phrase, private key, wallet database, RPC credential, address list, or public node endpoint from you.

Zebra is a full node, not a wallet or privacy switch

Zebra, whose daemon is named zebrad, is a Zcash full-node implementation written in Rust. Its job is to validate Zcash chain data, participate in the peer-to-peer network, relay valid data, and expose selected operational interfaces. That gives an operator an independently validated view of the chain rather than a blind dependency on a remote indexer. It does not construct a user's shielded transaction, store spending authority, or turn transparent chain activity into encrypted activity.

The current Zebra requirements document lists 300 GB of available disk as the baseline and describes 4 CPU cores with 16 GB RAM as recommended, with a smaller minimum configuration for constrained environments. Those figures are planning inputs, not a promise that every workload fits. Chain state grows, local indexes and monitoring add overhead, and the machine's actual limits depend on the software around the node. Capacity, patching, restart behavior, and disk alerts belong in the operator's runbook from the beginning.

For mainnet peer traffic, the Zebra documentation lists TCP port 8233; the testnet peer port is different. Peer reachability can help the network, but it is not the same as exposing administrative interfaces. Treat RPC, metrics, reverse proxies, container ports, firewall rules, logs, and host access as separate attack surfaces. A full node strengthens consensus verification. It does not erase an operator's IP address, hosting records, peer connections, client metadata, or the ordinary risks of an exposed service.

Health and readiness are different checks

A process can be alive while it is still catching up, stalled, misconfigured, or unable to serve the work a dependent service expects. Zebra documents optional health endpoints including a liveness-oriented endpoint and a readiness endpoint for a node near the tip. The distinction is useful for load balancers and orchestrators because it avoids treating a running process as automatically ready to answer a time-sensitive chain request.

Those endpoints are not a substitute for an operator's own checks. Monitor the chain tip against an independent source, peer connectivity, disk growth, CPU and memory pressure, restarts, error rates, certificate and credential expiry where relevant, and the exact queries applications make. Health tooling needs access control too. A convenient endpoint can become an information leak or an attack surface when it is published without a threat model.

The right success condition is specific to the role. A home operator may care about an honest, synced full node. A public service may need bounded response time, a recovery plan, observability, and staged upgrades. An exchange or application backend may also need compatibility verification for every integration point. No public dashboard can infer those local conditions. It can only help keep the protocol policy, documented interfaces, and source links in view.

The legacy wallet path needs its own evidence

The official zcashd transition guidance tells legacy wallet users to test Zallet. Zallet's own documentation currently describes it as alpha software under active development and warns that breaking changes may occur. That is not an invitation to dismiss it. It is a boundary that changes the standard of care: test with a non-critical recovery path first, use current official instructions, and avoid declaring a migration complete because an interface happens to open once.

A wallet transition has several separate proofs: recovery data can be read by the intended local software; the expected addresses and balances can be reconciled; the relevant receiver and transaction behavior work; a small test can be created and confirmed; and the old backup stays available until the replacement recovery path has been independently tested. Each proof belongs to the operator or wallet holder. They should be made without publishing secrets to a web form, chat, ticket, or unauthenticated helper.

This is also where third-party convenience can be dangerous. Browser pages, screenshots, and social posts can explain terminology, but the exact import or recovery workflow needs to come from the official project documentation and match the specific software version. A page that claims it can certify a migration without seeing the local environment is selling false certainty. This guide refuses that role.

Method and review contract

The Node Transition Console reads only the build-time source snapshot and official public documentation. It compares the captured primary chain height with the documented zcashd halt height, records a reviewed Zebra release signal, and preserves the current ZIP 258 draft activation height as a separate protocol record. Switching a lens changes the explanation, not the underlying public evidence. The full evidence matrix remains in the rendered document for readers and crawlers.

The browser does not call a node, RPC interface, wallet service, block explorer, or secret-bearing endpoint. It does not ask for an address, seed phrase, key, wallet file, password, or node URL. That restriction makes the tool useful as a source map rather than pretending to be a remote operations agent. For installation, migration commands, and compatibility details, follow the official zcashd, Zebra, Zallet, and ZIP documentation linked below.

This guide has a 30-day review window. A revised halt policy, Zebra operational requirement, Zallet release state, ZIP 258 revision, or material documentation change requires a new editorial check. Until then, it is a dated guide to public records and operational questions, not an assurance that a particular machine, application, or wallet is safe to change.

FAQ