{Zcash Light Client Privacy Transport Library}

1. Executive summary and decision snapshot

Crackdevs requests $18,500 to develop an open-source Rust “Zcash Light Client Privacy Transport Library” and reference local proxy for current lightwalletd sync traffic. The stated aim is to reduce selected network-metadata leakage through SOCKS5/Tor-compatible routing, fail-closed transport, compact-block request windowing, local caching, request coalescing, and trace reports. It explicitly does not claim full anonymity or cover transaction-submission timing. [1][4][5]

The proposed delivery team is Crackdevs: Ayomide Ojutalayo as project lead and Rust/proxy implementer, Aje Damilola for documentation and QA, and Ifedimeji Omoniyi for milestone coordination and handoff. [1]

Funding is divided into three milestones: $5,000 for transport and fail-closed behavior by August 15, 2026; $7,000 for request shaping, caching, and coalescing by September 5; and $6,500 for the proxy, reports, and documentation by September 26. [7][8]

Decision snapshot: The request is relatively small, technically bounded, and specifies testable artifacts. Its principal value depends on whether the request-shaping approach provides meaningful privacy improvement without unacceptable sync, cache, or integration trade-offs. The central delivery concern is limited independently documented evidence of the team’s prior delivery of comparable security-critical Rust or Zcash infrastructure work. [1][6][8]

2. Applicant and team track record

Crackdevs identifies a prior team project, zcash-cts-gate, described as a Zcash tool shaped by community survey feedback. The application does not provide documented deployment, adoption, security review, completed milestones, or user outcomes for that project. [1]

The team assigns identifiable functional ownership: the project lead is responsible for the Rust library, reference proxy, request-shaping logic, and repository delivery; the documentation/QA role covers tests, examples, and handoff; and the product-management role covers scope, milestones, and reviewer communication. [1]

A prior Crackdevs request for $18,000 concerning Zebra-to-lightwalletd cookie-file authentication is recorded as declined, but the cited meeting rationale says “Too early to vote.” This creates a material uncertainty about the prior proposal’s final disposition and provides no documented delivery outcome from which to assess execution performance. [11]

Inference: The proposed team structure is appropriate for a compact software grant, but evidence supplied does not yet establish a demonstrated track record in privacy engineering, Rust-library maintenance, or upstream Zcash integration.

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

The scope is a reusable Rust crate plus a local reference proxy. V1 targets selected CompactTxStreamer traffic: GetBlockRange requests may be normalized into fixed-size windows; repeated ranges may be served from cache; nearby requests may be coalesced. GetLatestBlock and GetLightdInfo are pass-through with trace recording, while other methods remain pass-through unless documented otherwise. [5][6]

The project proposes SOCKS5/Tor-compatible upstream routing and a fail-closed mode that prevents silent direct-network fallback when privacy transport is required. Direct mode is intended only for development testing. [5][6]

Budget is entirely compensation: 215 estimated hours at an approximately $86 blended hourly rate. The applicant allocates 55 hours to transport and fail-closed functionality, 90 to request shaping/cache/coalescing, and 70 to proxy, reporting, documentation, packaging, and QA. No hardware, software, service, startup, or other funding costs are requested. [6][7]

Dependencies are limited to public lightwalletd protocol documentation, Rust tooling, a local SOCKS5/Tor test setup, and public or local lightwalletd endpoints. The applicant states that no upstream merge, hosted service, vendor approval, or changes to Zebra, Zaino, Zallet, lightwalletd, or official SDK repositories are required. [5]

4. Community discussion, arguments, responses, and resolution

Arguments supporting the request: The proposal is unusually explicit that it reduces only selected metadata leaks, not all network visibility or wallet anonymity. One community participant viewed this scope discipline and clear limitations as a major strength for a security-related project. [4][8]

Arguments against or requiring scrutiny: The proposal’s own risk assessment identifies possible confusion with a generic Tor proxy or with complete-anonymity software. It also acknowledges that lightwalletd can still observe active sessions and that transaction-submission timing is outside V1’s privacy coverage. [6][7]

Applicant clarifications: The applicant distinguishes the work from a generic Tor proxy by emphasizing Zcash-specific compact-block windowing, caching, coalescing, and request reporting. It also states that V1 neither replaces future Z3-related privacy work nor directly integrates Android or iOS SDKs. [5][7]

Resolution status: Scope and privacy-claim concerns are partly addressed by explicit documentation commitments and measurable trace outputs. The unresolved disagreement is practical rather than conceptual: no supplied evidence demonstrates that wallet or SDK developers will adopt the crate, or that its privacy improvements outweigh performance and integration costs in real deployments. [7][8]

