Nym dVPN — 2-hop, single exit

A 2-hop WireGuard tunnel (entry + exit gateway) hides the client IP, but a single fixed exit leaves requests linkable at the destination within a session and weak across sessions.

✅IP hidden · P1@L2❌Req-unlink · P2@L2❌Local net · P1@L3L❌Global net · P1@L3G✅Fast sync

dVPN (WireGuard)

ClientEntry GWExit GWlightwalletd

dVPN (WireGuard) (no mixing)

Per-actor assessment & trade-offs

L2Compromised lightwalletd✅P1❌P2

Sees

Exit gateway IP
All requests and contents

Can't see

Client IP

Residual / countermeasure

P2 fails within a session: the tunnel delivers one NATed flow and, with gRPC, the whole sync typically uses one long-lived HTTP/2 connection. Across sessions, linkage depends on crowding at the exit IP.
Rotate the exit per request to restore P2 — see the multiple-exits scenario.

L3LLocal network observer

Sees

Sync fingerprint — WireGuard adds no cover and preserves packet timing

L3GGlobal network observer

Sees

End-to-end flow correlation

Residual / countermeasure

The 2-hop route only prevents a single gateway from linking client to destination (entry knows the client IP but not the destination; exit knows the destination but not the client IP). Both gateways colluding, or a global observer, can still correlate — the extra hop does not add protection over Tor's guard+exit.

Pros

Fast
Deployable today with no changes to lightwalletd

Cons / mitigations

A fixed exit is a linking key — rotate per request

Fit

The minimum: hides IP; must add exit rotation and §5 hygiene

Latency model

Geographic delay / hop120 ms

Regional (40)Continental (120)Intercontinental (300)

dVPN (WireGuard)360 ms (3 hops)

Geographic propagation (speed-of-light)

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).