Zecboat: Wake v1, a custom Halo 2 circuit for note lineage

1. Executive summary and decision snapshot

Request: Zecboat seeks $61,400 for Wake-v1, a custom Halo 2 note-lineage circuit integrated into a Debian desktop Zcash wallet. One developer would deliver the work, with independent circuit review described as ZCG’s engagement. Funding comprises three milestone payments and no startup payment; the application remains under review.[1][5]

Strongest capability signal: The applicant reports an already-shipping mainnet implementation, signed wallet releases, and circuit tests that demonstrate specific attacks by removing individual constraints.[1][4]

Decision focus—inference: The central question is whether this implementation can become independently validated, useful infrastructure at the proposed cost. Review arrangements, enforceable milestone acceptance, single-developer capacity, and demonstrated user demand should carry more weight than the existence of a beta release.[1][4][5]

2. Applicant and team track record

The applicant identifies as Zecboat, sole developer and maintainer of the Rust wallet and zmap-wake, and author of the ZMAP, Wake, and Knotline specifications. Responsibilities also include release signing, review remediation, on-chain collections, tutorials, workshops, hosting, and reporting.[1]

Reported delivery includes:

• Public wallet releases since September 2026; October’s 0.7.1-beta introduces Wake and Knotline.
• Three mainnet collections of ten units each, with wallet support for holding, sending, and checking them, including through a YubiKey-sealed wallet.[1]

These are applicant-reported artifacts, not independent performance findings. For independently validated security, sustained usage, or prior ZCG grant outcomes: No grounded evidence found. This does not establish that no prior grants exist.

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

Scope: Move Wake-v1 from its existing beta implementation through independent review to a wallet permitted to display “verified” lineage.[1][4]

Funding structure:[5]

Compensation is $55,800 for 620 hours at $90/hour; services total $5,600; hardware/software costs are zero. The applicant says each milestone has numbered deliverables and publicly checkable acceptance criteria. For the actual milestone descriptions, deadlines, and service-cost breakdown: No grounded evidence found in the supplied text. Consequently, payment-to-delivery alignment cannot yet be assessed.[5]

Technical approach, as described by the applicant:

• Prove each transfer’s connection to a previously owned note, chaining back to registered genesis outputs.
• Carry receiver-sealed proofs in transaction memos through Knotline, with a manually transferred sealed file as fallback.
• Verify proofs locally under pinned keys; obtain chain information from the recipient’s node or light server.
• Use two circuits derived from Orchard’s Action circuit, without a trusted setup or consensus change.[4]

Dependencies include independent circuit review and chain-data access. The applicant assigns review engagement to ZCG and remediation to the developer; the supplied budget does not establish whether review costs are included.[1][5]

4. Community discussion, arguments, responses, and resolution

Strongest supporting argument: The applicant presents an implementation rather than only a concept, with a defined authenticity problem, constraint-level attack tests, and explicit limits on security claims. Before external review, the wallet uses amber “Lineage checks out” wording rather than “Verified,” and distinguishes own-node checks from provider-supplied answers.[4]

Substantive challenge: George asks how an insurer or underwriter could determine that a presented certificate is the issuer’s original rather than a copy. This directly tests practical usefulness. The applicant’s opening description explains lineage verification, but no subsequent answer or demonstrated insurer workflow appears in the supplied discussion.[4]

Against funding now—inference, not documented community opposition: The mechanism described is not yet evidence that a nontechnical recipient can reliably establish certificate authenticity in practice.[4]

Clarification and resolution: The applicant confirms internally consistent payment totals and asserts checkable milestone criteria. That resolves budget arithmetic, not substantive acceptance readiness.[5] For documented technical rebuttals, applicant responses to the insurer question, or a resolved community disagreement: No grounded evidence found.

5. Relevant precedents and documented outcomes

• ZecBit: NFT infrastructure for Zcash Shielded Assets — $48,000, declined. Relevant because it also proposed asset infrastructure atop an existing implementation. The committee cited incompatibility with the current state of ZSAs, doubtful practical value, and community red flags; a member also reported unrefunded purchases backed by testnet assets. Inference: Wake should establish its distinct mainnet assumptions and user protections. Those criticisms are not evidence against Zecboat itself.[10]
• Reusable Halo2 Verifier Security Testing Infrastructure — $4,500, declined. Relevant to evaluating Wake’s security-testing claims. The committee questioned whether testing an implementation against itself could reveal circuit-logic bugs, identified no clear unmet need, and invited reconsideration if concrete problems were uncovered. Inference: Wake’s constraint-removal tests deserve evaluation, but cannot substitute for independent assessment of whether the circuit proves the intended property.[11]

These are documented decline rationales, not successful-delivery benchmarks.

6. Material risks and execution considerations

• Security scope—inference: Deriving a circuit from Orchard and demonstrating rejected attacks does not by itself establish complete lineage soundness. Review should examine the intended statement, removed constraints, genesis linkage, and end-to-end wallet behavior—not merely proof parsing.[4]
• Capacity—inference: Development, remediation, releases, education, and operations all depend on one person. Review findings or operational demands could displace planned work; no backup maintainer is identified.[1]
• Trust boundary: The design distinguishes local proof verification from node/provider chain answers. Inference: Acceptance testing should verify that wallet wording preserves that distinction under failure and adversarial conditions.[4]
• Long-history usability—inference: Recipients verify every proof in a lineage. Transfer-history growth therefore warrants measured storage, retrieval, and verification benchmarks; none are supplied.[4]

7. Material gaps and questions for the applicant

• What are each milestone’s deliverables, dates, acceptance tests, and intended-user signatories? Which deliverables unlock each payment?
• Who will perform the independent review, what is its scope and price, and is it inside the $61,400? What happens financially if remediation exceeds the planned hours?
• Can you demonstrate the insurer’s original-versus-copy check end to end, including adversarial examples and the precise guarantee the recipient receives?
• Which external users or issuers will test the product, and what measurable adoption or utility outcomes would distinguish success from merely shipping code?
• What are proof-generation time, verification time, memo/transaction costs, and recovery behavior across increasingly long transfer histories?
• What continuity arrangements cover release keys, maintenance, and unfinished milestones if the sole developer becomes unavailable?

8. Neutral decision considerations

Inference: The committee can distinguish prototype capability from review readiness, and review readiness from demonstrated ecosystem value. The reported implementation and test approach support examining the proposal seriously; they do not establish either security or demand.[1][4]

Possible funding conditions—not an approve-or-reject recommendation—include agreed milestone tests before disbursement, an explicitly funded independent-review plan, remediation and retesting requirements before “Verified” labeling, and external-user demonstrations before final acceptance.

9. Numbered source list

• [1] Zecboat: Wake v1, a custom Halo 2 circuit for note lineage — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/487
• [5] Comment on #487: Zecboat: Wake v1, a custom Halo 2 circuit for note lineage — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/487#issuecomment-6170311639
• [4] Zecboat.com Wake-v1, custom Halo 2 circuit for note lineage — posts 1–5 — https://forum.zcashcommunity.com/t/zecboat-com-wake-v1-custom-halo-2-circuit-for-note-lineage/58166/1
• [10] ZecBit: NFT infrastructure for Zcash Shielded Assets — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/409
• [11] Reusable Halo2 Verifier Security Testing Infrastructure (ZKCG Reference Implementation) — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/392