Idea + Detailed Roadmap: Decentralized Multi-Operator Light Client Infrastructure Optimized for Zakura – Seeking Community Feedback Before MVP

Community Grants RFI - RFP Grants
1

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:

  1. 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.
  2. 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)
  3. 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
  4. 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)
  5. 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
  6. 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

  1. Does the dual-path approach (support both lightwalletd and Zaino) make sense, or should the project focus on one primary path initially?
  2. Are there preferred monitoring, status-page, or deployment technologies the community already likes?
  3. What privacy defaults (logging policy, Tor, future Nym) feel most important?
  4. Is the phased timeline realistic? Should any deliverables move earlier or later?
  5. Are there existing operators, wallet teams, or developers who would like to collaborate or review the design?
  6. 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.

1 Like
Draft Grant Proposal (feedback wanted): Open Light Nodes — Independent Zcash Light Client Infrastructure for Asia
Grant Application - Open Light Nodes: Independent Zcash Light Client Infrastructure for Asia
2

Looking for feedback from people with relevant experience: @artkor @gguy @hanh @zerodartz @decentralistdan @ebfull @zancas and anyone working on light clients, wallets, Zaino, or node infrastructure.

3

From a wallet support perspective, a public status page and clear incident history would be especially useful. It can be difficult to determine whether a user’s syncing or transaction issue originates in the wallet, an individual endpoint, or the underlying network.

Would the MVP status page show endpoint health by region and maintain a public history of outages or degraded service? I’ll also share the proposal with our development team for any technical feedback they may have.

1 Like
4

Thanks @Anzus_GemWallet for the feedback, this is extremely helpful.

Yes, the plan for the MVP status page is to show endpoint health by region and keep a public history of outages or degraded performance. The goal is to make it easy for wallet teams (and users) to quickly see whether an issue is on a specific server, a region, or somewhere else.

I would really appreciate any technical feedback your development team has once they’ve had a chance to look at it. We will soon start working on initial development of MVP, and will share all progress.

Thanks again for taking the time to comment and for sharing it internally.

1 Like
5

how do you see request routing working across multiple operators? Will wallets select endpoints statically, or are you considering some form of decentralized service discovery or health-aware endpoint selection?

6

I shared the proposal with our development team. Since Gem Wallet generally relies on external node providers, their main suggestion is to involve node providers early in the MVP stage. Their operational feedback could help validate deployment requirements, reliability, and whether the proposed setup is practical at production scale.

They also noticed the initial-sync comparison with Zebra. Beyond that, they suggested publishing broader, reproducible benchmarks against the other Zcash node and light-client stacks—such as ongoing resource usage, request latency, throughput, reliability, recovery after interruptions, and operating cost. That would help node providers assess the infrastructure and help wallet teams evaluate potential endpoints.

7

Good question.

In the early MVP the plan is to keep it simple: publish a clear list of independent endpoints (with region and basic health info) so wallets can choose statically or let users pick.

Over time I would like to explore better options such as health-aware selection or lightweight service discovery, but only if wallet teams actually want it and it can stay decentralized. I don’t want to create a new central point of control.

8

Thanks for sharing this with your development team, very useful feedback.

I agree that involving node providers early is important. I’ll reach out to some existing operators and people running infrastructure so we can get practical input on deployment, reliability, and real-world constraints while shaping the MVP.

On benchmarks: yes, publishing clear and reproducible comparisons (resource usage, latency, throughput, reliability, recovery behaviour, and operating cost) against existing setups is something I want to include. That kind of data should help both node providers and wallet teams evaluate things properly.

I’ll keep the thread updated as these pieces progress. Appreciate you taking the time to pass this along.

2 Likes
9

Phase 1 update: moving from idea to something running, with numbers.

I stood up an independent light client node in Asia (Mumbai) and took it end-to-end: a full Zebra archive node serving lightwalletd, behind a real TLS endpoint, verified from an external host (valid Let’s Encrypt cert, GetLightdInfo returning the current tip, client-IP logging disabled). If you’d like to test it:

zebra.openlightnodes.org:443 · Mumbai · lightwalletd v0.4.19 · no-logging

Alongside it I ran a Zakura (pruned) node purely to benchmark the two, since the whole premise was that Zakura changes the cost/speed picture. Both were measured at the same chain tip (3,424,320), same day, same region, and every figure is measured rather than estimated.

Benchmark: Zebra (archive) vs Zakura (pruned)

Zebra (archive) Zakura (pruned)
Instance t3.xlarge t3.large
Node data on disk 259 GB 14 GB (~19× smaller)
Time to a synced node ~11.5 h < 25 min
Restart to serving again 106 s 34 s
Node RAM at tip 2.17 GiB 649 MiB
~Cost / month ~$175 ~$72 (~42%)
Can serve lightwallet clients Yes No (see below)

Honest caveats: this is not a same-hardware comparison (Zebra needs the bigger box), and bootstrap times reflect the snapshots that exist today. The only public Zebra snapshot is ~10 months stale, so most of its 11.5 h was P2P catch-up, not restore. Full method and raw findings are in the repo report.

Key finding: a pruned node can’t back a lightwallet endpoint

