Hi all,
I’ve submitted a ZCG grant application and I’m posting it here for community
input, as required: Grant Application - PrivateSync: Privacy-Preserving Light Client Sync Infrastructure for Zcash · Issue #549 · ZcashCommunityGrants/zcashcommunitygrants · GitHub
The problem: Zashi/Ywallet sync through lightwalletd servers, and that
sync leaks the user’s IP address and which compact blocks the wallet
downloads — a metadata trail that can deanonymize otherwise shielded
activity. lightwalletd’s own wallet-app threat model documents these
limitations, and ZCG’s open RFP for lightwalletd infrastructure asks for a
multi-operator solution.
The proposal: a three-tier privacy stack for light client sync, aligned
with upstream work already in flight (librustzcash #2665, SDK #1741):
- Tier 1 — Tor onion sync for lightwalletd (ships first)
- Tier 2 — Tor + multi-server PIR, where no single sync node learns which
block you requested (information-theoretic, per-server privacy) - Deployment: 3–5 independently operated testnet nodes + a runbook so more
operators can join — the multi-team model the RFP calls for
Ask: $27,000 over 8 months, paid per milestone, no upfront.
Evidence base (everything is public):
- Application repo (proposal, whitepaper, budget, verified research):
GitHub - sarinsk629-blip/Zcash_privacy-preserving-light-client-sync-proposal · GitHub - Working PoC already in the repo: multi-server PIR + tiered sync demo, 34
passing tests, CI green on Python 3.10–3.12 - The open RFP it responds to:
RFP - Zcash Lightwalletd Infrastructure Development and Maintenance
I’d genuinely value critique before ZCG reviews it — especially on:
- the PIR bandwidth assumptions vs real compact-block sizes,
- the node-operator recruitment plan,
- whether Tier 1 (Tor-only) should just be the default end-state.
Thanks for reading. ![]()
