Zcash × Nym

nym-smolmix (per-app mixnet client)

A per-app mixnet client with timing + location obfuscation built in. Ideal for the tiny, timing-sensitive broadcast path.

Runtime: Rust — native apps (mobile / desktop)Mixnet (5-hop)Speed: Slow
Mixnet (5-hop)
Mix L1+50 msMix L2+50 msMix L3+50 msWallet appEntry GWExit GWlightwalletd

Network path over the Nym network. See the client data-flow pipeline below for how requests are chunked into Sphinx packets and how SURB replies return.

ClientEntry GWMixExit GWlightwalletd
Mixnet (5-hop) (mixing delays)

Client data-flow pipeline

Goodput ≈ 51%2 packets · on-wire 4.0 KB+ 2 mixACKs (156 B)payload 2.1 KBupload · client → entry GW

A few KB — the ideal mixnet broadcast workload. Goodput ≈ 51% of on-wire bytes carry payload; the rest is Sphinx/IPR framing, fixed-size padding, WebSocket/TCP framing, and the 56 B mixACK return route.

Wallet app (client) — nym-smolmixSendTransaction2.1 KBIP stacksmoltcpSphinx + IPRmixnet clientEntry GWon the wire →SendTransaction ⇒ 2 Sphinx packets on the wire (4.0 KB):2008 B40015702008 B400630940~1600 B Sphinx payload − IPR framing ⇒ ~1570 B chunk, padded to a constant 2000 B Sphinx packet, wrapped in a WebSocket frame over TCP/IP.
Sphinx packet on the wireSphinx header (~400 B)IPR framing (~30 B)payload chunk (≤1570 B)padding → 2000 BWebSocket header (~8 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 SURBs.

Latency model

Regional (40)Continental (120)Intercontinental (300)
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

  • Transaction broadcasts
  • High-latency, low-bandwidth requests

Notes

  • Timing + location obfuscation built in
  • Slow (mixnet)

Per-actor assessment (inherited)

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

L2Compromised lightwalletd✅P1❌P2

Sees

  • Exit gateway / IPR IP
  • All requests and contents

Can't see

  • Client IP

Residual / countermeasure

  • The wallet's TCP connection to lightwalletd is an ordinary end-to-end connection arriving from the exit's IP. Per-packet unlinkability in transit does not translate into request unlinkability at the destination.
  • With a fixed IPR, P2 behaves exactly like the dVPN single-exit case — rotate the IPR per request to restore it (see the rotating-IPR scenario).
L3LLocal network observer✅P1

Sees

  • Constant-size packets at a Poisson rate with cover traffic
  • That the client uses the Nym mixnet

Can't see

  • Reliable destination, volume or activity
L3GGlobal network observer◐P1

Sees

  • Per-packet timing (hampered by mixing delays and cover traffic)

Residual / countermeasure

  • The extent to which bulk transfers of many packets can be correlated over time is an open question. The mixnet is strongest for small, independent messages and weakest for bulk sync — one reason bulk sync does not belong on the mixnet (the other is throughput).
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 →