Zakura pruned is dramatically cheaper and faster, but the indexer can’t run on it. A lightwallet server serves historical compact blocks so wallets can sync from any birthday height, and pruning discards that history. Verified directly on the node: getblock(3422000) serves, getblock(13) returns “Block not found,” and the same indexer build ran against the archive Zebra node without issue.

So for light-client operators the takeaway is that Zakura’s real win is bootstrapping the archive node fast, not pruning. Pruned nodes are great as a personal validator or a wallet’s own backend, but a public Zashi/YWallet-facing endpoint still needs the full ~259 GB archive.

A note for the indexer maintainers @zancas

The public endpoint runs lightwalletd, not Zaino, because both Zaino builds I tested fail on the current node’s value pools. Nodes now return six pools (…lockbox, ironwood). Zaino 0.1.2 errors while parsing it, and 0.5.0 indexes blocks fine but fails on GetLightdInfo (invalid length 6, expected fewer elements), so it can’t serve wallets against a current node yet. lightwalletd v0.4.19 handled the same node correctly. Happy to share full logs if that’s useful.

Upstream fixes @emersonian

Deploying on the open zcash-stack surfaced a few issues, which I’ve written up and started fixing:

Really appreciate the stack being open; it’s what made this a weekend rather than a month.

What’s next

  • Publishing the full open-source repo (deploy scripts, configs, and the reproducible benchmark harness) so anyone can run their own node or re-run these numbers.
  • A public status page (health/uptime by region). @Anzus_GemWallet, this is the thing you asked about, and it’s next up.
  • Onboarding the first independent community operators across Asia, and a second region. (@Giri-Aayush, on your routing question: for now a simple published list of independent endpoints with health, static selection by wallets. Discovery is something I’d only explore together with the core teams and kept decentralized.)

Feedback very welcome, especially from infra and wallet folks. If any wallet team wants to point a test build at the Mumbai endpoint, I’d love to coordinate. All work is public and I’ll keep this thread updated.

cc for thoughts: @emersonian @zancas @hanh @Anzus_GemWallet

2 Likes
10

Two more Phase 1 pieces are now public.

Open-source infrastructure repo: GitHub - jatinsahijwani/openlightnodes: Independent, community-run Zcash light client infrastructure, starting in Asia. Zebra + lightwalletd, reproducible deploy scripts and benchmarks. · GitHub
Everything used to stand up and measure the Mumbai endpoint is in here: deploy scripts, configs, the full benchmark report, and a guide for running your own independent node. MIT licensed, so anyone can reproduce it, audit it, or spin up their own.

Public status page: Open Light Nodes Status
Live health, uptime, and block-lag by region, with a public history of any outages or degraded service.

@Anzus_GemWallet, this status page is exactly what you suggested: endpoint health by region, plus an outage history so wallet teams can quickly tell whether an issue is a specific server, a region, or something else. Thank you for the idea. It shaped the design, and it is now live.

Feedback very welcome, especially on what else would make this genuinely useful for wallet and node teams. More operators and a second region are next.

1 Like
11

Neat, thanks for benchmarking and thoughts. :student:

1 Like
12

Thank you so much.

1 Like
13

Great to see this live, and thank you for the credit. The regional health, block-lag, and outage-history information is exactly the kind of visibility that can help support teams distinguish wallet issues from infrastructure problems.

1 Like
14

Thank you, this is really encouraging to hear.

Since Gem Wallet works with external node providers, I’d love to make the Mumbai endpoint (and the additional Asian regions we’re bringing up next) easy for you to try. Would your team be open to adding it as a selectable or test/staging provider, even informally at first, so we can validate real wallet traffic together and I can tune reliability to exactly what Gem Wallet needs?

I’m happy to do all the integration legwork: share the exact endpoint details and config, coordinate with your devs, and adapt to any requirements on your side. My goal is to make this genuinely useful to wallet teams, and having Gem Wallet as an early integration and feedback partner would shape it in the right direction.

We’re also starting to formalize this work so it can be sustained and expanded across more independent operators in Asia, and your perspective as a wallet team would be invaluable there. Even a lightweight test on your side would tell us a lot.

1 Like
15

Thanks for the offer. Decisions about testing or adding node providers would need to come from our development and infrastructure teams, so I can’t commit to a staging test or integration from my side.

I’ll pass along the endpoint, repository, and status page for their consideration. If the team is interested or has specific requirements, I’ll follow up here.

Draft Grant Proposal (feedback wanted): Open Light Nodes — Independent Zcash Light Client Infrastructure for Asia
16

Thank you, that makes complete sense, and I really appreciate you passing the endpoint, repo, and status page along to your development and infrastructure teams.

To make their evaluation easy, I am happy to provide whatever they need: full endpoint and connection details, the deployment configs, the benchmark data, and answers to any technical or reliability questions. If they have specific requirements for considering a node provider, such as uptime targets, regions, privacy and logging policies, or incident contacts, just let me know and I will make sure we meet them.

There is no pressure on timing. The endpoints, repo, and status page will stay up and maintained, so they are available to review whenever your team has bandwidth. Thanks again for your engagement throughout, it has directly shaped the project, including the status page you suggested.

1 Like