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

Community Grants
1

Open Light Nodes: Independent Zcash Light Client Infrastructure for Asia

This is a draft shared for community feedback ahead of a formal ZCG submission. It follows the official ZCG grant application format so the community can review the real thing. Feedback and criticism are very welcome. Full background and progress are in our forum thread: Idea + Detailed Roadmap: Decentralized Multi-Operator Light Client Infrastructure Optimized for Zakura – Seeking Community Feedback Before MVP

Application Owners

@jatinsahijwani, @AnirudhSingh07

Organization Name

Open Light Nodes (an initiative led by members of the Zcash India community)

How did you learn about Zcash Community Grants

Through the Zcash community and ZecHub, and by following ZCG’s published RFPs and wishlist on the forum and zcashcommunitygrants.org.

Requested Grant Amount (USD)

$40,000

Category

Infrastructure

Project Lead

Name: Jatin Sahijwani
Role: Project lead and lead operator (engineering and operations)
Background: Lead of the Zcash India community, which has organically grown active channels, run university workshops reaching hundreds of students, run developer bounties and Hindi educational content, and received ZecHub support for grassroots education and onboarding. Over one week, and before requesting any funding, I independently designed, deployed, benchmarked, and open sourced a production Zcash light client node (details below).
Responsibilities: Architecture, deployment, day to day operations, security and upgrades, benchmarking, incident response, and upstream contributions.

Additional Team Members

  • Name: Anirudh Singh Chouhan
    Role: Co-lead and partner
    Background: Active organiser within the Zcash India community, focused on community programs, ecosystem strategy, and partnerships.
    Responsibilities: Integrating this work into Zcash India community initiatives and planning, driving wallet adoption and coordination with wallet teams, and supporting the public monitoring and status reporting so the health of the network is transparent to everyone.

Project Summary

An independent, community run network of Zcash light client servers, starting in Asia, built on the modern Zebra plus lightwalletd and Zaino stack, fully open source and reproducible, complementing existing operators such as zec.rocks rather than competing with them.

Project Description

Most Zcash wallets (Zashi, YWallet, and others) reach the chain through light client servers. That layer remains concentrated on a small number of operators and providers, with little independent presence in Asia. Open Light Nodes addresses this by running independent, geographically distributed light client endpoints, making the entire deployment reproducible and open, and inviting a community of independent operators to join so the network becomes decentralized in practice rather than another single service.

Phase 1 is already live and was self funded, as proof of execution. We shared the idea on the forum first and gathered community feedback before building, then delivered:

Community feedback on the thread has been positive and shaped the work directly. Gem Wallet asked for a public status page with regional health and outage history, which we built and they confirmed is exactly what support teams need. This grant turns that proven Phase 1 into a maintained, multi region network with reproducible benchmarking and strong wallet integration support.

Proposed Problem

Zcash light client infrastructure is concentrated: a small number of public servers, limited geographic diversity, and little independent operation in Asia. This is a resilience, privacy, and censorship resistance weakness. It is an explicit ZCG wishlist item (“Ongoing Services: Light client servers / infrastructure”) and the subject of the still open Lightwalletd Infrastructure RFP. Wallet and support teams also lack reproducible data and public health visibility to evaluate and depend on endpoints.

Proposed Solution

Run and maintain independent, open, reproducible light client endpoints across three Asian regions, publish public health monitoring and reproducible cross stack benchmarks, and provide strong wallet integration support so the endpoints get used. Alongside this, and as a Zcash India community initiative, we will make it easy for community members to run their own independent nodes and join the network. Everything is coordinated with core teams and existing operators, including upstream contributions.

Solution Format

Running production infrastructure, plus open source software and documentation (deploy scripts, configs, monitoring, onboarding guides), a public status page, and published reproducible benchmark reports. All code MIT licensed with a CONTRIBUTING.md following Zcash development standards.

