What if Zcash never broke again because of a single lightwalletd server?

General
1

Building for Zcash Shouldn’t Be This Hard

Hey everyone,

I’m Emilio, a full-stack developer. I’ve been working with Zcash for a while now and one thing became crystal clear: the privacy tech is amazing, but the barrier to entry for developers is way too high.

The Real Problem

Your app connects to a single lightwalletd server. That server goes down or falls behind. Your app stops working. Users think Zcash failed.

This has already happened multiple times:

  • ECC Emergency Mode (2023)

  • Nighthawk infrastructure shutdown (2024)

  • Multiple reports of lightwalletd failures

Every team has to build their own failover system from scratch. That’s what’s holding back new developers.

Why This Matters

I’ve worked across different ecosystems and there’s a clear pattern:

Ethereum → Web3.js comes out → Any web dev can build dApps → Explosion of projects

Algorand → Simple Python SDK → Students and researchers can start in minutes → University adoption

Zcash → You need Rust, understand infrastructure, build everything from scratch → Many give up

I’m not talking about wallets. Those already have their teams. I’m talking about:

  • Students doing thesis projects

  • Freelance devs with quick ideas

  • E-commerce plugins

  • Donation bots

  • Educational tools

  • Prototypes to validate ideas

These projects don’t exist because getting started is too complex.

Without Our Toolkit vs With Our Toolkit

Without our toolkit:

  • Need to learn how lightwalletd works

  • Manually configure multiple servers

  • Write retry and failover logic

  • Handle timeouts, circuit breakers, exponential backoff

  • Monitor server health

  • Keep all this updated

Estimated time: 2-3 weeks (if you know what you’re doing)

With our toolkit:

Option 1 - SDK (for JS/TS devs):


npm install @zcash/auto-failover

const client = new ZcashClient({ autoFailover: true });

// Done. Auto failover in <3 seconds

Option 2 - HTTP API (any language):


curl "https://api.zcash-failover.dev/best?region=us"

# Returns the best available server

Option 3 - DIY Guides:

Step-by-step documentation with real code you can copy and adapt to your specific use case.

Estimated time: 15 minutes

What Could Be Built

Things that should exist but don’t because of the high technical barrier:

  • Payment plugins for Shopify/WooCommerce

  • Telegram bots for community payments

  • Private subscription systems

  • Tools for teaching privacy at universities

  • Third-party APIs on top of Zcash

  • Quick MVPs to validate ideas

The Impact

Before:

Idea → 3 weeks on infrastructure → Frustration → Goes to another chain

After:

Idea → 15 minutes → Working prototype → More projects on Zcash

More developers = More use cases = More adoption

No Vendor Lock-In

  • Everything MIT (open source)

  • We don’t touch private keys

  • Decentralized registry (you can host your own copy)

  • If our service goes down, the system keeps working

If you think this makes sense, I have a formal proposal with all the technical details: ZCG Grant Proposal – Auto-Failover Toolkit v2 - Community Grants / Applications - Zcash Community Forum

Any feedback or support (even just a comment) helps a lot.

Thanks,

Emilio

7 Likes
2

Oh finally. So basic, so needed.

With this we don’t need to pay millions for fancy lightwallet servers anymore. That’s also to say the investment will be quickly recouped.

2 Likes
3

I’d rather have something like that integrated with the lwd protocol: a seeding and peer discovery service… A bit weird to have to use another library when nodes typically find each other automatically.

3 Likes
4

It’s non-sense we don’t already have this clearly, I’m approving (voting for) whichever comes first so I don’t have to hear about spending for fancy lightwalletd servers.

2 Likes
5

@outgoing.doze Out of curiosity where are you seeing data on indexer cloud spend

2 Likes
6

Thanks for the comment, @hanh. I agree: the ideal is native discovery/seeding in lightwalletd (not just at the app layer).

Our toolkit fixes outages now (MIT, self-hostable, no lock-in) while we push that standard.

I plan to open a short “lightwalletd-discovery” draft and issues to align with maintainers. Options I’d propose:

• DNS SRV (_lightwalletd._tcp) for simple discovery.

• /.well-known/lightwalletd-peers.json (signed, HTTPS).

• A health/peers endpoint in lightwalletd (gRPC/HTTP) for metrics and rotation.

If the community adopts a mechanism, the SDK becomes a client of the standard and the directory can be sunset.

