Zcash light-wallet privacy over the Nym network

A light wallet leaks three things to lightwalletd: its IP, the timing of its traffic, and a block-height fingerprint that links its sync sessions and transactions. This site visualises the options from the Nym × Zcash reference doc — mixnet vs dVPN — for closing those leaks, with animated mixing and an illustrative latency model.

Compare all scenarios

Scenario	Client IP hidden	Timing obfuscation	Fast compact-block sync	Timing-safe broadcast
Unprotected	❌	❌	✅	❌
VPN	✅	❌	✅	❌
Mixnet · IPR	✅	✅	❌	✅
Mixnet · SP	✅	✅	❌	✅
Multipath · mixnet	✅	✅	❌	✅
Multipath · dVPN	✅	❌	✅	❌
★ Recommended hybrid	✅	◐	✅	✅

Click a scenario name for its detailed, animated diagram. ✅ yes · ❌ no · ◐ partial (mitigated).

Network-privacy scenarios

Unprotected

The wallet talks to lightwalletd directly. No IP, timing or block-height obfuscation — the baseline everything else improves on.

VPN

A VPN hides the client IP behind an exit gateway, but lightwalletd still sees a wallet syncing from a resume height up to the head — timing correlation remains.

Mixnet · IPR

Traffic routes over the 5-hop mixnet to an IP Packet Router, which forwards to a stock lightwalletd. Strong IP + timing + location privacy, but sync is very slow.

Mixnet · SP

A Nym-native service provider replies via SURBs, so lightwalletd never learns the client identity or location. The strongest scenario — resists even a global passive adversary — but very slow and needs client/server changes.

Multipath · mixnet

Different block chunks are requested from different exit gateways over the mixnet, from a single entry gateway. Spreads requests across exits; still slow due to 5-hop + mixing.

Multipath · dVPN

A single entry gateway, peers registered on many exit gateways; each batch of requests takes a dVPN route to a different exit. Fast, hides IP — but no mixing delays, so sync timing is still correlatable.

★ Recommended hybrid

The only combination that scores on all four properties: bulk block sync over fast dVPN (multipath exits + out-of-order buffered requests), timing-sensitive tx broadcast over the mixnet. Strongest variant sends broadcasts to a forked lightwalletd service provider replying via SURBs.

Reference architectures

mixFetch

A drop-in fetch / WebSocket replacement — the only in-browser option. Routes over the 5-hop mixnet. Not for block syncs or short-timeout requests.

nym-smol-dvpn

A per-app dVPN client (1- or 2-hop WireGuard) with a post-quantum PSK created at registration and a QUIC bridge if WireGuard is censored. No timing obfuscation — the caller must add it.

nym-smol-mix

A per-app mixnet client with timing + location obfuscation built in. Ideal for the tiny, timing-sensitive broadcast path.

★ Hybrid

The recommended architecture. One process runs both a per-app dVPN client and a per-app mixnet client: sync over dVPN, broadcast over the mixnet.

Forked lightwalletd

The strongest variant. A lightwalletd fork embeds a Nym service provider and is deployed in a DMZ (no inbound connections). Resists a global passive adversary; requires server + client changes to Nym addressing.

NymVPN (whole machine)

Zero-integration fallback: all device traffic goes over Nym in the user's chosen mode. Cannot split sync from broadcast until 3-way app tunnelling ships.

Deep dive

Mixnet deep-dive

Watch fixed-size Sphinx packets shuffle through an expandable many-node mixnet with cover traffic, see the delay added at each hop, and the Sphinx vs WireGuard packet framing.

dVPN cover traffic

Many wallets share one gateway and all send getBlockHeight() — lightwalletd sees indistinguishable requests from a single exit IP. The more wallets, the larger the anonymity set.