GraphSense Zcash Shielded Accounting Repair

1. Executive summary and decision snapshot

Steven Hert requests $8,000 for GraphSense Zcash accounting repairs: completing upstream review, reproducible validation, and a historical-correction handoff. He would deliver the work alone; the application is under review. The request funds remaining work, not reimbursement for the existing patch. [1] Payments are proposed at $3,000 / $3,000 / $2,000, with no startup payment, over six weeks from an agreed start. Acceptance requires technical review, reproducible results, and completed regression support—not merely an opened pull request. [6] The strongest capability signal is the applicant’s reported real-node verification and submitted patch with mainnet fixtures and regression tests. Decision inference: the central question is whether funding independently usable validation and an accepted repair provides sufficient value when production correction remains GraphSense’s responsibility. [4]

2. Applicant and team track record

Hert identifies himself as an open-source developer working on Zcash accounting and infrastructure. He reports authoring GraphSense PR #163 and conducting the node verification discussed in issue #126. No additional team members are listed; implementation, testing, review, documentation, and regression fixes all sit with him. These are applicant-reported accomplishments, not independently reproduced results in the supplied evidence. [1] Minutes identify an earlier applicant as @steven_hert for Zcash Reference Flow Kit v1: Android SDK Smoke Paths. The matching name suggests continuity, but the supplied excerpts do not explicitly establish that account’s connection to the current applicant. Its decision relevance is addressed in section 5. [9] For completed prior grant milestones or demonstrated downstream impact attributable to the current applicant: No grounded evidence found.

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

The proposed correction handles signed integer-zatoshi balances across Sapling, Orchard, and Ironwood while preserving GraphSense’s generic shielded input/output representation. Remaining work includes malformed-value handling, RPC compatibility, multi-pool accounting tests, pinned transaction evidence, and resolving transparent previous outputs before asserting fees. The applicant reports that the agreed approach requires no Scala change. [5] Budget: 160 hours at $50/hour, entirely compensation; hardware/software and service costs are zero. The allocation is 60 hours for review and hardening, 60 for validation, and 40 for handoff and support. [5]

• Milestone 1—week 2, $3,000: applicable checks and tests pass, blocking comments are resolved, and a maintainer publicly accepts the patch technically or approves it for merge. [6]
• Milestone 2—week 4, $3,000: a clean-checkout validation command, evidence manifest, and machine-readable comparison report cover specified transaction classes. Expected balances, totals, and fees must match; required mismatches must fail. A maintainer or ZCG-agreed reviewer confirms reproducibility. [6]
• Milestone 3—week 6, $2,000: public, reviewed operator guidance and representative results, plus 14 days of support after validation-package acceptance; no confirmed blocking in-scope regression may remain. Production rebuilding and release timing are excluded. [6] Dependencies include graphsense-lib, its Python test environment, Zebra RPC data, and public transactions. GraphSense controls upstream acceptance, merging, production rebuilding, and a separate storage-schema update needed to persist new balance fields; that update is not funded here. [4][5]

4. Community discussion, arguments, responses, and resolution

Strongest documented support: Strahn Cryptography describes compensation as reasonable and the problem, solution, and maintainer agreement as persuasive. This is a favorable assessment, not an independent technical validation. [6] Documented substantive opposition: No grounded evidence found in the supplied discussion. Applicant clarifications: the proposal explicitly excludes reimbursement for completed work, promises public deliverables usable without the hosted service, and separates applicant deliverables from GraphSense’s production responsibilities. These clarify payment purpose, accessibility, and ownership of rollout tasks; the excerpts do not show them resolving a contested exchange. [4] Counterargument—committee inference, not a community objection: funding can achieve accepted code and validation without achieving corrected production history. The milestone wording makes that boundary clear, but does not settle whether that narrower outcome merits ecosystem funding. No documented consensus on that value judgment is supplied. [6]

5. Relevant precedents and documented outcomes

• Zcash Reference Flow Kit v1: Android SDK Smoke Paths—$12,500, declined July 6, 2026. ZCG wanted clearer alignment with SDK maintainers and stronger evidence of need and actual use. Relevance—inference: this is the closest precedent for evaluating a developer-validation deliverable; documented maintainer demand matters more than a prototype alone. The recorded reasons concern coordination and demand, not a finding of technical failure. [9]
• Ledger shielded support—$300,000, approved December 8, 2025. The minutes emphasize close proposal coordination, ECC technical feedback, and expected user demand; maintenance and support were excluded. Relevance—inference: it illustrates the value of upstream alignment and explicit support boundaries, not a useful price benchmark for this much smaller repair. The supplied evidence documents approval only; for delivered milestones or realized user impact, No grounded evidence found. [10]

6. Material risks and execution considerations

• Schedule and effort: the applicant acknowledges that maintainer availability can delay review and that remediation effort is unknown. He promises to report delays and agree material scope or budget changes with ZCG. Inference: the six-week schedule is a target, not a fully applicant-controlled commitment. [5]
• Downstream analytical effects: the proposal says corrected inputs can change relation estimates, coinjoin classifications, and cluster membership. It excludes new clustering algorithms, identity enrichment, viewing-key processing, and wallet fingerprinting. Inference: this is not merely cosmetic accounting work; the committee should weigh consequences for existing analytics alongside correctness benefits. [6]
• Support horizon: funded regression support lasts 14 days after validation acceptance, while production rollout is outside the milestone. Inference: delayed rollout could reveal defects after funded support expires. [6]

7. Material gaps and questions for the applicant

• Maintainer commitment: who will review and accept the work, and can they confirm review availability and intended use of the correction?
• Production value: what is GraphSense’s expected schedule for the schema update and historical rebuild, and what useful outcome remains if either is deferred?
• Budget justification: what specific unfinished tasks support the 160-hour estimate, distinguishing them from the already-submitted patch and tests?
• Validation credibility: who will independently reproduce the results, how are expected values established, and what confirms representative coverage of uncommon transaction shapes?
• Privacy and analytical effects: can representative before-and-after examples quantify changes to relations and clustering, including potential unintended effects?
• Contingencies: what happens to payment, schedule, and support obligations if upstream acceptance or production deployment is substantially delayed?

8. Neutral decision considerations

Committee options, not a funding recommendation:

• Evaluate deliverable completion separately from ecosystem impact. Define whether accepted code and independently reproducible validation are sufficient funded outcomes.
• If funding proceeds, retain milestone acceptance gates and agree reviewer responsibilities, delay handling, and the support-period trigger before work starts.
• Request targeted maintainer confirmation where it could change confidence in demand, integration, or timing.
• Treat technical readiness, cost justification, and the desirability of improving existing analytics as separate judgments rather than letting any one substitute for the others.

9. Numbered source list

• [1] Grant Application - GraphSense Zcash Shielded Accounting Repair — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/424
• [6] Grant Application - GraphSense Zcash Shielded Accounting Repair — posts 1–5, part 3 — https://forum.zcashcommunity.com/t/grant-application-graphsense-zcash-shielded-accounting-repair/57585/1
• [4] Grant Application - GraphSense Zcash Shielded Accounting Repair — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/grant-application-graphsense-zcash-shielded-accounting-repair/57585/1
• [9] Zcash Reference Flow Kit v1: Android SDK Smoke Paths - decision minutes — https://forum.zcashcommunity.com/t/zcash-community-grants-zcg-meeting-minutes-7-6-2026/56577
• [5] Grant Application - GraphSense Zcash Shielded Accounting Repair — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-graphsense-zcash-shielded-accounting-repair/57585/1
• [10] Zcash Shielded support in Ledger Wallet and Ledger devices — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/152