Do you see pros/cons between SRV, well-known, or an explicit endpoint as a first step? If you’re up for it, I’ll prepare the draft and share it here.

1 Like
7

Thanks, @outgoing.doze that’s exactly the goal: reliability without fancy infra. It’s MIT and self-hostable. I’ll share a tiny demo + chaos-lab scripts soon so anyone can verify the failover. Appreciate the support

2 Likes
8

My current understanding of the situation is described in the following message:

If it’s wrong, good. We still need to make it easy to have smart selection of lightwalled based on latency and quick smooth failover when one fails, don’t you think @shieldedmark ?

3 Likes
9

Sure, and other avenues worth exploring (that address more of the trust model than reliability) could be:

  1. Some sort of quorum-based mutli-indexer querying to detect divergence on certain types of data. This could be incorporated rather easily if we decide to trust the failover system in place.
  2. Verifiable compute / remote attestation to prove the indexer operator is running the correct, unmodified version of the software.
3 Likes
10

We have a working WooCommerce Zcash payment plugin for ZGo.

4 Likes
11

Thanks, @pitmutt — good to know. I listed those as use cases that benefit from stronger infra; ZGo’s WooCommerce plugin is a great example. Our toolkit is complementary: multi-endpoint lightwalletd failover to keep apps online during endpoint hiccups.

1 Like
12

it is not that easy. You can see by the number of different peer discovery protocols out there. kamdelia, gossip, etc. I have the feeling that the benefits of this proposal won’t be enough to make the devs integrate it, but it could be wrong.

With zcash there are more risks, a malicious actor could try to exploit the system to have clients connect to it.

4 Likes
13

@hanh @outgoing.doze Hello i want to say something strong textabout this the project does not add peer discovery (no gossip/Kademlia). v2 focuses on client-side failover across pre-trusted endpoints. Selection is limited to a wallet-controlled allowlist, backed by a signed JSON registry (ed25519) and TLS pinning. This minimizes attack surface and avoids clients connecting to malicious nodes.

2 Likes
14

Relevant: Wallet App Threat Model — Zcash Documentation 6.10.0 documentation

3 Likes
15

Threat models are critical to us evidently. Pardon me for going sideways here, but it’s somewhat relevant.

Preface: I have no buff, nothing against @emersonian. Seem like a cool, smart, person.

But, this is also him, the guy in charge of the main lightwalled, used by Zashi (and some other wallets I suppose):

I am personally assuming he is still working with LE (as we all should), because why wouldn’t he, in such a perfect position to surveil the network activity.

That is to say that my expectation is that wallet should be able to send transactions in a way to is safest for the user. I don’t like the direction in which we need to introduce trust in the equation.

I don’t mean this as a complain though. I’m a ZEC user, been for a long time. I am just sharing how I see things as a user, should someone find this useful.

1 Like
16

I think @emersonian is generally respected among the community, but that’s irrelevant because the security of the system shouldn’t depend on whether we believe a single operator is a “good guy” or a “bad guy”

The threat model I linked addresses this (correctly imo) by treating the lightwalletd server as at least partially adversarial. Also, the lightwalletd code is open source and auditable by anybody for concerns like back doors or exfiltration tools.

Also, multiple independent teams and individuals have reviewed and run this stack for years; many many smart people are verifying, not blindly trusting.

4 Likes
17

To avoid confusion: our approach is complementary and modular. We provide a plug-and-play SDK, a Directory API to list/filter active endpoints, and a semi-automatic mode using a signed allow-list that anyone can copy or self-host. We do not add peer discovery; failover operates only over wallet-approved endpoints (ed25519 signatures + TLS pinning), aligned with the Wallet Threat Model by treating the indexer as partially adversarial. Everything is MIT / no lock-in, with best-practice docs so apps stay online even during endpoint hiccups.

@outgoing.doze @hanh @shieldedmark

3 Likes
18

Super well explained, Emilio. This is exactly the kind of tooling Zcash needs so developers don’t have to fight infrastructure just to build simple prototypes. Removing the single-server dependency on lightwalletd completely changes the developer experience.

Thanks for bringing a real, open-source solution to the table. I genuinely hope this gets the support it deserves this is the type of work that actually drives adoption and unlocks new projects in the ecosystem

3 Likes
19

Thanks so much

2 Likes
20