Dependencies

  • Upstream software: Zebra (Zcash Foundation), lightwalletd, Zaino (Zingo Labs), and zcash-stack (zec.rocks).
  • Snapshot sources for fast bootstrap.
  • Independent hosting providers across Asian regions.
  • Coordination with wallet teams (Gem Wallet has engaged and validated the status page on the forum thread), the Zaino team regarding the value pool finding, and zec.rocks regarding the upstream fix.

Technical Approach

Archive Zebra full nodes back lightwalletd, and Zaino once it supports current node value pools, on independent hosts in each region. Each endpoint is fronted by Caddy on port 443 with automatic Let’s Encrypt TLS and access logging disabled, with gRPC bound to localhost. Deployment is Docker based and reproducible from the public repo. A separately hosted monitoring instance checks each endpoint’s real serving and block lag health and reports health, uptime, and outages by region on a public status page. A reproducible benchmark harness measures resource use, sync and bootstrap time, latency, recovery, and cost across stacks. Provider and region diversity is a deliberate design goal, with no central point of control.

Upstream Merge Opportunities

This project builds on and contributes back to existing Zcash software:

  • zecrocks/zcash-stack: submitted a fix for a broken Caddy compose overlay so the stack starts, at fix(docker): make compose.caddy.yaml parseable and functional by jatinsahijwani · Pull Request #29 · zecrocks/zcash-stack · GitHub. Additional documented issues include the zfnd/zebra image silently ignoring a mounted zebrad.toml unless CONFIG_FILE_PATH is set, and the pinned Zaino version.
  • Zaino (Zingo Labs): documented that current builds fail on the node’s new six value pool response (ironwood, lockbox). We will coordinate with the Zaino team, provide real world testing, and migrate the endpoints to Zaino once resolved.
  • Deployment tooling and operator documentation produced here will be offered upstream where useful. No forced forks are planned.

Budget

Hardware/Software Costs (USD)

$2,000

Hardware/Software Justification

Domains, appliance and self hosting test devices (Start9 and Umbrel style) to validate onboarding on real home server hardware, and miscellaneous tooling. TLS is free via Let’s Encrypt. All software used is open source.

Service Costs (USD)

$14,000

Service Costs Justification

This covers, over twelve months: independent hosting for three regions plus a separate monitoring and status host, with light redundancy, on independent Asian providers rather than a single major cloud (approximately $5,000); a Zcash India community operator initiative, including onboarding materials, a workshop, and optional seed hosting or small setup incentives for community members who choose to run their own nodes (approximately $4,000, spent only if operators come online); wallet integration and adoption support, including integration documentation, reference configs, coordination, and small test integration support for wallet teams (approximately $3,000); and a contingency for bandwidth, DDoS protection, or hardware needs (approximately $2,000).

Compensation Costs (USD)

$24,000

Compensation Costs Justification

Twelve months of work for two people, at a modest below market rate. Jatin Sahijwani leads engineering and operations: deployment and maintenance across regions, security upgrades, incident response, benchmarking, and upstream contributions. Anirudh Singh Chouhan leads community integration, wallet adoption and coordination, and public monitoring and status reporting.

Total Budget (USD)

$40,000

Previous Funding

No

Previous Funding Details

No prior ZCG grant. The Zcash India community has received ZecHub support for grassroots education and onboarding. Phase 1 of this project was self funded.

Other Funding Sources

No

Other Funding Sources Details

Not applicable. Phase 1 was bootstrapped independently.

Risk Assessment

Implementation Risks

  • Zaino does not yet serve wallets against a current node because it fails on the new value pools. Mitigation: run lightwalletd v0.4.19 today, track the upstream fix, and migrate when ready.
  • Wallet adoption is the main risk for any infrastructure. Mitigation: involve wallet teams early. Gem Wallet has engaged on the thread and provided feedback on the status page, and has kindly offered to pass the endpoint, repository, and status page to their development and infrastructure teams. Endpoint testing is unconfirmed and would be their teams’ decision.
  • Hosting or bandwidth costs could spike. Mitigation: independent providers, monitoring, origin protection, and a contingency line. Base hosting is predictable and low.
  • Community operator uptake is uncertain. Mitigation: this is treated as an initiative, not a committed deliverable, so no funded milestone depends on volunteer participation.

