Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation)

1. Executive summary and decision snapshot

Request: Sujyot Kamble, operating as ZKCG and acting as a solo developer, requests $4,500 for reusable Halo2 verifier-security testing infrastructure, with ZKCG serving as the reference implementation. The request is under review. [1][3]

The proposed outputs combine:

• ZKCG-specific verifier security testing; and
• A generalized, open-source module of Halo2 verifier-security test patterns intended for broader ecosystem reuse, potentially including Zcash-adjacent Halo2 projects. [1][4]

The strongest delivery evidence is the applicant’s stated prior development of a Halo2-based system, Rust crates, and verifier/prover infrastructure. However, these are applicant claims in the proposal; no independent evidence of code quality, adoption, completed prior grants, or security-review outcomes is supplied. [1][4]

Primary decision issue: the grant is small and has concrete proposed technical artifacts, but the evidence does not specify a payment schedule, timeline, milestone-by-milestone budget, acceptance criteria, or a committed Zcash maintainer/adopter. This limits the committee’s ability to assess delivery control and Zcash-specific value. [1][4]

2. Applicant and team track record

Documented applicant information: The applicant identifies as Sujyot Kamble, founder and sole developer of ZKCG. The application states that he designed Halo2 circuits in Rust and published zkcg-verifier, zkcg-common, and zkcg-halo2-prover version 0.2.0. It also claims live proof flows for Centrifuge, Maple Finance, Ondo Finance, and Securitize use cases. [1][4]

Capability relevance: The claimed experience is directionally relevant because the request concerns Rust, Halo2 verifier behavior, proof serialization, testing, and CI integration. [1][4]

Evidence limitation: No grounded evidence is supplied of:

• Prior ZCG awards or delivery performance;
• Independent review of the applicant’s claimed code or deployments;
• Prior fuzzing, formal-security, or vulnerability-disclosure experience; or
• Additional team capacity, peer review, or continuity arrangements.

The solo-developer structure concentrates technical ownership and delivery responsibility in one person. [1]

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

The proposal seeks $4,500 to produce two tiers of deliverables. [1][4]

Tier 1: ZKCG reference implementation

• A cargo-fuzz harness targeting proof deserialization, field-element parsing, and pairing-check inputs;
• At least 50 malformed-proof rejection tests;
• Replay and domain-separation tests;
• Differential verification across Halo2 and RISC0 paths using 100 categorized inputs and an assertion of zero divergence; and
• CI execution of the full suite on pull requests. [4]

Tier 2: reusable ecosystem artifacts

• A standalone halo2-verifier-security-patterns/ module;
• Documented test patterns, malformed-proof vectors, serialization-fuzzing methodology, replay/domain-separation testing, and differential-verification patterns; and
• A THREAT_MODEL.md template covering trust boundaries, assumptions, proof scope, exclusions, and responsible disclosure. [1][4]

Budget and milestone structure: The total request is clearly stated as $4,500. [1][3] No grounded evidence found for a phased payment plan, timeline, allocation of funds across deliverables, or formal milestone acceptance criteria specific to this work.

Dependencies: The work depends primarily on the applicant’s ZKCG codebase and on producing patterns transferable to other Halo2 users. Potential upstream engagement with Zcash-related maintainers is expressly described as a possible bonus outcome, not a commitment. [4]

4. Community discussion, arguments, responses, and resolution

Arguments supporting the request: The proposal makes a substantive case that reusable verifier-security testing patterns could reduce repeated effort among Halo2 projects and improve coverage of malformed proofs, replay protection, serialization handling, and cross-implementation consistency. It proposes artifacts rather than only a security claim or conceptual study. [1][4]

Arguments against or concerns: The most material concern is that the direct initial beneficiary is ZKCG, while broader Zcash adoption is aspirational. The proposal asserts shared relevance because Zcash components and ZKCG use Halo2 tooling, but it supplies no maintainer endorsement, integration plan, or evidence that the selected patterns match a specific Zcash verifier need. [4]

A second concern is evaluability: the source specifies many outputs but not the schedule, payment structure, test-quality thresholds, fuzzing duration or coverage targets, or how generalized artifacts will be validated outside ZKCG. [1][4]

Applicant responses or clarifications: The applicant posted the proposal for community review and identified intended technical outputs. [4][6] No grounded evidence found for substantive answers to technical objections, budget questions, adoption questions, or revised commitments.

Resolution: No material disagreement is documented in the supplied discussion evidence. The central unresolved question remains whether a ZKCG-based testing suite will become a sufficiently reusable and Zcash-relevant public good.

5. Relevant precedents and documented outcomes

