Hi all,
Posting here to gather community feedback for ZCG application #307. The grant funds a public, cross-implementation conformance test suite for the Zcash protocol family, covering five core ZIPs (244, 225, 321, 32, 316).
The problem this addresses
Zcash today has no public conformance test suite spanning its core ZIPs. The existing `zcash-test-vectors` repository is a standalone test-vector generator for internal `librustzcash` and `zcashd` consumption, with no Go, JavaScript, or pip-installable Python bindings and no cross-implementation harness for non-Rust wallet stacks.
The consequence is that each wallet, light client, and merchant backend that adopts a ZIP independently re-discovers its specification edge cases. When an implementation gets a corner wrong — a byte-order mistake, an off-by-one in a memo subdigest, a wrong dispatch on the “shielded-only-with-transparent-output” edge case — the only mechanism to surface it today is for the bug to appear on mainnet, with real funds at risk.
What the grant delivers
Three lasting public-good artifacts:
-
A multi-source test vector corpus of at least 5,000 vectors across five ZIPs (at least 1,000 per ZIP), mainnet-sourced where the protocol exposes the data on-chain (ZIP-244 sighash, ZIP-225 wire format) and synthesized as boundary corpora or spec-test fixtures where the protocol design keeps the data off-chain (ZIP-321 Payment URIs ride off-chain QR codes; ZIP-32 HD-derivation private keys never appear on-chain; ZIP-316 Unified Addresses are wallet-side payment strings and do not appear on-chain in canonical form).
-
Cleanroom-validated golden outputs cross-checked between the cleanroom and `librustzcash` for byte equality, with any disagreement triggering a spec-audit note — three cleanroom C++ implementations for the security-critical ZIPs (sighash, wire format, HD derivation) and two cleanroom Rust implementations for the encoding/parsing ZIPs layered on standard cryptographic primitives (URI parsing in ZIP-321; F4Jumble Feistel permutation over BLAKE2b XOFs and receiver-set encoding in ZIP-316).
-
Per-ZIP repository-internal spec-audit notes documenting candidate ambiguities, the empirical convention current implementations agreed on, and a normative recommendation.
Multi-language bindings (Rust native, Go, JavaScript) and a Milestone 1 Python interop demo bridging to `zcash-test-vectors` make the suite consumable across the ecosystem without depending on the Rust ecosystem alone.
How the cross-check works
Every ZIP is cross-checked against at least two genuinely independent code paths: `librustzcash` (the canonical Rust reference) plus a cleanroom implementation written exclusively from spec text. The cleanroom is C++ for the three security-critical ZIPs (244 sighash, 225 wire format, 32 HD derivation) and Rust for the two lower-funds-at-risk ZIPs (321 URI, 316 Unified Address), where URI parsing is text formatting and F4Jumble is a Feistel permutation over standard BLAKE2b XOFs — encoding-tier algorithms layered on existing cryptographic primitives rather than novel cryptography of their own. Each test vector is run through both producers and classified into one of nine agreement states; any state other than full agreement triggers a spec-audit note.
A source-level audit of the cross-implementation landscape confirms that `librustzcash` is the only genuinely independent production implementation for these surfaces: Zebra’s V5 sighash, ZIP-32, and ZIP-316 paths consume `librustzcash` crates rather than re-implementing them, and zcashd consumes the same crates via FFI shims (with an independent C++ outer framing for V5 wire whose Sapling/Orchard bundle bytes are still FFI’d into Rust). The cleanroom is therefore the first genuinely independent C++ peer for ZIP-244 sighash, ZIP-225 bundle internals, and ZIP-32 derivation, and the first non-`librustzcash` Rust peer for ZIP-321 URI parsing and ZIP-316 UA encoding.
Spec audit work runs dual-blind: two engineers independently read each ZIP and produce a candidate ambiguity list before sharing notes. The PoC’s first-pass ZIP-244 audit identified three such candidates (P0/P1/P2); a similar audit ships per ZIP across the other four.
The proof of concept (already public) demonstrates end-to-end viability for ZIP-244. The PoC produced 67 mainnet test vectors and exercised three code paths over them: direct `librustzcash`, `zebra-chain` (structurally a wrapper over `librustzcash` for V5 sighash, so its output equals `librustzcash` by construction), and a cleanroom C++ implementation written from spec text alone. The cleanroom reached byte-equal sighash with `librustzcash` on 52 of 67 vectors; the remaining 15 are edge-case vectors not yet covered by the cleanroom. The PoC also surfaced one real wrapper integration bug — caught and fixed by the conformance harness itself, validating the ROI argument the grant rests on.
Milestones
Six monthly milestones over six months:
-
ZIP-244 production coverage + Python interop demo
-
ZIP-225 V5 wire format round-trip
-
ZIP-321 payment URI cross-implementation
-
ZIP-32 shielded HD wallet derivation
-
ZIP-316 unified addresses
-
Native multi-language packaging (cargo / go get / npm install) + final documentation + v1.0 release
Each milestone ships the vector corpus, cleanroom source, runner integration, and the spec-audit note for that ZIP.
Funding
-
Startup-phase infrastructure (CI scaffolding, vector pipeline bootstrap, runner harness, spec-audit tooling): $3,000
-
Engineering compensation (two engineers × six months × $3,500 per month, equal split): $42,000
-
Total: $45,000
Forward-looking audience
The suite is built for future independent implementers: new hardware wallet firmwares, future non-Rust ecosystem implementations of Zcash ZIPs, and any future ZIP adopter who needs to validate against the spec without inheriting a particular implementation’s assumptions. The three lasting public-good artifacts (corpus, cleanroom-validated golden outputs, spec-audit notes) deliver immediate value; the multi-language bindings deliver future-proofing as the ecosystem diversifies beyond a single canonical Rust implementation.
Full proposal: Grant Application - Cross-Implementation ZIP Conformance Test Suite · Issue #307 · ZcashCommunityGrants/zcashcommunitygrants · GitHub
PoC repository: GitHub - jiehuo100net/zec-zip-conformance: Cross-implementation conformance test suite for the Zcash protocol family · GitHub
Feedback on ZIP coverage, scope, the cleanroom-vs-wrapper distinction, or the per-ZIP vector floor of 1,000 is welcome.
Thanks for reading, and looking forward to whatever the community surfaces.