★ Recommended architecture

Hybrid: nym-smol-dvpn + nym-smolmix

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.

Runtime: Rust — native apps, both modes concurrently in one processdVPN (WireGuard)Mixnet (5-hop)Speed: Fast sync / slow broadcast
dVPN (WireGuard)Mixnet (5-hop)
Mix L1+50 msMix L2+50 msMix L3+50 msClientUser-space IP stack (smoltcp)2-hop WireGuard (boringtun)Nym mixnet clientEntry GWExit GW (mixnet)Exit GW (dVPN)lightwalletd

One process runs both per-app clients: sync over dVPN via one exit gateway, broadcast over the mixnet via another — one entry gateway, one lightwalletd.

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

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)

What to send over it

  • dVPN: block syncs, low-latency high-bandwidth requests
  • Mixnet: transaction broadcasts, high-latency low-bandwidth requests

Notes

  • Each app creates a per-app dVPN client (PQ PSK, QUIC bridge) and a per-app mixnet client
  • Recommended architecture (see Recommendation)

Per-actor assessment (inherited)

The same four threat actors apply. This architecture inherits the assessment of the configuration it implements: Recommended hybrid. Layer-2 baseline hygiene remains the wallet’s responsibility.

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

Sees

  • That the client syncs Zcash (sync flow fingerprintable)

Can't see

  • Broadcasts (routed separately over the mixnet — unobservable)

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