Zcash × Nym
★ Recommended

Recommended — per-app hybrid: dVPN for block sync + mixnet for broadcast

The most practical target: bulk block sync over fast dVPN (multipath exits + out-of-order buffered requests), timing-sensitive tx broadcast over the mixnet. The two streams share no session state, so broadcasts are unlinkable to the sync profile by default. Strongest variant broadcasts to an SP-integrated lightwalletd replying via SURBs.

✅IP hidden · P1@L2✅Req-unlink · P2@L2◐Local net · P1@L3L◐Global net · P1@L3G✅Fast sync
dVPN (WireGuard)Mixnet (5-hop)
Mix L1+50 msMix L2+50 msMix L3+50 msClientEntry GWExit GW (mixnet)Exit GW (dVPN)lightwalletd

One client and entry gateway. Block sync (dVPN) is mostly downloads — blocks flowing lightwalletd → exit → entry → client — with ~10% uploads. Tx broadcast (mixnet) is upload only: client → entry → 3 mix layers → exit → lightwalletd. Both reach a single lightwalletd.

ClientEntry GWMixExit GWlightwalletd
dVPN (WireGuard) (no mixing)Mixnet (5-hop) (mixing delays)

Per-actor assessment & trade-offs

L2Compromised lightwalletd✅P1✅P2

Sees

  • Sync side: a pseudonymous height-chain profile
  • Broadcast side: arrival timing on the mixnet path

Can't see

  • Client IP
  • Which broadcast belongs to which sync

Residual / countermeasure

  • The two streams share no V1 (different transports, different IPs, no common session). Broadcasts are unlinkable to the sync profile and to each other via per-request tags and decorrelated timing (§5).
  • Invariant A holds under three conditions (§4.5): (i) the sync tunnel hides the client IP; (ii) broadcasts are unlinkable to the sync profile and to each other; (iii) broadcast contents do not identify the user through auxiliary information (Invariant B).
L3LLocal network observer◐P1

Sees

  • That the client syncs Zcash (sync flow fingerprintable)

Can't see

  • Broadcasts (routed separately over the mixnet — unobservable)
L3GGlobal network observer◐P1

Sees

  • The sync flow (correlatable)

Can't see

  • Amounts and broadcasts

Residual / countermeasure

  • Sync is correlatable but uninformative — a network adversary learns 'this client syncs Zcash', not amounts, and broadcasts are protected. The hybrid does not make sync invisible; it makes sync uninformative.

Pros

  • Client IP hidden, fast compact-block sync, and timing-obfuscated broadcast in one design
  • Strongest variant resists a global passive adversary via an SP-integrated lightwalletd (SURBs)

Cons / mitigations

  • Needs a pluggable per-request-class transport, an out-of-order buffered block scheduler, and coordination on shared exit-gateway sets

Fit

  • The recommended architecture for wallet teams: fast private sync + timing-safe broadcast

Latency model

Regional (40)Continental (120)Intercontinental (300)
Block sync · dVPN (WireGuard)360 ms (3 hops)
Tx broadcast · Mixnet (5-hop)1.6 s (6 hops, 3 mix layers)
Geographic propagation (speed-of-light)Per-hop mixing delayReliable-channel ACK (return, geographic only)Fragmentation (bounded send rate)

Fragmentation latency shown for SendTransaction (2.1 KB): a larger message splits into more Sphinx packets, metered onto the mixnet at a bounded rate, adding latency.

Baseline hygiene applies here tooWhatever the transport, the wallet still owes the same Layer-2 discipline: randomize request times, obfuscate the start height, and never broadcast on reaching the tip.Full detail →

Content from the Nym × Zcash reference doc. Latency figures are an illustrative model (not measured).