5. Relevant precedents and documented outcomes

Crackdevs’ prior Zebra/lightwalletd authentication request: This is the closest precedent because it involved the same applicant and related infrastructure. The committee record describes a narrowly scoped security improvement with CI tests, documentation, and deployment references, requesting $18,000. However, the record is inconsistent: it labels the request declined while also recording “Too early to vote.” No funded outcome or delivered artifact is documented. [11]

Zcash Privacy Capsule: This declined $46,400 request is relevant because committee members emphasized that standalone tooling may lack value without wallet integration or a clear user path. The committee cited lack of wallet support, unclear use case, and concerns about off-chain storage incentives. The present proposal similarly avoids direct wallet/SDK integration, though it is framed as a developer library rather than an end-user product. [14]

Inference: The precedent suggests that independent technical merit may not be sufficient if likely adoption by wallets, SDKs, or maintainers remains unsubstantiated.

6. Material risks and execution considerations

• Privacy-value risk: Fixed windows, cache hits, and fewer exact-range requests can demonstrate altered request patterns, but supplied evidence does not establish how much adversarial inference is reduced under realistic lightwalletd observation. [4][6]
• Adoption risk: The proxy permits local evaluation without modifying wallet code, but production use by wallet or SDK teams would still require later integration work. Direct Android/iOS integration is expressly out of scope. [5][7]
• Security and correctness risk: A transport library that changes range scheduling, cache behavior, and failure behavior needs rigorous testing for boundary ranges, stale or incorrect cached data, overlapping requests, and fail-closed behavior. The proposal includes tests for these categories, but no independent review or audit is proposed. [8]
• Expectation-management risk: Users could mistake Tor-compatible routing and request shaping for comprehensive anonymity. The applicant plans limitations documentation and reports, which is a mitigation but depends on clear implementation and communication. [6][7]

7. Material gaps and questions for the applicant

1. What threat model and evaluation method will establish that windowing, caching, and coalescing reduce meaningful metadata leakage rather than merely change visible request patterns?
2. What are the expected sync-latency, bandwidth, memory, and disk-cost trade-offs for configurable window sizes and cache retention?
3. How will the cache ensure correctness across chain updates, reorgs, endpoint changes, and partially completed syncs?
4. Which wallet, SDK, or lightwalletd developers have reviewed the API or indicated potential integration interest?
5. Will milestone acceptance require an independent technical reviewer with relevant Rust, lightwalletd, and privacy-engineering expertise?
6. Can the applicant provide documented examples of previous Rust, Zcash, security, or open-source maintenance work by the named contributors?

8. Neutral decision considerations

Consider the request’s limited cost and staged acceptance criteria against the lack of independently documented capability evidence and adoption commitment. The milestones can be evaluated through concrete software artifacts, local proxy operation, transport tests, cache/coalescing tests, and trace reports. [6][8]

Potential funding conditions could emphasize: independently reproducible privacy-behavior tests; explicit performance and storage benchmarks; clear cache/reorg correctness tests; fail-closed verification; limitation language that avoids anonymity claims; and a credible maintenance or adoption path following delivery. These are inferences from the proposal’s stated technical and adoption risks. [5][6][7]

No grounded evidence found of completed outcomes, production use, external security review, or committed downstream adoption for this proposed library.

9. Numbered source list

• [1] Grant Application - {Zcash Light Client Privacy Transport Library} — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/348
• [4] Grant Application - {Zcash Light Client Privacy Transport Library} — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/grant-application-zcash-light-client-privacy-transport-library/56592/1
• [5] Grant Application - {Zcash Light Client Privacy Transport Library} — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/grant-application-zcash-light-client-privacy-transport-library/56592/1
• [7] Grant Application - {Zcash Light Client Privacy Transport Library} — posts 1–5, part 4 — https://forum.zcashcommunity.com/t/grant-application-zcash-light-client-privacy-transport-library/56592/1
• [8] Grant Application - {Zcash Light Client Privacy Transport Library} — posts 1–5, part 5 — https://forum.zcashcommunity.com/t/grant-application-zcash-light-client-privacy-transport-library/56592/1
• [6] Grant Application - {Zcash Light Client Privacy Transport Library} — posts 1–5, part 3 — https://forum.zcashcommunity.com/t/grant-application-zcash-light-client-privacy-transport-library/56592/1
• [11] Secure-by-Default Zebra ↔ lightwalletd: Add RPC Cookie-File Authentication Support - decision minutes — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-2-16-26/54737
• [14] Zcash Privacy Capsule (ZPC) — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/304