Hello ZCash Community,
Based on the feedback received from ZCG and upon discussions with members from ZF and ECC, we are revising our proposal’s scope, timeline, and structure for developing an alternative, Independent Full Node Client Implementation of ZCash - Grant Application - [Revised] zec-go: Independent, Alternative Zcash Full Node Client · Issue #191 · ZcashCommunityGrants/zcashcommunitygrants · GitHub
Revision
- Scaled Efforts:
The effort is now framed realistically as a 24–36 month project and a team of 5 FT engineers with prior experience developing production-grade node clients. - Phased execution
The work is divided into clear phases and milestones with defined boundaries and outcomes. Each phase can be evaluated independently. - Reduced initial scope:
This proposal requests funding for Phase 1 only. Later phases would require separate review and approval. - Clear ecosystem boundaries
The project does not propose ZF or ECC engineering capacity for protocol changes, alternative consensus rules, or reliance on testing.
Why do we need another node client?
Before diving into the technicals, we highly recommend reading our thesis on why node diversity should be a top-priority for ZCash Network right now:
Proposal
We are developing zec-go, an Alternative, Independent Full Node Client implementation of ZCash. We are proposing Phase 1: Consensus & Node Operations (Testnet Release), delivering a fully validating Zcash node that operates on Testnet and focuses on correctness, operability, and conformance.
Our proposal covers a 7-milestone plan to deliver a production-ready node capable of:
- Peer-to-peer networking and message handling
- Block and transaction validation
- State management (UTXO set and shielded pools)
- Mempool and transaction relay
- RPC interfaces for node operation
- Ziggurat-based conformance testing
- Extended Testnet operation
Deliverable: A stable, fully validating Testnet node that can participate in the network without introducing mainnet risk.
Only Phase 1 is included in the current funding request. Phase 2 includes development of an alternative, specification-compliant cryptographic implementations where appropriate. Until such work is explicitly reviewed, cryptographic correctness remains de-risked through continued use of librustzcash. Phase 3 of Audit and Mainnet Release is focused on operational review amd security audits to prepare for mainnet release.
Full Technical Proposal Spec:
Why Go? Our choice of Go is a security decision. True resilience requires Toolchain Diversity. By using a different stack (Go compiler/runtime vs. Rust/LLVM), we protect the network from:
- Compiler/LLVM Bugs: A zero-day in a specific compiler version won’t take down the entire network.
- Runtime Deadlocks: Different memory management and concurrency models (Goroutines vs. Tokio) provide a safety net against language-level exploits.
- The Language of the Cloud: Go is the industry standard for infrastructure. A Go-client makes Zcash 10x easier for enterprises, exchanges and custodians to extend, integrate, monitor, and scale using the tools they already use (Kubernetes, Docker, Prometheus).
We’re open to suggestions from the ecosystem if any other language make more sense.
The Ask
Our goal is to deliver a functional Testnet-ready node client that can participate in the network, synchronize blocks, and provide a modern API for developers.
ZCash is at a crossroad where node-diversity should be a top-priority. We can continue to bet on a single-team-single-client model, or we can build a resilient, multi-client ecosystem that makes the protocol unkillable.
We look forward to your feedback and are happy to answer any technical questions below.
About Us
We are Chainscore Labs, a web3 engineering firm specialized in blockchain infrastructure. More details in proposal spec > attached.