ZCG GitHub form fill - Nozy Sync Engine public ($45k)

1. Executive summary and decision snapshot

Leonine DAO requests $45,000 to turn Nozy Sync Engine from a local/operator service into public light-wallet infrastructure. Lowo88 (LaDale), the sole listed developer, would deliver hardening, client compatibility work, a production endpoint, monitoring, and privacy documentation. The application is under review; the proposed schedule runs through April 2027 with startup funding and four milestone payments. [1][4]

Strongest capability evidence: the applicant reports an existing implementation, successful Zeaking synchronization against a live Zebrad node, and shielded-output comparisons with zec.rocks. These are applicant-reported tests, not independently demonstrated outcomes in the supplied evidence. [4]

Decision assessment—inference: the key considerations are incremental value over other lightwalletd implementations, independently testable readiness, sustainable operation by one maintainer, and the payment-total discrepancy detailed below. [1][4]

2. Applicant and team track record

Lowo88 identifies as maintainer of NozyWallet, its Sync Engine, and related CLI/Desktop/API infrastructure. No additional team members are listed. The application claims ecosystem applications, including Gleyo, depend on Nozy/Zebra-class infrastructure for shielded flows. [1]

The applicant reports that completed work includes compact-block ingestion, tip/range queries, treestate, subtree roots, and transaction forwarding. The forum identifies code and a technical write-up, but their contents are not supplied for assessment. [4]

The application also reports participation in the Coinholder-Directed Retroactive Grants Program for wallet-core work, distinguishing that from this forward-looking request. No grounded evidence found establishing the associated award, accepted deliverables, independently verified adoption, or prior grant outcomes. This does not establish that no prior grants exist. [1]

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

Technical approach: a Rust service reads Zebrad or Zakura through JSON-RPC and exposes the CompactTxStreamer interface already used by Zeaking. The applicant proposes changing the wallet’s endpoint rather than its implementation. [4]

Planned delivery sequence:

• Staging: TLS, rate limits, health checks, and operator configuration.
• Client gaps: remaining calls needed by Zeaking and Nozy mobile, supported by synchronization logs; unsupported calls remain explicitly unimplemented.
• Production: a public endpoint, monitoring, and uptime evidence.
• Privacy: zero-indexer integration if tooling permits, otherwise a published deferral gate and accurate shared-infrastructure privacy disclosures. [4]

Funding discrepancy: the stated ask is $45,000, but the forum lists $5,000 startup funding plus milestones of $10,000, $12,000, $13,000, and $10,000. Calculation: those payments total $50,000—$5,000 above the ask. Whether startup funding is included in a milestone or additional remains unresolved. [1][4]

The timetable extends through April 2027. No grounded evidence found in the supplied text for itemized labor/hosting costs, dated milestone acceptance tests, or an explicit mapping between each payment and workstream. The forum says full acceptance criteria are in the application, but the supplied application text does not show them. [1][4]

Replacing Zebrad, custodial wallet hosting, a full transparent explorer, and Android Play/iOS delivery are excluded. Dependencies include node RPC compatibility, target-client requirements, and zero-indexer readiness. [1]

4. Community discussion, arguments, responses, and resolution

Strongest case for the request: the applicant presents a bounded public-service extension of an existing local implementation, rather than funding an entirely new wallet or node. Completed LAN work is explicitly excluded from the request. [1][4]

Strongest challenge: hanh questions how this differs from other lightwalletd implementations and reports that Zebra is experimenting with a built-in lightwallet server. The applicant responds that its implementation is ready and that funding is needed, but supplies no comparative analysis. Differentiation remains unresolved; the reported Zebra experiment is a community statement, not independently substantiated here. [4]

Demand signal: Strahn requests accessible Zebrad JSON-RPC infrastructure because of another provider’s rate limits. Lowo offers to help once funded. Inference: this indicates adjacent infrastructure demand, not a commitment to use the proposed CompactTxStreamer endpoint. [4]

Clarifications, not verified resolutions: the applicant states that keys remain on users’ devices, the service is not hosted wallet custody, and a public sync server is not a mixnet. These clarify intended scope and privacy claims; they do not demonstrate operational privacy protection. No substantive resolution of the duplication concern is documented. [4]

5. Relevant precedents and documented outcomes

• Zaino Completion — $151,240, approved. Relevant because it funded Rust infrastructure, RPC work, and a light-wallet backend. ZCG initially questioned scope overlap and open-ended funding, then unanimously approved, citing delivery and valued collaboration. The record marks the startup payment and first milestone complete, but provides no independently demonstrated adoption or performance outcomes. Inference: its useful precedent is scrutiny of incremental scope and continuing obligations—not proof that another implementation is warranted. [9]
• Zebra State Snapshot & Fast Sync Infrastructure — $30,000, declined. Relevant as another Zebra infrastructure proposal promising easier synchronization. ZCG unanimously rejected it over security trade-offs, centralization, uncertain adoption, and limited benefits relative to alternatives. Inference: the transferable test is whether a measurable user benefit justifies the architecture and risks; the snapshot-specific criticisms should not be attributed to Nozy without evidence. [10]

6. Material risks and execution considerations

• Public-service readiness—inference: reported LAN success does not establish resilience under public load, abuse, outages, or node/client incompatibilities. The proposal itself identifies public hardening and production monitoring as unfinished. [1][4]
• Continuity—inference: development, deployment, monitoring, and reporting sit with one listed maintainer. This concentrates delivery and incident-response responsibility. [1]
• Privacy dependency: zero-indexer may be deferred under the proposed scope. Inference: committee expectations must distinguish delivery of truthful disclosures from delivery of the integration itself. [1][4]
• Operating sustainability: the proposed endpoint creates an ongoing service commitment, while the supplied schedule ends in April 2027. No grounded evidence found for post-grant hosting funding, maintenance duration, or a handover commitment. [4]

7. Material gaps and questions for the applicant

• What is the binding total request, and how does every startup and milestone payment fit within it?
• Which wallets or independent operators will validate deliverables, and what requirements make this preferable to existing or planned alternatives?
• What reproducible evidence supports current synchronization/parity claims, and what compatibility, load, abuse-resistance, and uptime thresholds will govern acceptance?
• What are the dated deliverables and itemized costs for each payment, separating development, hosting, and ongoing operations?
• What precisely triggers zero-indexer deferral, what privacy properties remain without it, and should that branch change payment or scope?
• Who provides backup maintenance and incident response, and how long will the public service remain funded after April 2027?

8. Neutral decision considerations

Evaluation inference: this request is strongest if it demonstrates a distinct user need and converts its reported local functionality into independently accepted public-service milestones. Implementation diversity alone would not resolve the outstanding value question. [1][4]

Committee options include requesting clarification before commitment, considering a bounded staging/validation phase, or structuring payments around independently verified compatibility and service performance. Any funding agreement could separately specify the integration and deferral branches, an operating-support period, and named acceptance reviewers. These are possible evaluation conditions, not an approve-or-reject recommendation.

9. Numbered source list

• [1] ZCG GitHub form fill - Nozy Sync Engine public ($45k) — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/455
• [4] Grant Application — Nozy Sync Engine: public CompactTxStreamer in front of Zebrad — posts 1–5 — https://forum.zcashcommunity.com/t/grant-application-nozy-sync-engine-public-compacttxstreamer-in-front-of-zebrad/57896/1
• [9] Zaino Completion — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/30
• [10] Grant Application – Zebra State Snapshot & Fast Sync Infrastructure — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/187