zcashd

Key Facts

• zcashd is a full Zcash consensus node derived from an early Bitcoin Core codebase and also includes wallet functions.
• The official repository says zcashd is deprecated, does not support NU6.3, and automatically halts at block 3,417,100.
• The current reviewed release is v6.20.0, published on June 3, 2026.
• The repository directs node-only operators to Zebra and users of the zcashd wallet to begin testing Zallet.
• A zcashd migration must separate node dependencies from wallet keys, RPC behavior, data directories, and application-specific recovery needs.

Why zcashd cannot be treated like an ordinary upgrade

zcashd historically combined two responsibilities: it validated the Zcash chain and it managed wallet data. Many services only use the node and RPC layer, while some installations also hold addresses, keys, and transaction history. An end-of-support event therefore has different consequences depending on what the daemon does inside a particular system. Replacing the binary without identifying those responsibilities is reckless.

The official version 6.20.0 README says zcashd does not support NU6.3 and documents an automatic halt at block height 3,417,100. The public chain snapshot used by this site is beyond that height. The policy boundary is not a vague recommendation to upgrade eventually, but it also does not diagnose a particular machine. Systems that require ongoing network participation need a supported plan and local verification of their own dependencies.

Node-only operators should evaluate Zebra

The zcashd repository explicitly tells operators who do not need the legacy wallet to migrate to Zebra. Zebra is the Zcash Foundation's actively maintained Rust full-node implementation. The high-level destination is clear, but the migration is not automatically a one-for-one binary swap. Services may depend on specific zcashd RPC methods, authentication behavior, flags, indexes, startup timing, or error responses.

Inventory every caller before the cutover. Compare required RPC coverage, run Zebra alongside the existing node where possible, verify chain tip and responses, update monitoring, and test restart behavior. Data directories and configuration formats should be treated as implementation-specific unless the official documentation says otherwise. A successful sync is only one checkpoint; dependent applications must behave correctly under normal and failure conditions.

Wallet users have a different migration problem

If zcashd holds wallet keys, removing the daemon before proving recovery can turn a software transition into a custody incident. The official warning directs those users toward Zallet testing. Before importing or moving anything, identify the wallet file, address types, encrypted state, passphrase requirements, backups, and any watch-only or viewing-key configuration. Keep an untouched backup of the original data and record the software version needed to read it.

Test the replacement with a small, non-critical account or transaction. Confirm balances, receivers, change behavior, memo access, and the ability to create and broadcast the intended shielded transaction. Never paste seed words or private keys into a website, issue, chat, or support form. A legitimate migration guide can explain a local command or supported import; it does not need remote possession of recovery material.

The automatic halt is a safety mechanism

zcashd releases have long used an automatic deprecation shutdown after a support window. That policy prevents an old node from continuing indefinitely as if it understood later network rules. For this final transition, the repository names the end-of-support height and says NU6.3 follows afterward; the public chain snapshot used here is already beyond the documented height. The boundary can be disruptive, but silently operating incompatible consensus software would be worse.

Operators should alert on both block height and software status rather than a calendar estimate alone. Network timing can move because blocks do not arrive on a perfect schedule. The canonical condition is the documented height and the current upgrade specification. ZIP 258 is the protocol source for the NU6.3 deployment, while the zcashd EOL guide is the operational source for migration.

What remains valuable after end of support

End of support does not erase zcashd's history or make every line of its code useless. It remains an important reference implementation, a record of Zcash's evolution, and the source of behavior that existing systems may still need to understand during migration. The repository remains open, and Zcash Foundation now governs the wider Zcash GitHub organization while multiple organizations and independent contributors can continue collaborating.

The practical rule is simpler: historical value is not operational support. Do not start a new production dependency on a daemon that declares it cannot follow the next network upgrade. Preserve what is needed for recovery and compatibility analysis, then move consensus and wallet responsibilities onto supported paths with explicit tests.

FAQ