Hi everyone,
I lead the Zcash India community, where we have organically grown active channels, hosted multiple online sessions and university workshops reaching hundreds of students, run developer bounties and Hindi educational content, collaborated with local developer groups, and received ZecHub support for grassroots education and onboarding efforts.
I am posting this idea and technical roadmap to gather community feedback before building a minimum viable product. My goal is to address one of the longest-standing infrastructure gaps in a way that is practical, decentralized, and aligned with current ZCG priorities.
Current situation
Most user-facing wallets (Zashi, YWallet, and others) rely on light client servers rather than running a full node. The primary software used today is lightwalletd (GitHub - zcash/lightwalletd: Lightwalletd is a backend service that provides a bandwidth-efficient interface to the Zcash blockchain · GitHub, latest release v0.4.19). Zaino (GitHub - zingolabs/zaino: Zaino is an indexer for the Zcash blockchain implemented in Rust. · GitHub, latest release v0.6.0 from 13 July 2026) is the modern Rust-based indexer that implements the CompactTxStreamer gRPC API for compatibility and is designed as a longer-term replacement path.
The existing light client server landscape remains relatively centralized, with limited geographic distribution and operational diversity. This matches the motivation behind the still-open ZCG RFP “Zcash Lightwalletd Infrastructure Development and Maintenance” (posted March 2024, still listed on zcashcommunitygrants.org) and the current wishlist items:
- Ongoing Services: Light client servers / infrastructure
- SDK: Network layer privacy solutions for light client SDKs and libraries
- Core: R&D Decentralized light client syncing
Why Zakura changes the picture
Zakura v1.0.0 was released on 15 July 2026 by Valar Group and Project Tachyon (Introducing Zakura — Zakura, GitHub: GitHub - zakura-core/zakura: Zcash full node, built for scale. · GitHub). It is a consensus-compatible full node forked from Zebra with several practical advantages for light client backends:
- Approximately 5× faster initial block sync than Zebra (measured ~4h 20m vs ~20h 46m)
- Native configurable block pruning
- Snapshot bootstrapping (pruned snapshots ~11 GB, bootstrap times under 2 minutes in reported tests)
- zcashd RPC compatibility mode that reproduces the legacy interface needed by existing tools
These features significantly lower the cost and time required to run high-quality full nodes that can back light client services. The opportunity is to build the light client layer on top of this new performance profile from day one rather than treating it as an afterthought.
Proposed project
A production-grade, multi-operator network of light client servers (supporting both classic lightwalletd and Zaino) that is designed specifically to run on Zakura (pruned mode) as the preferred backend, while remaining compatible with Zebra.
Core design goals:
- Multi-operator and geographically distributed Independent operators in multiple regions (target alignment with the RFP: North America, Europe, Asia, and additional coverage). No single entity controls the majority of capacity.
- Strong privacy defaults
- No logging of user IP addresses or request content
- Tor hidden service support out of the box
- Clear path and documentation for Nym or similar network-layer privacy (aligned with Zaino’s design philosophy and the wishlist item on network layer privacy)
- High reliability and operability
- Automatic health checks and basic failover guidance
- Public status page and metrics (Prometheus-compatible where practical)
- Clear incident response and upgrade procedures
- Easy self-hosting and operator onboarding
- Docker Compose packages
- Simple one-command or documented Kubernetes/Helm options
- Guides suitable for home servers, VPS, and appliance platforms (Start9, Umbrel-style, etc.)
- Zakura-specific optimizations (pruned mode + snapshot bootstrap)
- Wallet developer experience
- Stable public endpoints
- Clear documentation so any wallet can switch or add the network with minimal effort
- Compatibility notes for both lightwalletd CompactTxStreamer clients and Zaino
- Open source and public goods focus All code, deployment manifests, monitoring configs, and documentation will be open source. The project will produce tools that make it easy for additional independent operators to join, rather than creating a new centralized service.
High-level phased roadmap (for discussion)
Phase 0 – Community feedback and design refinement (now – 2–3 weeks)
This post. Collect input on technical choices, scope, priorities, and potential collaborators. Finalize architecture decisions (primary path: lightwalletd on Zakura zcashd-compat vs Zaino on Zakura/Zebra, privacy requirements, monitoring stack, etc.).
Phase 1 – Foundation and MVP (months 1–2)
- Technical design document covering architecture, security, privacy, and Zakura integration
- 2–3 production servers in different regions running Zakura (pruned) + light client software
- Public endpoints live
- Basic public status / uptime page
- Docker-based deployment scripts and initial documentation
- GitHub organization with clear roadmap and contribution guidelines
Phase 2 – Expansion, privacy hardening, and operator tooling (months 3–6)
- Expand to additional regions and onboard first independent operators
- Full Tor support and stricter no-logging defaults
- Improved monitoring, alerting, and basic load-balancing / failover documentation
- Refined self-hosting packages and runbooks
- Performance measurements vs existing public lightwalletd instances
Phase 3 – Ecosystem integration and sustainability (months 7–10/12)
- One-click / appliance-friendly packages
- Comprehensive wallet integration documentation
- Public dashboard of participating nodes and health
- Operator onboarding process and long-term maintenance recommendations
- Final project report and handover materials
This structure is intentionally modest in the early phases so that real working infrastructure appears quickly and can be evaluated by the community and wallet teams.
Alignment with ZCG
This idea sits directly inside the open Lightwalletd Infrastructure RFP goals (multi-region, security, high availability, maintenance, decentralization across providers) and the current wishlist items for light client servers/infrastructure and network-layer privacy. It also benefits from perfect timing with the brand-new Zakura release.
I am not asking for funding in this post. I am seeking feedback so that any future formal grant application is grounded in community input and early technical progress.
Specific questions for feedback
- Does the dual-path approach (support both lightwalletd and Zaino) make sense, or should the project focus on one primary path initially?
- Are there preferred monitoring, status-page, or deployment technologies the community already likes?
- What privacy defaults (logging policy, Tor, future Nym) feel most important?
- Is the phased timeline realistic? Should any deliverables move earlier or later?
- Are there existing operators, wallet teams, or developers who would like to collaborate or review the design?
- Any concerns about scope, centralization risks, or technical approach that I should address before writing more code?
I will incorporate constructive feedback into the design and will keep this thread updated. All work will be public.
Thank you in advance for any comments, criticisms, or suggestions. Looking forward to the discussion.