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.
Runtime: Rust — native apps (mobile / desktop)dVPN (WireGuard)Speed: Fast
dVPN (WireGuard)
Network path over the Nym network (mostly block downloads, some uploads). See the client data-flow pipeline below for how requests are chunked into WireGuard packets and how replies return.
A few KB — the ideal mixnet broadcast workload. Goodput ≈ 90% — WireGuard framing is the only overhead.
WireGuard packet on the wireWireGuard hdr — entry (~60 B)WireGuard hdr — exit (~60 B)payload (≤1380 B)
Pick a gRPC message to see how it fragments and frames inside the client, and what fraction of on-wire bytes carry real payload (goodput). Replies return as regular WireGuard packets.
Timing obfuscation must be done by the caller (out-of-order, buffered requests)
Fast
Per-actor assessment (inherited)
The same four threat actors apply. This architecture inherits the assessment of the configuration it implements: dVPN · single exit. Layer-2 baseline hygiene remains the wallet’s responsibility.
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.
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.
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 →