Hi everyone,
I just submitted a retroactive grant application for lightwalletd-rs, an independent Rust implementation of the Zcash light-client server, built from scratch between June and August 2026.
Ask: $10,720 USD
FPF issue: Retroactive Grant Application - lightwalletd-rs · Issue #41 · Financial-Privacy-Foundation/ZcashCoinholderGrantsProgram · GitHub
Repository: GitHub - jpgonzalezra/lightwalletd-rs: A Rust lightwalletd for Zcash: a caching proxy that serves compact blockchain data to shielded light wallets over gRPC. · GitHub (MIT)
Release: Release lightwalletd-rs 0.1.0 · jpgonzalezra/lightwalletd-rs · GitHub
I come from the Ethereum world. I’ve been writing software for 13+ years, in crypto since 2018, mostly Rust and Solidity, with merged upstream contributions to revm and Foundry. This is my first Zcash project, built in my free time. Privacy and cryptography pulled me here, and I learn by building real things.
Why this exists
The core stack went Rust years ago with zebrad and librustzcash, yet light wallets still connect through a Go server. I wanted one that fits the Rust ecosystem: one crate, about 19k lines, consensus-critical parsing left to librustzcash, and zebrad touched only over its public JSON-RPC. Small enough for an operator to actually read. Zaino has a much wider scope; I kept this narrow on purpose, because serving infrastructure this critical deserves more than one independent implementation.
What shipped
All 20 CompactTxStreamer methods. Ingestion into a disk cache (redb) with reorg rollback and automatic recovery. TLS on by default, Prometheus metrics, gRPC reflection and gRPC-web, graceful shutdown, and a darkside mode for deterministic wallet tests. NU6.3 (Ironwood) landed on July 7, three weeks ahead of mainnet activation, and matches zebra byte-for-byte on testnet.
The numbers
Benchmarked against the Go reference on live mainnet data, with the harness and full reports committed to the repo. Pacu contributed two PRs as a volunteer (concurrent ingestion plus the benchmark harness, and an optional in-process Zebra backend); no part of the ask covers his work. Range streaming tops out around 330k blocks/s; the Go reference lands between 60k and 140k. At 64 concurrent clients, GetBlock p99 holds near 2.7 ms. The Go server is still faster on a single dense stream and on p50 at moderate concurrency; the reports show both sides.
This is beta software. It has not been audited, and as far as I know the only instance running is mine. What I’m claiming is a complete, tested, benchmarked and publicly verifiable implementation, not an adopted one.
AI coding assistants were part of the workflow the whole way (Claude Opus 5 and Claude Fable 5, via Claude Code); the issue explains how I worked and how each claim can be checked.
Happy to answer questions here during the review period.