Potential Side Effects

  • Perceived overlap with existing operators such as zec.rocks. Mitigation: the project is explicitly complementary, coordinated, and contributing upstream. The goal is provider, operator, and region diversity, not duplication.
  • Low usage if wallets do not add the endpoints. Mitigation: dedicated integration support and early wallet involvement.

Success Metrics

  • Three live, independent regional endpoints with public uptime and block lag on the status page.
  • High availability as the goal, targeting roughly 99 percent uptime per endpoint as redundancy and monitoring mature.
  • Reproducible benchmark reports published, with at least one independent reproduction.
  • At least one wallet team testing the endpoints, with production use as the goal.
  • Upstream contributions accepted.
  • Aspirational, not a committed deliverable: a growing number of independent community operators over time.

Project Schedule

Startup Funding (USD)

$8,000

Startup Funding Justification

Covers Milestone 1: hardening and consolidating the already live Mumbai endpoint, the open source repo, the status page, and the reproducible benchmark, plus a technical design document, and the first period of operations. Because much of Milestone 1 is already delivered and self funded, this first tranche mostly pays for work that is already live and proven, so the committee can see real results before committing further funds.

Milestone Details

  • Milestone: 1, Foundation and consolidation
    Amount (USD): 8,000
    Expected Completion Date: about 3 weeks after approval
    User Stories:

    • “As a wallet developer, I want a reliable, documented light client endpoint with public health visibility, so that I can evaluate and depend on it.”
    • “As a prospective node operator, I want a fully reproducible open source deployment, so that I can stand up my own node.”
      Deliverables:
    • Production hardened Mumbai archive endpoint (live)
    • MIT open source repo with deploy scripts, configs, and docs (live)
    • Public status page with health, uptime, and lag by region and outage history (live)
    • Reproducible benchmark report, Zebra versus Zakura (live)
    • Technical design document covering architecture, security, and privacy
      Acceptance Criteria: Community members, and any interested wallet team representative, confirm the endpoint is reachable and the status page and repo are usable and reproducible.

  • Milestone: 2, Second region, benchmarking suite, and wallet test
    Amount (USD): 12,000
    Expected Completion Date: about month 3
    User Stories:

    • “As a wallet developer, I want endpoints in more than one region and reproducible cross stack benchmarks, so that I can choose reliable endpoints using real data.”
      Deliverables:
    • A second independent region live and visible on the status page
    • Expanded reproducible benchmarking harness and report, independently reproducible
    • Integration documentation and support made available to wallet teams, with an invitation to test against the endpoints
      Acceptance Criteria: Two regions visible and healthy on the status page, and a third party reproduces the benchmark. Wallet integration support and documentation are provided and wallet teams are invited to test. A completed wallet test is a goal for this milestone but is not required for acceptance, since it involves the wallet team to adapt to support the full integration.

  • Milestone: 3, Third region, privacy and reliability hardening, and community initiative
    Amount (USD): 12,000
    Expected Completion Date: about month 6
    User Stories:

    • “As a privacy conscious user, I want no logging and Tor access, so that my usage is protected.”
    • “As a Zcash India community member, I want clear onboarding, so that I can run my own independent node if I choose to.”
      Deliverables:
    • A third independent region live and visible on the status page
    • Tor hidden service on the endpoints
    • Monitoring, alerting, and incident response runbooks
    • Published operator onboarding guide and one Zcash India community workshop inviting members to run their own nodes
      Acceptance Criteria: Three regions healthy on the status page, Tor endpoint reachable, runbooks published, onboarding guide published, and the workshop delivered. Community operator participation is a welcomed outcome but is not required for this milestone.

  • Milestone: 4, Ecosystem integration and sustainability
    Amount (USD): 8,000
    Expected Completion Date: about month 10 to 12
    User Stories:

    • “As a wallet team, I want clear integration documentation, so that I can add the network with minimal effort.”
      Deliverables:
    • Wallet integration documentation, published and open for wallet team review
    • Appliance friendly or one command self hosting packaging
    • A long term sustainability and maintenance plan
    • Final project report and handover materials
      Acceptance Criteria: Integration documentation is published and reviewed, ideally by a wallet team, and ZCG accepts the final report.

