Introduction

zero-indexer is privacy for Zcash light wallets, a Shielded Labs product. It stands on two pillars:

• zero-leak indexing: a light wallet should sync and transact without handing an indexer the raw material to deanonymize it.
• the Nym mixnet: the transport that unlinks a wallet’s traffic from its source IP and region.

Today a Zcash light wallet leaks. Under the ZIP 307 light-client protocol it talks to an indexer over clearnet, so the operator sees the wallet’s source IP and the timing of everything it does. The problem and threat model lays out that leak and its worst instance, the Orchard to Ironwood migration, which Zooko called the worst privacy-loss event in Zcash history.

Near-term and long-term

Two efforts share a name and a direction but not a scope.

The near-term system is urgent and narrowly scoped: stop transactions that touch the Orchard pool, starting with the Orchard to Ironwood migration, from leaking a user’s IP. It is a small, attested system, deliberately an 80% first step, honest about the 20% it does not cover. The shim and the hub are built and run as attested enclaves, and a real Orchard to Ironwood migration has gone through the whole stack on mainnet: held, batched, and published on the flush cadence, with the operator’s indexer never seeing it. The Nym hop is deployed: an attested pair has run it on the public mixnet since 2026-08-14, though the live pair’s provenance does not yet reproduce, so it is not independently verifiable. STEVE and the key consortium remain design (roadmap has the status table).

The long-term vision is the fuller product the name promises: a wallet-facing private indexer serving queries, not just broadcasts, over Nym, terminated inside an attested enclave, with PIR added later as a hardware-independent layer. That arc is deferred until the migration fix ships. Roadmap traces the three versions (V1 Nym, V2 +TEE, V3 +PIR). Most of this book is the near-term system, because that is what is being built now.

The system in its world

Seen from outside, zero-indexer is one thing: an attested front-end that a wallet talks to exactly as it talks to an indexer today, and that publishes the transactions most at risk on someone else’s schedule rather than the sender’s. Who touches it, and what it touches:

flowchart TB
  USER["Wallet user (the IP at stake)"] -->|"runs"| WAL["Wallet software (zingo, Zashi, ywallet)"]
  WAL -->|"queries + broadcasts, same endpoint URL as today"| ZI["ZERO-INDEXER"]
  OPR["Light-wallet operator"] -->|"deploys the front-end; untrusted for Orchard-touching contents"| ZI
  TO["Hub operator / Trusted Organization"] -->|"operates the batcher; announces a detected attack"| ZI
  AUD["Auditor (any independent party)"] -->|"verifies attestation + CT, without trusting an operator"| ZI
  KC["Key consortium (Caution / Nym / SL / ZF)"] -->|"governs the long-lived keys"| ZI
  ZI -->|"publishes transactions, reads the chain tip"| ZEC["Zcash network"]
  ZI -->|"unlinkable internal transport"| NYM["Nym mixnet"]
  ZI -->|"attested execution, hardware root of trust"| NITRO["AWS Nitro"]
  ZI -->|"ordinary CA certificate, publicly logged"| CT["Let's Encrypt + Certificate Transparency"]
  ZI -->|"hosted on"| CAU["Caution's enclave platform"]

  classDef enclave fill:#1b7f4d,color:#fff,stroke:#0d5233;
  classDef client fill:#2563eb,color:#fff,stroke:#1e40af;
  classDef actor fill:#d97706,color:#fff,stroke:#92400e;
  classDef keyinfra fill:#7c3aed,color:#fff,stroke:#5b21b6;
  classDef external fill:#6b7280,color:#fff,stroke:#4b5563;
  class ZI enclave;
  class USER,WAL client;
  class OPR,TO,AUD actor;
  class KC keyinfra;
  class ZEC,NYM,NITRO,CT,CAU external;

The cast