Exit security

Every tool that reaches an external service through the Nym Mixnet shares the same exit security model, whether it's the Rust smolmix crate, the SOCKS5 module, or the mix-* packages built on mix-tunnel (mix-fetch, mix-dns, mix-websocket). They leave the Mixnet at an Exit Gateway, either through the IP Packet Router (which forwards raw IP packets) or the SOCKS-based Network Requester (which makes the request from a SOCKS stream), so they share the same properties and the same caveat. Tools where both ends run a Nym client (nym-sdk, the TypeScript SDK) never exit the Mixnet at all; the end-to-end case is covered below. This page is the canonical statement of the model; the package pages link here rather than restating it.

The one-sentence version

In proxy mode the Mixnet hides who you are from the destination and where you're going from the network, but the Exit Gateway sees your destination and any payload you didn't encrypt yourself. In end-to-end mode there is no Exit Gateway: traffic stays Sphinx-encrypted the whole way.

Proxy mode or end-to-end?

Most of this page is about proxy mode: your traffic leaves the Mixnet at an Exit Gateway, via either the IP Packet Router (raw IP packets) or the SOCKS-based Network Requester (which sees the destination hostname), and continues to a third-party server over clearnet, where the security trade-offs apply.

If both ends run a Nym client (end-to-end), traffic never exits the Mixnet. It stays Sphinx-encrypted from your client to the other client, there is no Exit Gateway, and the encrypt-your-own-payload concern below does not arise: the Mixnet is the encrypted channel. What still applies to end-to-end traffic is everything that is not exit-specific: the trust boundaries (unlinkability is statistical, not absolute) and what the Mixnet does not protect (application identity, fingerprinting, traffic analysis). For the end-to-end wiring itself, see nym-sdk and the TypeScript SDK.

What each hop sees

Proxy mode: only your side runs Nym, and traffic exits to a third party:

you → entry gateway → 3 mix layers → exit gateway → destination
└─────────────── Sphinx-encrypted ──────────────┘└─ clearnet ─┘
                                     exit gateway 
				     strips Sphinx 
				     here

End-to-end: both sides run Nym, and traffic never leaves the Mixnet:

you → entry gateway → 3 mix layers → peer's gateway → peer Nym client
└────────────────── Sphinx-encrypted the whole way ─────────────────┘

The table below is the proxy-mode path. In end-to-end mode there is no exit and no clearnet hop, so only the first two rows apply and the far end is another Nym client rather than a remote host.

Segment	Mixnet encryption	What's visible
Your machine → Mixnet entry	Sphinx (layered)	Entry gateway sees your IP but not the destination
Inside the Mixnet (entry gateway + 3 mix layers)	Sphinx (layered)	Each node only knows its previous and next hop
Exit Gateway (IPR or NR)	Sphinx removed; raw IP packet (IPR) or SOCKS request (NR) exposed	The IPR sees the destination IP and port; the NR sees the destination hostname. Either way the payload depends on your application layer (see below).
Exit Gateway → remote host	None (Sphinx is Mixnet-only; your own TLS, if any, still applies)	Remote host sees the Exit Gateway's IP, not yours

The Sphinx encryption is the Mixnet transport layer: it protects packets as they traverse the mix nodes. In proxy mode the Exit Gateway strips the Sphinx layers and forwards the request to the destination, analogous to how a Tor exit node or VPN endpoint unwraps its tunnel. In end-to-end mode the Sphinx layers are only removed at the receiving Nym client, so nothing is ever exposed on clearnet.

Encrypt your own payload

Because the Exit Gateway removes the Sphinx layers, whatever is inside is visible to the exit unless you encrypted it yourself.

