Fork of lightwalletd + service provider
A lightwalletd fork embeds a Nym service provider and is deployed in a DMZ (no inbound connections). Requires server + client changes to Nym addressing.
Runtime: Server-side (lightwalletd fork with embedded Nym service provider, in a DMZ) + per-app clientsdVPN (WireGuard)Mixnet (5-hop)Speed: Fast sync / slow broadcast
dVPN (WireGuard)Mixnet (5-hop)SURB reply
Sync over dVPN and broadcast over the mixnet both reach one forked lightwalletd that embeds a Nym service provider (in a DMZ). Broadcast replies return via SURBs, so the server never learns the client address.
ClientEntry GWMixExit GWlightwalletd
dVPN (WireGuard) (no mixing)Mixnet (5-hop) (mixing delays)
Latency model
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)
Per-actor assessment (inherited)
The same four threat actors apply. This architecture inherits the assessment of the configuration it implements: Mixnet · SP-integrated. Layer-2 baseline hygiene remains the wallet’s responsibility.
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 →
Above this transport: query shapeThis transport carries the bytes; what goes on the wire and when is decided above it. nym-swizzle-zcash shapes the query pattern itself — grid-aligned sync ranges and decoupled, restart-safe broadcasts — so the server can't chain sessions or attribute sends.The duty →The library →