Independent Recomputation of the Zcash Supply Ledger, including the NU7 NSM Reserve

1. Executive summary and decision snapshot

Request: $50,000 for an independent, reproducible accounting of Zcash’s value pools and NU7 NSM reserve. Independent Developer’s two-person team—robust/robustfengbin and aic-larry—proposes approximately five months of work, funded through $3,000 startup support and milestone payments of $17,000, $15,000 and $15,000. The application is under review. [1][4]

Strongest capability evidence: prior Zcash security-tooling work, including applicant-reported upstream integration of Zebra fuzzing infrastructure. Principal evaluation issues: whether the accounting provides sufficient additional assurance, whether the effort estimate is justified, and whether changing specifications, activation timing and upstream participation permit delivery as proposed. [4][5]

Inference: This is best evaluated as independent accounting and verification infrastructure—not a comprehensive audit of shielded supply integrity. The applicant explicitly excludes detection of counterfeit shielded funds. [4]

2. Applicant and team track record

The application describes robust as a senior engineer with 15+ years’ experience in Rust, distributed systems and blockchain, responsible for accounting rules, acceptance, coordination and disclosure. Aic-larry would own block ingestion, deterministic outputs, node operations and continuous verification. These are applicant-provided qualifications. [1]

The team claims delivery of both Zebra coverage-guided fuzzing and batch-versus-single verification equivalence tooling; it says the latter was delivered in the submission week. No grounded evidence found for independent acceptance or measured security outcomes of that recent delivery. The earlier fuzzing project offers stronger completion evidence, discussed in section 5. [1][4][12]

3. Proposal scope, milestones, budget, technical approach, and dependencies

The applicant estimates approximately 28 person-weeks across 22 calendar weeks. Compensation totals $47,000, hardware $3,000 and services $0; the applicant states milestone payments follow delivery. [4][5][7]

Approach: independently implement accounting rules from the ZIPs, reconstruct the transparent pool from an independent unspent-output set, and use integer arithmetic and fixed output ordering. Transaction parsing remains shared through zcash_primitives; the accounting code would not be shared with either node implementation. [4][5]

Dependencies: ZIP 237 remains under review according to the applicant; reserve exposure by implementations is changing; Mainnet activation determines the live-verification window. The vector deliverable can shift to checking implementations against ZIP-author vectors if those appear first. These are proposal-reported conditions, not independently established protocol status. [5]

4. Community discussion, arguments, responses, and resolution

• Strongest argument for: the applicant proposes a separately written accounting model rather than another presentation of node-computed balances, with reserve vectors and reproducible historical outputs. This offers a concrete verification objective. [4]
• Strongest objections: a commenter questioned why existing teams or node operators could not perform the work, whether $50,000 was proportionate, and whether dedicated infrastructure was necessary. The claim that established libraries and AI make the work trivial was not supported by a demonstrated equivalent implementation. [4][5]
• Applicant response: independence concerns the accounting, not parsing; most work lies in historical issuance boundaries, reserve rules and diagnosing divergences. The applicant supplied a person-week breakdown and explained infrastructure as supporting five months of Mainnet/Testnet comparisons. [4][5]

Assessment: the responses clarify scope, effort assumptions and infrastructure purpose. They do not establish that the estimate is competitive or independently validate the workload. A technical rebuttal addresses the “just sum balances” characterization; the funding-value disagreement remains unresolved. [4][5]

5. Relevant precedents and documented outcomes

Zebra Coverage-Guided Fuzzing Infrastructure — $30,000, approved. This is the closest capability precedent: the current team claims responsibility for harnesses merged upstream and Zebra’s enrollment in OSS-Fuzz. The grant is marked complete, with all three milestones complete. These distinguish recorded completion from the applicant-reported integration outcome; neither establishes measured security impact. Inference: relevant evidence of ability to deliver upstream-facing testing infrastructure, but not direct proof of supply-accounting expertise. [4][12]

Zebra Mempool Adversarial Resilience Suite — declined. This is relevant as a technical-tooling evaluation precedent, not established history of the current team. Committee members cited unclear expertise, vague scope and insufficient involvement of expert development teams to ensure adoption. Inference: its lesson is to establish credible reviewers and intended users before relying on future integration as a major benefit. [9]

6. Material risks and execution considerations

• Correlated errors: shared parsing and specifications limit independence. Inference: matching outputs demonstrate reproducibility, not necessarily correct accounting; boundary-case review and independent expected values remain important. [4][5]
• Schedule exposure: M1 targets weeks 1–6 but includes live activation work. Inference: activation or specification changes could delay payment eligibility even if substantial engineering is finished. Divergence investigations add uncertain effort. [5]
• Durability: Zebra integration is proposed, not committed; the applicant says the tool remains standalone if maintainers decline it. Inference: long-term value depends partly on who continues running and maintaining it after funded verification ends. [4]
• Communication of assurance: counterfeit shielded funds are explicitly out of scope. Inference: reports should distinguish accounting consistency from broader claims about the absence of inflation. [4]

7. Material gaps and questions for the applicant

No grounded evidence found for named upstream acceptance commitments, an agreed activation-delay arrangement, or post-grant maintenance ownership. The applicant confirms acceptance criteria exist, but their full wording is not supplied. [4][5][7]

Priority questions:

• Acceptance: Who will sign off each milestone, and what exact tests constitute acceptance—including treatment of unresolved divergences?
• Timing: If NU7 activation or final ZIP changes fall outside the planned window, which deliverables and payments move, and what remains payable?
• Independent correctness: Who will review accounting rules and expected values independently of both the applicant and node outputs?
• Value for money: What compensation rates, task assumptions and narrower-scope alternatives support the 28-person-week estimate?
• Adoption and maintenance: What feedback have ZIP authors and Zebra/Zakura maintainers provided, and who funds maintenance if upstream integration does not happen?
• Prior performance: Can intended users confirm acceptance and upstream use of the recently claimed batch-versus-single delivery?

These questions target the proposal’s acceptance, effort, external dependencies and claimed capability. [1][4][5][7]

8. Neutral decision considerations

Inference: The committee can distinguish three potential benefits: reserve test vectors, an independent historical ledger, and sustained verification. Each should have separately testable acceptance conditions so that external adoption is not confused with delivery. [4][5]

Possible funding conditions include named technical reviewers, agreed specification baselines, an activation-delay clause, reproducible acceptance tests and a bounded maintenance commitment. These address identified uncertainties without presuming approval or rejection.

The central trade-off is credible additional verification versus an effort estimate and long-term adoption case that remain applicant-supported rather than independently validated. Milestone-based payment reduces upfront exposure but does not itself establish technical correctness or value. [4][5][7]

9. Numbered source list

• [1] Grant Application - Independent Recomputation of the Zcash Supply Ledger, including the NU7 NSM Reserve — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/444
• [4] Grant Application - Independent Recomputation of the Zcash Supply Ledger, including the NU7 NSM Reserve — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/grant-application-independent-recomputation-of-the-zcash-supply-ledger-including-the-nu7-nsm-reserve/57799/1
• [5] Grant Application - Independent Recomputation of the Zcash Supply Ledger, including the NU7 NSM Reserve — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-independent-recomputation-of-the-zcash-supply-ledger-including-the-nu7-nsm-reserve/57799/4
• [12] Zebra Coverage-Guided Fuzzing Infrastructure — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/234
• [7] Comment on #444: Grant Application - Independent Recomputation of the Zcash Supply Ledger, including the NU7 NSM Reserve — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/444#issuecomment-5825776357
• [9] Zebra Mempool Adversarial Resilience Suite - decision minutes — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-8-3-2026/56909