NymVPN: a Rust VPN client that routes through a mixnet

The target is traffic patterns, not just addresses

The README describes NymVPN as a decentralized VPN, a dVPN, that protects traffic patterns, not just packet contents, and the argument it makes against conventional VPNs is the key to understanding the project.

A conventional VPN, the README says, replaces your ISP with a single trusted operator who can see both your IP and your destinations. NymVPN removes that trusted party. The client is open source, cross-platform, and written in Rust, and it routes traffic either through Nym's decentralized mixnet for metadata-level anonymity or over multi-hop AmneziaWG for low-latency, censorship-resistant tunneling. The claim that follows is that, unlike conventional VPNs, no single node can correlate who you are with what you do.

That is a different threat model from the one a normal VPN addresses, and it is worth being clear that the two are not substitutes. Encrypting the tunnel to a provider protects contents from the path, but the provider still sees the metadata. A design that removes the single observer of that metadata has to pay for it in hops, in cover traffic and in latency, and the whole design of the project follows from that trade.

The homepage is nym.com, and the project sits under the nymtech organisation. The licence is GPL-3.0, the default branch is develop, and the most recent releases are dated 2026-10-20, 2026-10-12 and 2026-10-09.

Two routing modes, chosen per connection

The README shows both modes in one diagram, and the diagram is the clearest statement of the architecture. A single Rust core in the app sends traffic either into a five hop mixnet or a two hop AmneziaWG tunnel, and in both cases no single hop sees both endpoints:

┌─────────────────┐    ┌──────────────┐    ┌─────────────────┐
│                 │ -> │   Mixnet     │ -> │   Destination   │
│                 │    │  (5 hops)    │    │                 │
│    NymVPN App   │    └──────────────┘    └─────────────────┘
│    (Rust Core)  │    ┌──────────────┐    ┌─────────────────┐
│                 │ -> │  AmneziaWG   │ -> │   Destination   │
│                 │    │  (2 hops)    │    │                 │
└─────────────────┘    └──────────────┘    └─────────────────┘

Mixnet mode is the five hop path through Nym's mixnet, with the Sphinx packet format, per-hop onion encryption, packet reordering and cover traffic. The stated purpose is to break the timing and volume correlations that deanonymize traditional onion and VPN traffic, and the README places it in the threat models where metadata exposure matters, naming crypto wallets, email and private messaging.

Fast mode is the two hop path on AmneziaWG, a censorship-resistant WireGuard fork, for performance-sensitive use, with the same guarantee that no single operator observes both endpoints.

Two routing modes in a single client, selectable per connection, is the practical feature. It lets a user decide per session which of the two costs they are willing to pay, and the README states plainly that the two modes are selected per connection rather than being a global setting.

zk-nyms make payment unlinkable from usage

The third pillar of the design is identity, and it is the part with no conventional VPN equivalent.

The README lists zero-knowledge credentials, the zk-nyms, as the mechanism where authentication and payment are cryptographically unlinkable from network usage, and states that no email or account identity is required to connect. In a normal VPN the account that pays for the service is the account the service can tie to the traffic, and a payment processor is a third party that sees both.

The fourth pillar is the topology. There is no single point of failure, because the network is operated by independent node operators with no central server to compromise, subpoena or surveil, and the feature list adds that there is no centralized logging because the multi-hop architecture makes meaningful traffic logs impractical to keep.

Those two claims are related, and the second is a consequence of the first rather than a separate policy decision. If traffic is spread across independent operators with cover traffic mixed in, a log of one operator's hop is not a log of a user, because the operator cannot tell which of the packets they saw belonged to which of the flows that passed through them.

The repository description puts it as protecting metadata, not just IP addresses, with zero-knowledge payments for unlinkable online activities, and the technical detail is in the NymVPN Litepaper and the Nym Whitepaper rather than in the README.

A client feature list that reads like a mobile VPN

The NymVPN Features list is a mix of privacy mechanisms and the ordinary expectations of a commercial VPN client, and the ordinary expectations are covered.

There is a built-in kill switch with data-leak prevention, custom DNS, and split tunneling to include or exclude apps from the VPN tunnel. There is built-in ad blocking to stop ads, trackers and malware. There is entry and exit node selection, and censorship resistance via AmneziaWG, Stealth connect and QUIC to prevent VPN blocking. On top of that sit the privacy properties, multi-hop by default so no node sees both your IP and your activity, the zk-nym credentials, and no centralized logging.

