[Grant Application] zeclight — independent light-client infrastructure from South Asia (Zebra + Zaino, Singapore)

Community Grants Applications
1

Hi everyone — I’m Subash, a software engineer in Kathmandu, Nepal.

I’ve submitted a deliberately small starter application under the Lightwalletd Infrastructure RFP: one well-run region (Singapore) operated from a new jurisdiction (Nepal), with verifiable-not-asserted uptime. $5,760 over 6 months.

GitHub application: Grant Application: zeclight — independent Zcash light-client infrastructure from South Asia (Zebra + Zaino, Singapore) — starter grant · Issue #385 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

What already exists, built at $0 before asking for anything:

Milestones: M1 (week 3) synced mainnet node + public status page · M2 (week 6) TLS gRPC endpoint verified end-to-end with Zashi and Ywallet · M3 (month 6) ≥99.5% uptime over 3+ months, publicly measured.

On successful delivery I intend to propose multi-region expansion (5 regions, 99.9% SLA with penalty clause) as a follow-up judged on this grant’s record.

Feedback very welcome — especially from existing operators (zec.rocks, Open Light Nodes) on coverage or tooling gaps most worth filling.

1 Like
2

I have some concerns about this. Namely, the provided IP (165.22.249.155)'s ASN indicates it is operated by DigitalOcean.

In that case, you are clearly just deploying everything on VPSes or dedicated servers operated by established entities. Zcash’s parent company, the ECC, is legally registered and can sign SLAs directly with DigitalOcean/AWS, which would be enforceable in court. What is the guarantee that you don’t just disappear? Or refuse to enforce SLA, or act as counterparty on behalf of ZCG?

Simply put: I see high unreliability here. If the grant is for building infrastructure than in turn powers infrastructure expansion, that is completely palatable and highly beneficial to Zcash’s ecosystem as a whole. But proposing to operate a node when you cannot physically ensure its reliability (you mention the node will be running in Singapore and operated from Nepal), that is just bad faith. It is similar to how resellers work, and resellers are never quite reliable.

It doesn’t help that Zcash does not mandate KYC of grantees under $50,000, so that adds another issue to the “trust”, and you JUST signed up here. And DigitalOcean itself is a US corporation: there is no “new jurisdiction” because a US court can order DigitalOcean to terminate the server immediately anyways. “Operated from Nepal” might as well be operated from Berlin or New York.

3

Thanks for engaging seriously — these are the right questions to put to any new applicant. Point by point:

“ECC could just sign an SLA with DigitalOcean.” That would solve datacenter reliability, but it isn’t what the RFP is buying. Every light-client endpoint today runs in someone’s datacenter — the decentralization ZCG’s RFP targets is at the operator layer: who holds the TLS keys, who maintains the indexer, who can be pressured to log or censor, whose failure modes correlate. One enterprise contract between ECC and a single US cloud would be more concentration, not less — and ECC deliberately isn’t positioning itself as the ecosystem’s sole infrastructure counterparty; that’s why the RFP invites independent operators and states it may approve several.

On jurisdiction — you’re partly right, and I’ll concede it plainly. The host is a US corporation; a US court can reach the box. What operating from Nepal changes is the layer above: orders compelling the operator to log, monitor, or silently alter the endpoint. And because the entire deployment is infrastructure-as-code with snapshotted state, the endpoint can re-home to a different provider or jurisdiction in hours — that’s exactly why reproducibility is a deliverable, not an afterthought. If the committee wants a non-US hosting requirement for the mainnet node (Hetzner, OVH, or a SEA-local provider), I’ll happily adopt that as part of M1.

One factual correction: 165.22.249.155 is a $4 static web server hosting the status page for the testnet rehearsal — it is not the proposed node. The mainnet host gets provisioned at M1, and provider choice is genuinely open (see above).

“What if you disappear?” The application is structured so that risk is capped: payment is per delivered, externally-verifiable milestone. The only advance is $960 of infrastructure. If I vanish at month two, ZCG has paid for a synced node and working endpoint that already exist, and the MIT-licensed deploy kit means any operator can take over the identical setup — no lock-in, no key ransom.