Zaino — Stability, Performance & Testing ($50,000; approved): This is the strongest positive precedent because it funded targeted stability, performance, and testing work on a component described as important to post-zcashd light-wallet infrastructure. The committee rationale emphasized specificity, practical engineering value, and readiness for integration by the Zaino team. The record shows approval and a completion status, but no outcome evidence is supplied here beyond those status signals. [7]

Zebra State Snapshot & Fast Sync Infrastructure ($30,000; declined): This is relevant because it illustrates that technically plausible infrastructure can be rejected when security tradeoffs and likely adoption are unfavorable. Committee concerns included centralization, limited likelihood of use in Zebra’s normal node path, and the possibility that the proposed benefit did not justify the network-security risks. [9]

Quantir Privacy-Safe Risk Intelligence ($48,000; declined): This is relevant as a caution against broad ecosystem claims without sufficiently specific, practical Zcash value. The committee characterized the scope as vague, overbroad for the budget, and insufficiently connected to the stated Zcash infrastructure problem. [10]

Inference: This request aligns more closely with the Zaino precedent in being discrete engineering-and-testing work, but it lacks Zaino’s documented integration readiness. It should avoid the adoption and specificity weaknesses highlighted in the declined precedents. [7][9][10]

6. Material risks and execution considerations

• Zcash-specific utility risk: The requested artifacts may be useful for Halo2 projects generally, but no intended Zcash repository, maintainer, or adoption pathway has committed to using them. [4]
• Generalization risk: Tests built around ZKCG’s BN254-based design and its Halo2/RISC0 verification paths may not transfer directly to other Halo2 verifier architectures. This is an inference from the proposal’s stated reference implementation and technical stack. [1][4]
• Validation risk: “Zero divergence” across two verification paths is proposed, but the evidence does not define equivalence boundaries, expected failure classes, corpus provenance, or independent review. [4]
• Delivery risk: A single individual is responsible for development, testing, documentation, CI, and milestone delivery. [1]
• Security-disclosure risk: The proposal mentions responsible disclosure if findings arise, but no disclosure process, coordination contacts, or remediation ownership is specified. [4]

7. Material gaps and questions for the applicant

1. What are the proposed milestones, delivery dates, payment amounts, and objective acceptance criteria for each?
2. Which specific Zcash, Zebra, PSE, or other Halo2 verifier code paths are expected to benefit, and has any relevant maintainer indicated interest in reviewing or adopting the outputs?
3. What parts of the ZKCG fuzz harness and test corpus are expected to be reusable without dependence on ZKCG’s BN254 choices, circuit structure, or RISC0 path?
4. How will fuzzing effectiveness be measured—for example, runtime, corpus growth, code coverage, crash triage, or reproducible regression tests?
5. What exactly constitutes a differential-verification input and “zero divergence,” including treatment of malformed inputs, error categories, and unsupported proof classes?
6. Will the reusable module include runnable example integrations, licensing information, contribution guidance, and CI tests independent of the ZKCG repository?
7. What responsible-disclosure and remediation process will apply if the campaign identifies a vulnerability in shared Halo2-related software?

8. Neutral decision considerations

Committee members may weigh the request as a low-cost, technically concrete attempt to create security-testing public goods, with deliverables that are more testable than a general research proposal. [1][4]

The strongest case for funding would be a revised plan that ties payments to independently checkable artifacts: a runnable harness, reproducible malformed-proof and replay tests, documented results, an extractable reusable module, and evidence of review or adoption interest from a relevant Halo2 maintainer.

The strongest case for caution is not the technical concept itself, but uncertainty over Zcash-specific uptake, independent validation, and whether the generalized module will be meaningfully reusable beyond the applicant’s own system. Those uncertainties could be reduced through explicit milestones and a credible external review or adoption path. [4]

9. Numbered source list

• [1] Grant Application - Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/392
• [3] Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation) — https://docs.google.com/spreadsheets/d/1FQ28rDCyRW0TiNxrm3rgD8ai2KGUsXAjPieQmI1kKKg/edit?gid=1164534734
• [4] Grant Application Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation) — posts 1–5 — https://forum.zcashcommunity.com/t/grant-application-reusable-halo2-verifier-security-testing-infrastructure-zkcg-reference-implementation/57115/1
• [6] Comment on #392: Grant Application - Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/392#issuecomment-5342501448
• [7] zaino - Stability, Performance & Testing — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/328
• [9] Grant Application – Zebra State Snapshot & Fast Sync Infrastructure — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/187
• [10] Quantir Privacy-Safe Risk Intelligence for Zcash Infrastructure — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/288