The cryptographic stack is listed in full: Curve25519, AES, ChaCha20-Poly1305, BLAKE2 and BLAKE3, the Lioness wide-block cipher, Pointcheval-Sanders signatures, Pedersen commitments, NIZK proofs, BLS12-381, and post-quantum key exchange.

The audit history is the part an evaluator should read first, because it is the evidence rather than the claim. The README lists independent audits by JP Aumasson in 2021, Oak Security in 2022, Cryspen in 2023 and 2024, and Cure53 in 2024, with a link to the Nym trust centre.

For a client that handles traffic and payments, four audits across four years is a reasonable baseline to expect, and the fact that the audits are named with dates is what makes the list useful.

One monorepo, six languages and a separate network repo

The repository is a monorepo containing all the NymVPN client source, and the README is explicit that it is separate from the Nym network monorepo. That split is a deliberate boundary: the client can be read, built and reviewed without wading through the network implementation.

The Platforms and Stack table maps each piece to a directory and a language. The core VPN engine is `nym-vpn-core` and `nym-vpn-windows` in Rust and C++. Android is `nym-vpn-android` in Kotlin. iOS and macOS are `nym-vpn-apple` in Swift and SwiftUI. The Linux and Windows desktop app is `nym-vpn-app` with Tauri and TypeScript. And the WireGuard integration is the `wireguard` directory in Go, which is a fork of the WireGuard Go implementation.

Six stacks in one repository is a real maintenance cost, and the fact that the desktop app is Tauri and TypeScript while the core is Rust means the boundary between the UI and the engine is also a language boundary.

The build reflects that structure. The top-level Makefile has an `all` target that builds the WireGuard integration and the core:

all: build-wireguard build-nym-vpn-core

# WireGuard build
build-wireguard:
	./wireguard/build-wireguard-go.sh

and there is a separate path for cross compiling to Windows from Linux, which the README notes requires binutils-mingw-w64 and mingw-w64:

# Used for cross compiling to target windows from linux
# requires:
#     binutils-mingw-w64 mingw-w64
windows-cross: build-wireguard-windows build-nym-vpn-core-windows

Ships on every store, with fingerprints to check

The download section is long, and every entry is a different distribution channel: Android builds from GitHub releases, F-Droid, Flathub, Google Play, the Apple App Store, TestFlight, and GitHub releases again for Linux, macOS and Windows.

That spread is the practical answer to a question a VPN client has to answer, which is how a user gets a build they can trust. The README publishes SHA-256 certificate fingerprints for the signed artifacts, with the package identifier `net.nymtech.nymvpn`, one fingerprint for the GitHub APK and one for the Google Play build:

3C:98:A0:16:AA:4F:14:A3:BA:18:5C:76:4E:D3:63:41:5C:F7:FF:3C:3D:32:8A:87:FF:FF:2F:F1:B1:40:FF:06

C0:FA:AA:D7:4F:17:BB:CB:4A:C2:30:93:F0:6A:B5:2E:8C:5C:95:F9:FB:AA:A2:D3:BF:02:24:2C:75:7E:82:BD

Publishing a fingerprint per channel is the part that matters, because it lets a user confirm that the app they downloaded is the one the project built, whichever store it came from.

The version scheme is worth noting too. The recent releases are named `nym-vpn-v2026.14.0-beta.1`, `nym-vpn-v2026.13.1` and `nym-vpn-v2026.13.0`, so the version carries the year, and the newest one is explicitly a beta. Contributions are welcome across the stack, from the Rust core through mobile, desktop, protocol research and security review, and localisation is crowdsourced through Crowdin.

Editorial conclusion

NymVPN fits a user whose threat model includes metadata, who is willing to accept the latency of a mixnet route for their sensitive traffic, and who wants to pay without an account tied to their activity. It is the wrong choice if you need the throughput of a plain WireGuard tunnel for large transfers, since the fast mode still routes through two hops and adds AmneziaWG's own overhead, and the wrong choice if you want a client with a long record of stable releases. Verify first which routing mode you are paying for in latency, that the store you install from matches the SHA-256 fingerprint published in the repository, and whether the beta release naming is acceptable for the device you put it on.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. nymtech/nym-vpn-client on GitHub
3. Project website
4. README
5. Releases