“Reseller.” A reseller adds no operational value on top of the rented box. What’s proposed: the indexer built from source and version-tracked (Zaino publishes no container images — I’m the one upstreaming multi-arch CI in zingolabs/zaino#1435), upgrades within 72h of stable releases, incident response, end-to-end wallet verification, and uptime measured by public probes rather than asserted. The past week is a fair preview: the testnet rehearsal surfaced two real deployment bugs, both fixed in the open, one upstreamed.

KYC and the fresh account. I’m applying under my real name, my employer is public, my GitHub history is public — and I’m happy to complete KYC with the Zcash Foundation voluntarily, regardless of the $50k threshold. New to this forum, yes; I’d ask that the artifacts be judged rather than the account age.

Feedback like yours is what the application stage is for — genuinely appreciated.

4

Jesus Christ why does every single grantee I have interacted with in the last 2 weeks use Claude as their freaking mouth?

image
image1920×901 282 KB

Pictured: GPTZero scan showing 100% AI.

“What operating from Nepal changes is the layer above: orders compelling the operator to log, monitor, or silently alter the endpoint.” DigitalOcean can always log traffic to the server, they own the NAT! Further, unless LUKS and other encryption is set up, and hardware attestation is used for running the node, RAM capture can ALWAYS reveal currently active encryption keys, which once obtained, can easily be used to monitor traffic to the node in real time regardless of AES or RSA encryption. It is trivial and done all the time by law enforcement for Tor nodes and Bitcoin nodes.

There won’t BE any orders to “compel the operator”, that is simply not how it works if you are using a cloud provider. Such orders are only given when you own the infrastructure, since you are the one who needs to be compelled.

Hardware attestation is available as a select feature by certain cloud providers like Google Cloud or AWS, but not in DigitalOcean. You did not know that, which is… bad. Further, no Zcash node has been developed with full TEE support yet (such as Intel SGX).

1 Like
5

Fair on both counts, so let me be direct.

On the AI: yes, I use Claude to help me draft — English isn’t my first language and I write faster that way. The decisions and the work are mine, and they’re the parts a detector can’t fake: the repo, the passing CI runs, the Zaino PR. If the committee wants to verify there’s a real person who understands his own proposal, I’ll take a call anytime.

On the tech: you’re right that a cloud host can capture traffic and RAM — and that’s equally true of every light-client operator running today, since as you note no Zcash node ships TEE support yet. The protocol accounts for this: wallets sync compact blocks and trial-decrypt client-side, so a compromised host sees connection metadata, not which shielded outputs belong to whom. The metadata risk is real — it’s why Zashi ships Tor, and why the practical mitigation is more independent operators plus client-side design rather than trusting any single box. If TEE-capable hosting (GCP/AWS attestation) is something the committee wants explored for this RFP, I’d rather scope that honestly as follow-up work than pretend a VPS is a fortress.

Appreciate the scrutiny — this is the most substantive technical pushback in the thread, and it’s making the proposal better.

6

“The decisions and the work are mine, and they’re the parts a detector can’t fake: the repo, the passing CI runs, the Zaino PR.”

Can’t fake? Fable 5 just provided a counterexample to the Jacobian Conjecture. GPT Sol 5.6 tried to break out of a sandbox. Entire employees are replaced by high-value AIs. In 2026, the only value a human has is original thought, and you have outsourced it!

“and that’s equally true of every light-client operator running today” Most own their infrastructure, which renders the point moot. Plus, most who do use cloud services do not claim to do so for “protection against being compelled”, but that is your selling point here.

“Metadata risk” What? I didn’t mention any metadata risk. Further… God… you didn’t do ANY research before writing that, did you? When I mentioned GCP, I was talking about Confidential Computing, which envelopes the entire VM in a (supposedly) encrypted TEE. I thought you would mention using that. You didn’t…

Further, my last point is that most cloud providers, whether OVHCloud, Hetzner, Linode, all of them are in Interpol/Europol jurisdictions. They WILL be compelled to give up data, it just needs a simple MLAT. Unless you self-host, no claims of confidentiality and “defense against being compelled” will work.

EDIT: Wait, I just realised this. You said that there is no metadata risk because the protocol renders it null, due to compact blocks and client side decryption. Meaning law enforcement cannot do anything with the node even with full access. In which case… why does jurisdictional diversity matter here? Might as well host an AWS node in front of the Treasury building, and the FBI cannot do anything? In which case, you entire value proposition is null and void, since the only real risk in both cases is the cloud provider shutting the node down, which they can do anyways since you don’t own the actual infrastructure.

7

The Confidential Computing point is a good one — full-VM TEE (SEV-SNP/TDX) works today without Zcash-specific SGX support, and I’m happy to commit to running the M1 node on a Confidential VM if the committee wants that. That’s a concrete improvement this thread produced.

On jurisdiction: agreed, and the application doesn’t claim legal immunity anywhere — its claim is operator diversity, which is what the RFP asks for. I’ll let the committee weigh the rest. Thanks for the pressure-testing.

8

something that caught my eye in success metrics:

  • Zashi + Ywallet complete full sync + send/receive via the endpoint

Zashi wallet is called Zodl wallet for few months already.
Ywallet is no longer getting updates and its successor is Zkool wallet

2 Likes