Application-layer encryption closes the gap. TLS, the Noise Protocol, or any authenticated encryption keeps the payload as ciphertext to the exit. It still sees the destination, but not the content. Over TLS the exit only ever handles ciphertext bound for that destination; the bytes inside stay opaque to it.
Unencrypted payloads are fully visible. Plain HTTP, unencrypted WebSocket (ws://), and plain UDP DNS are readable in full at the exit. The Mixnet still hides your identity, so the exit reads the content without being able to attribute it to you.

Trust boundaries

You trust the Mixnet to provide unlinkability between sender and receiver. Sphinx provides this cryptographically at the per-packet level: a node cannot read addressing beyond its own hop. Unlinkability of your traffic pattern over time is weaker, and statistical rather than absolute. It comes from mixing and cover traffic, and degrades with low network traffic, with cover traffic or Poisson timing disabled, and against an adversary that can observe a large fraction of the network.
You trust the Exit Gateway in the same way you trust a VPN exit or Tor exit node: it can inspect whatever leaves the Mixnet, but it does not know who is sending the traffic (the Mixnet hides your identity). What it can inspect, and the shape of the trust, differs between the two exit types:
- IP Packet Router (IPR). A packet forwarder, like a VPN exit. It receives raw IP packets, so it sees the destination IP and port and reads any packet payload you did not encrypt. It works at the network layer and does not parse your application protocol. This is the exit used by smolmix and the mix-* packages (mix-tunnel, mix-fetch, mix-dns, mix-websocket).
- Network Requester (NR). A SOCKS proxy that makes the request on your behalf, so your trust in it is exactly the trust you place in any SOCKS5 proxy. With the socks5h URL the SDK hands it the destination hostname (not just an IP) plus the byte stream, and the NR opens the TCP connection itself and relays bytes back. It therefore sees the destination hostname and port, and any payload you did not encrypt. This is the exit used by the SOCKS5 module and the standalone nym-socks5-client.

⚠️

Protect the payload with TLS or equivalent. If the exit operator matters to you, pin one; the control depends on the exit type:

IPR-backed clients (smolmix and the mix-* packages): set the preferred IPR (preferredIpr in the TypeScript and wasm packages; see each package page for the native equivalent).
SOCKS5 module (Network Requester): pin a specific requester with NetworkRequesterSelector::exact(...), or constrain the jurisdiction with NetworkRequesterSelector::in_countries([...]), passing either to Socks5MixnetClient::connect_with(...).

What the Mixnet does not protect

The Mixnet operates at the network layer: it hides your IP and unlinks sender from receiver. It does nothing at the application layer, so anything you reveal in the content of your traffic is yours to manage:

Application identity. If you log in, send a cookie, or include an API token, the destination knows who you are regardless of the network path. The Mixnet anonymises the pipe, not what you put through it.
Fingerprinting. A stable request pattern, a distinctive TLS or HTTP fingerprint, or a recognisable account correlates your traffic across sessions. mix-fetch's default headers reduce trivial fingerprinting but do not make you indistinguishable from a real browser.

Separately, the network-layer guarantee itself is not absolute:

Statistical traffic analysis. Unlinkability is probabilistic, not a guarantee. It is strong by default but weakens with low network traffic, with cover traffic and Poisson timing turned off, and against an adversary observing a large fraction of the network.

If you need anonymity at the application layer too, design for it explicitly: fresh identities, no cross-session correlators, and no logged-in accounts you also use over clearnet.

Comparison with other privacy tools

	Nym (Mixnet)	Tor	VPN
Exit node sees traffic?	Yes (encrypt it)	Yes (encrypt it)	Yes (encrypt it)
Exit node knows sender?	No (Mixnet hides identity)	No (onion routing)	Yes (VPN provider knows)
Timing analysis resistance	Strong with defaults (mixing, cover traffic)	Weak (low-latency)	None
UDP support	Yes	No (TCP only)	Yes

The timing-analysis rating assumes the defaults. Cover traffic and Poisson timing can be turned off to trade that resistance for latency and bandwidth, moving Nym's row toward Tor's. The named switches for this (disableCoverTraffic / disablePoissonTraffic) are specific to the browser/wasm packages (mix-tunnel and the feature packages built on it); the native smolmix crate does not expose them by those names. The UDP row reflects a design difference, not a ranking: Tor is TCP-only by design, while the Nym IPR routes raw IP.

Exit Gateway Services: how the SOCKS-based Network Requester and the IP Packet Router each route traffic past the exit, and how they differ.
Per-transport exposure (where TLS terminates, what the resolver sees, wss:// vs ws://) lives on each package's own page: smolmix, the SOCKS5 module, mix-fetch, mix-dns, and mix-websocket.

Overview Message Queue & Cover Traffic