Hi all,
I’ve submitted a ZCG grant application and wanted to share it here for community feedback, as required before ZCG can discuss and vote on it.
GitHub issue: github PoC repository (in progress): github.com/mahmudsudo/zip229-conformance
Summary
NU6.3 (“Ironwood”) activates on mainnet July 28, replacing the Orchard shielded pool after a soundness flaw was found in its circuit, and introduces a new v6 transaction format (ZIP-229) and a new shielded pool with its own note commitment tree, nullifier set, and chain value pool (ZIP-258). Several independent teams ,Zebra/ZF, Zaino, Zallet, Shielded Labs, Project Tachyon, Valar Group, and Keystone are implementing against this format in parallel under real time pressure. That’s exactly the condition under which independent implementations of a shared spec tend to diverge in small, dangerous ways.
I’m proposing a cleanroom, independently-implemented conformance suite for ZIP-229 parsing and serializing the v6 format from spec text alone, then cross-checking byte-for-byte against librustzcash/zebra-chain output on real testnet (and soon mainnet) transactions. Any disagreement gets documented as a spec-audit note rather than silently resolved.
Why this and not the ZIPs from the earlier declined #307 proposal
A prior ZCG proposal (#307) used this same cross-implementation methodology on five mature, already-well-tested ZIPs (244, 225, 321, 32, 316) and had a strong working PoC , 67 mainnet vectors, byte-equal sighash on 52 of 67 between a cleanroom implementation and librustzcash, and a real bug caught by the harness itself. It was declined specifically because those ZIPs are already stable, not because the methodology doesn’t work. This proposal applies that same validated approach to the opposite situation: a format that’s brand new, security-critical, and activating within days.
A correction I want to be upfront about
The first version of my PoC scaffold was actually built against ZIP-230 , the withdrawn v6 transaction format draft, which has a materially different and more complex format (ZSA issuance bundles, memo bundles, an explicit fee field). I caught this before writing any real parsing logic, fetched the actual current ZIP-229 text directly, and corrected the struct layout to match. It’s a real ZIP-229 (v5 format unchanged, plus a new Ironwood component mirroring Orchard’s encoding) — no memo bundles, no ZSAs, no fee field. Both the mistake and the fix are visible in the repo’s commit history; I’d rather show that process than pretend the first version was right.
Scope
- $19,000 total, 3 milestones over ~3 months
- Standalone crate, no dependency on any wallet team or upstream maintainer approval
- Deliverables: cleanroom v6 header/transparent/Sapling parsing, Ironwood Action bundle parsing, testnet/mainnet vector cross-checks, spec-audit notes, published crate
Background
I’m a systems engineer with 6+ years of production Rust/C++ experience in distributed systems and protocol engineering (former CTO at StreamLivr, published crates including circuit_breaker, rate_rs, daemon_rs, agenticrs). Previous ZCG applications: iCert (not funded) and a FROST Shielded Multi-Sig SDK (not funded , reviewers correctly noted it lacked a named integrating application and skipped the hard coordination/recovery problems). This proposal is scoped narrower and grounded in a live PoC rather than a plan, in response to that feedback.
Feedback welcome, especially from anyone closer to librustzcash/zebra on the Ironwood component or the digest personalization changes.
Thanks, Mahmud (@mahmudsudo)