Supporting Documents

cc @ZcashGrants for any early guidance
@emersonian @zancas @hanh @Anzus_GemWallet

3 Likes
Grant Application - Open Light Nodes: Independent Zcash Light Client Infrastructure for Asia
2

Thank you for stepping up to contribute!

Jatin has already put in some useful PRs to zcash-stack, the open infrastructure code we use to run Zec.rocks. I like this early sign of collaboration and of course welcome more node operators around the world.

Currently the closest cluster region to India that we serve is Singapore, so while more decentralization is great, this also fills a gap in Zcash light wallet network coverage.

It takes a lot of time and care to maintain servers, the price is justified.

I’d love to see Kubernetes used especially with how LLMs make it easy these days, but Docker Compose in production can be okay too. I highly recommend trying out Kubernetes for stability though, especially for zero downtime deploys (multi-server deployments). Vultr’s Kubernetes is price efficient and works great with zcash-stack.

What’s your plan for if funding is rejected in the future, would you continue to run the nodes at a smaller scale or shut them down? I think you have a strong application here but encourage you to crowdfund by posting a Zcash address (and broadcasting it via lightwalletd/zaino) in the event that this particular application doesn’t work out.

More global coverage, and more operator decentralization, is great for Zcash users. Thank you for taking on some regions that Zec.rocks has not covered yet.

1 Like
3

Thanks for sharing the draft and for the shoutout! Just one small footnote before Gem Wallet accidentally gets assigned homework :grinning_face_with_smiling_eyes:

As I mentioned in the original thread, I can pass the endpoint, repository, and status page along internally, but testing and provider decisions belong to the relevant teams.

For accuracy, it may be better to say that Gem Wallet provided feedback on the status page and that endpoint testing remains unconfirmed, rather than saying a test integration is already being coordinated.

If anything progresses internally, I’ll follow up through the appropriate channel.

4

Thank you, this means a lot coming from the team behind zec.rocks and zcash-stack. The stack being open is what let me ship Phase 1 in days, and I intend to keep contributing back.

Good to know Singapore is your closest cluster to India. That is exactly the gap we want to fill, and I would like to coordinate with you so the regions we run complement zec.rocks coverage rather than overlap it.

On Kubernetes: agreed, and thank you for the concrete pointer. Zero downtime, multi server deploys are exactly what the reliability and uptime goals call for, so I will move the deployment to Kubernetes and try Vultr’s managed Kubernetes with zcash-stack as you suggested. I will share the results, including on the benchmark side.

On sustainability: I am committed to this for the long term and would not simply shut the nodes down if a future round were not approved. I really like your crowdfunding suggestion, so I will add a Zcash donation address and broadcast it through the endpoint. That gives the project a path to keep running with direct community support, independent of the grant.

Thank you again for the encouragement and the guidance. I will keep the thread updated as I roll out Kubernetes and the additional regions.

1 Like
5

Thank you, and you are completely right. No homework intended.

I will correct the wording so it accurately reflects your role: Gem Wallet provided helpful feedback on the status page, and endpoint testing is unconfirmed and would be a decision for your development and infrastructure teams. I appreciate you flagging it. Accuracy matters to me and I do not want to overstate anything.

No pressure on the rest. Thank you for passing the endpoint, repo, and status page along internally, and I will follow your lead on the right channel if anything progresses.

I have already edited the draft to reflect this: it now states that Gem Wallet provided feedback on the status page and that endpoint testing remains unconfirmed.

2 Likes