Mix Networks Friday — June 19 2026 Weekly Update

TL;DR — This Week

• Tor: Arti 2.4.0 released June 1 2026 with flowctl-cc (RTT-congestion control, proposal 324) promoted to stable. This is the first Arti release where the relay + directory-authority roles are the headline feature, not the future. Multiple breaking TorClient API changes — downstream Rust users must migrate.
• Tails: 7.8 (May 21) plus emergency 7.8.1 (June 4) — kernel + Tor client security fixes. 7.9 shipped June 18.
• Tor Browser: 15.0.14 (May 19) → 15.0.15 (June 3) — plus alphas 16.0a6 (May 7) and 16.0a7 (June 3). The v16 line is in feature freeze; the v15 emergency cadence is the new normal.
• CGO (Counter Galois Onion): November 2025 announcement is being followed by a slow burn across 2026. No firm flag day yet; tor-dev is still resolving edge cases. The good news: production CGO performance is faster at proxies and exit/entry routers than the legacy tor1 scheme.
• I2P: 2.13.0 target is August 2026. The big ticket item is the SSU2-PQ transport (proposal 169) — the first time the I2P wire protocol itself gains post-quantum protection, beyond the ratchet layer that shipped in 2.11.0.
• Nym: The March 13 2026 roadmap is now the load-bearing document. Three concrete bets for the year: (1) hand-optimized crypto by djb, (2) formally-verified crypto by Karthik Bhargavan, (3) new cover-traffic scheme from joint research with EPFL that the roadmap claims is "more resistant to statistical attacks (including AI-powered) than any other VPN." The Lewes Protocol PQE is live (optional toggle) in NymVPN Fast mode; Anonymous mode PQ work continues.
• Katzenpost: No major code change this week, but the threat model remains the architectural reference for PQ federated mixnets. Watch for hybrid PQ (X25519+ML-KEM) deployment updates.
• HOPR: Active repo, not archived; payments + Sphinx packet relaying still the niche. No headline release this week.
• Research: Outfox (SIGCOMM 2025) and MOCHA (ePrint 2025/861) remain the load-bearing 2026 papers. No new paper has superseded them this week, but expect USENIX Security 2026 to be the next venue for mixnet papers.

The freedom-tech takeaway: the mixnet space is bifurcating into Tor/I2P-as-default-transport and Nym/Katzenpost-as-metadata-shield. The two are complementary, not competitive.

The Week in Detail

Tor / Arti: The Rust rewrite hits the relay path

Arti 2.4.0 (June 1 2026) is the most important Arti release of the year so far, because it is the first release where the headline is Arti as a relay and as a directory authority — not "coming soon" but actively shipping. The accompanying promotion of flowctl-cc to stable is also significant: this is the implementation of proposal 324 — RTT-based congestion control for Tor streams — and it has been the gating work for moving Arti beyond client-only.

Concrete 2.4.0 changes:

• Relay role: Arti can now act as a relay on the network. Not a directory authority yet as a default config, but the code path is shipped.
• Directory authority role: Continued development. The directory authority logic is the most complex Tor protocol role after the relay itself; this is the next major milestone.
• Onion service client connectivity: Multiple bug fixes to address real-world connectivity issues. This is a reminder that Rust implementations, even when protocol-correct, can have edge-case bugs that the C implementation has ironed out over 20 years.
• use_obsolete_software option removed (#1960) — a clear sign the project is tightening its contract with downstream users.
• Multiple breaking TorClient API changes — downstream arti-client crate users must update. Combined with the next release's planned Arc wrapping requirement, the Arti team is consolidating the API surface before the directory-authority milestone.

For ungovernable system design: Arti is now viable for embedded, mobile, and programmatic use cases that the C tor daemon does not support well. If you are building a Rust app and want to embed a Tor client, Arti is no longer a "we'll catch up" dependency — it is the recommendation. If you want to run a Tor relay from a Rust-native stack, 2.4.0 is the first release where that path is realistic for non-production use.

Tor Browser: Emergency cadence is the new normal

The Tor Browser release rhythm in May 2026 was striking:

The Firefox ESR base is a constant security-pressure source, and the Tor Browser team is matching that pressure with frequent releases. This is not a sign of weakness — it is a sign of an active maintainer team responding to a hostile environment.

The 16.x line is in alpha and is not the production target yet; 15.x remains the stable branch. If you are integrating Tor Browser for at-risk users, pin to 15.x stable, not the alpha line.

Tails: The amnesiac OS is shipping too

• Tails 7.8 (May 21 2026): Adds automatic Thunderbird-via-Additional-Software to keep the email client current with each release (this is a meaningful security improvement — Thunderbird was a long-running source of vulnerabilities).
• Tails 7.8.1 (June 4 2026): Emergency release. Patches CVE-2026-43503 in the Linux kernel (a privilege-escalation in the Debian kernel image) plus unspecified Tor client security vulnerabilities. This is the second emergency in three weeks after 7.7.3 (May 12).
• Tails 7.9 (June 18 2026): Latest, fresh as of yesterday.

For at-risk users, Tails 7.8.1 or later is required for safe use. The emergency cadence here is the cost of running a security-focused OS on top of a moving Linux kernel — the same surface that protects you can be the surface that breaks you.

CGO (Counter Galois Onion): Slow but real

CGO was announced on 2025-11-24 and the paper is ePrint 2025/583. As of mid-2026, deployment is still in the working-through-edge-cases phase. The pre-conditions for a network-wide flag day:

1. Every relay (guard, middle, exit) must be ready to negotiate CGO.
2. The directory authorities must be able to flag CGO-capable relays.
3. Clients must fall back gracefully when a path contains non-CGO relays (which will be the case during rollout).
4. The protocol change must not break onion services, pluggable transports, or any of the many things that depend on the existing tor1 cell format.

The performance numbers from the paper are favorable: CGO is faster at proxies, exit, and entry routers, with a "mild slowdown" at intermediate routers. This is the right trade-off for an anonymity network where entry/exit routers see the most traffic and intermediates see the most per-packet work.

The interesting open question: how will CGO interact with pluggable transports like obfs4, Snowflake, meek, and WebTunnel? Pluggable transports wrap Tor cells in obfuscation, and any change to cell format can break the wrapping. The tor-dev list has been working through this.

For ungovernable system design: do not deploy custom CGO code paths yet. Wait for the network-wide flag day and a stable Arti client that negotiates CGO automatically. The protocol is well-analyzed; the engineering integration is the part still in progress.

I2P: Heading toward 2.13.0 in August

The I2P development model is incremental with releases approximately every 13 weeks. The 2.13.0 target is August 2026, which means the work is currently in active development. Headline items:

• SSU2-PQ transport (proposal 169) — the first post-quantum protection at the I2P wire transport layer, distinct from the ratchet-layer PQ added in 2.11.0. This is the bigger fish: the transport is what every router-to-router packet uses, so PQ at this layer is a network-wide change.
• I2CP lookup support for LS service record parameters (proposal 167) — infrastructure for encrypted lease sets, which makes destination discovery metadata-private.
• Per-tunnel throttling and bandwidth parameters — capacity management that interacts with Sybil/spam defenses.
• Refactor Noise initialization — modernizing the cryptographic handshake code.
• Memory usage reduction for floodfills — operational efficiency.

The 2.12.0 release (April 20 2026) already shipped NTCP2-PQ transport and started on SSU2-PQ. The 2.13.0 release will likely complete the SSU2-PQ rollout. This is the most consequential I2P change since the ECIES migration of 2023 — and arguably more important, because it protects the wire transport from the harvest-now-decrypt-later threat that 2.11.0's ratchet-layer PQ does not.

The other notable I2P story: multiple new I2P router implementations are emerging — emissary in Rust and go-i2p in Go. The Java I2P router is the reference, but the ecosystem is becoming multi-implementation. This is good for resilience and bad for protocol-drift risk.

For ungovernable system design: I2P is the right choice for in-network services that need post-quantum metadata privacy today (waiting for SSU2-PQ to land in 2.13.0). For clearnet exit, Tor remains the choice.

Nym: The Bernstein/Bhargavan play

The Nym March 13 2026 roadmap is a striking document because it commits Nym to a specific cryptographic and engineering posture that is rare in the mixnet space:

1. Hand-optimized crypto by Daniel J. Bernstein. djb is the author of Curve25519, ChaCha20, Salsa20, and the Noise protocol framework. Nym hiring or contracting with djb for hand-optimized crypto is a signal that Nym is treating cryptography as a product feature, not a research concern.
2. Formally verified crypto by Karthik Bhargavan. Bhargavan is the author of the CryptoVerif tool and a long-time leader in formal verification of cryptographic protocols (he co-authored the Blanchet group's work and is at INRIA). Formally verified mixnet crypto is a step change in assurance.
3. New cover-traffic scheme from joint research with EPFL. The current Poisson-based cover traffic is optimized for email/messaging workloads. The new scheme is for "general internet use" and aims to be "more resistant to statistical attacks (including AI-powered) than any other VPN." This is a direct response to the MOCHA paper (ePrint 2025/861), which showed that message-anonymity-optimized mixnets can have dangerously low client anonymity.
4. Wallet-VPN merger. The $NYM token wallet will live inside the NymVPN app. This is productization, not protocol work, but it has privacy implications: the wallet becomes the identity for accessing the network, and stake-weighted node selection becomes a wallet-native action.
5. Customizable mixnet parameters in the NymVPN UI. Users will be able to choose cover-traffic, SURB, and other mixnet parameters via the GUI. This is the "anonymity vs speed" slider taken to its logical conclusion.
6. Split tunneling Fast ↔ Anonymous. Route specific apps through the mixnet (Signal, wallets) while keeping others on Fast mode. This is the most important UX change for adoption.
7. New pluggable transports including post-quantum obfuscation. Censorship resistance at the transport layer with PQ primitives.

The roadmap's stated user-base target is "from thousands to hundreds of thousands" in 2026. The mixnet side is the bottleneck — Halpin's own admission is that the mixnet is "simply too slow for everyday usage." Items 1-6 in the list above are all aimed at closing that gap.

The Nym token economy is also being overhauled: the current "finite mixmining pool" model creates sell pressure that the roadmap explicitly diagnoses and promises to fix with a "rational market" upgrade. This is partly economic, partly about aligning incentives for node operators.

For ungovernable system design: Nym is the right choice when (a) the user is willing to accept seconds of latency for metadata privacy, (b) the product needs to ship to non-technical users, and (c) the threat model includes a global passive adversary. Items 1-3 above, if they ship, will meaningfully strengthen Nym's position. Track the EPFL cover-traffic research and the Bernstein hand-optimized crypto as the two 2026 deliverables that matter most.

Katzenpost: Quiet week, durable architecture

No major Katzenpost release in the past seven days. The project remains the architectural reference for post-quantum federated mixnets, with the threat-model and literature-overview PDFs as the load-bearing primary sources. The KEM Sphinx work (twice-as-fast on the server side as the original NIKE Sphinx) is the most consequential technical contribution and remains the basis for new PQ mixnet designs.

For ungovernable system design: Katzenpost is what you read before designing a new mixnet. It is not a consumer product, but the documentation is the field's most careful statement of mixnet threat modeling.

HOPR: Quiet week, niche intact

HOPR's Coin Bureau review describes it accurately: "HOPR employs advanced encryption techniques and mixnets to ensure the privacy and anonymity of user data. The proof-of-relay mechanism incentivizes node operators to actively participate in relaying data. HOPR's SafeStaking mechanism ensures the security of node runner funds."

The "proof-of-relay + payment channel" model is the most distinctive feature. Whether it works economically at scale is an open question. The repo remains active, non-archived, and recently pushed. No headline change this week.

For ungovernable system design: HOPR is worth tracking but not yet a default. The incentive-market experiment is the interesting part, not the protocol itself.

Cross-cutting themes

The "Anonymous mode" line is the most important analytical line in 2026

The single sharpest distinction in the mixnet space is between systems that defend against a global passive adversary (GPA) and systems that do not. As of June 19 2026:

The trap that most commentary falls into is conflating "the system is named with a mixnet word" with "the system defends against a GPA." NymVPN Fast mode is not a mixnet. It is a decentralized VPN with PQ handshakes. Both are useful; only one is mixnet-grade.

Post-quantum migration is no longer hypothetical

The 2026 PQ landscape:

• Cloudflare reports (October 2025) that more than half of human-initiated web traffic on their network uses post-quantum key agreement.
• NIST 2035 deprecation deadline for RSA and ECC is firm.
• Nym's Lewes Protocol is live (optional) in NymVPN Fast mode — a Noise-based Post-Quantum Pre-Shared-Key protocol.
• Katzenpost's hybrid X25519+ML-KEM Sphinx is the architectural reference.
• I2P's ratchet-layer PQ shipped in 2.11.0 (Feb 2026). SSU2-PQ transport is targeted for 2.13.0 (August 2026).
• Outfox (SIGCOMM 2025) is the research direction for PQ layered-mixnet packet formats.
• Tor's CGO is classical-crypto faster, not PQ. Tor's PQ migration is in the proposal-discussion phase for the network, not the cells.

The mixnet-specific PQ challenge is fingerprinting: if PQ handshakes produce distinguishable packet sizes or timing, an adversary can use that to classify clients. Outfox addresses this with a simplified Sphinx variant designed for PQ from scratch. Nym's Lewes Protocol addresses it with a PSK + KEM combination that doesn't change the wire format of the underlying Noise handshake.

For ungovernable system design: harvest-now-decrypt-later is a real threat for traffic that needs to remain private for a decade or more. For 5-year-secrecy traffic, classical mixnets with classical Sphinx remain acceptable. For 30-year-secrecy traffic (journalism, dissident communications, financial sovereignty planning), PQ is the right bet.

The Rust-rewrite of the entire stack is happening in parallel

This is an underappreciated trend. The mixnet stack is being rewritten in Rust:

• Arti (Tor): client complete, relay + directory authority in development.
• Nym mixnet: Rust-native since launch.
• I2P emissary: a new Rust I2P router implementation.
• sphinxmixcrypto (Python) and sphinxcrypto (Rust): library-level rewriting of the packet format primitives.
• HOPR: Rust-native.

Java (the I2P reference), C (the Tor reference), and Go (the Katzenpost reference) are the legacy implementations. Rust is the new default. For freedom-tech builders, Rust is the right default language for new anonymity-network code — the memory-safety argument applies even more strongly to adversary-facing systems.

What to watch in the next 7-14 days

1. Arti 2.5.0 (likely late June 2026): Will it ship the directory authority role as the headline feature? The "Arc wrapping" change in the next release is the most disruptive API change yet.
2. Tor Browser 15.0.16 or 16.0a8 (likely): The v16 line is in alpha; expect a feature-freeze announcement soon.
3. Tails 7.9.1 (possible): The 7.9.0 release is fresh; an emergency may follow.
4. I2P 2.13.0 (August 2026, ~7 weeks out): SSU2-PQ transport completion is the headline.
5. Nym EPFL cover-traffic paper (expected 2026): The roadmap promises a new cover-traffic scheme; the academic paper is the primary source.
6. USENIX Security 2026 (August 2026): Expect new mixnet papers; check the program.
7. Tor CGO deployment timeline (no firm date): The tor-dev list is the live signal.

Evidence at a glance (June 13-19 2026)

Open research questions (updated)

1. How much cover traffic is enough? MOCHA says optimizing for message anonymity alone can give dangerously low client anonymity. The Nym/EPFL cover-traffic work is the response.
2. Can token incentives buy honest mixing without centralizing stake? Nym is overhauling its token economy in 2026. HOPR continues to test the alternative model.
3. How should mixnets expose APIs to apps? Arti as a library, NymSDK, SOCKS proxies, SAMv3 for I2P — the API surface is fragmenting.
4. Can post-quantum upgrades be deployed without new fingerprinting? Outfox is the research direction; Lewes Protocol is the production direction; I2P SSU2-PQ is the transport-layer direction.
5. What is the right user experience for strong anonymity? Split tunneling Fast ↔ Anonymous (Nym) is the most interesting 2026 UX experiment.
6. What is the realistic timeline for CGO network-wide deployment? Late 2026 or 2027 is plausible; no firm date.
7. Can formally-verified crypto make mixnets auditable in a way that builds trust? Bhargavan's involvement in Nym is the bet.

Primary sources (this week)

Releases and announcements

• Tor Project — Arti 2.4.0 (June 1 2026): https://blog.torproject.org/arti_2_4_0_released/
• Tor Project — Tor Browser 15.0.14 (May 19 2026): https://blog.torproject.org/new-release-tor-browser-15014/
• Tor Project — Tor Browser 15.0.15 (June 3 2026): https://blog.torproject.org/new-release-tor-browser-15015/
• Tor Project — Tor Browser 16.0a7 (June 3 2026): https://blog.torproject.org/new-alpha-release-tor-browser-160a7/
• Tor Project — Tails 7.8 (May 21 2026): https://blog.torproject.org/new-release-tails-7_8
• Tor Project — Tails 7.8.1 emergency (June 4 2026): https://blog.torproject.org/new-release-tails-7_8_1
• I2P — Development Roadmap (last updated 2026-05): https://i2p.net/en/get-involved/roadmap
• Nym — 2026 Roadmap (March 13 2026): https://nym.com/blog/nym-roadmap-2026
• Nym — Lewes Protocol launch (NymVPN v2026.7): https://nym.com/blog/lewes-protocol-post-quantum

Papers and analysis

• Degabriele, Karadžić. "Counter Galois Onion (CGO) for Tor: Fast Non-Malleable Onion Encryption." ePrint 2025/583: https://eprint.iacr.org/2025/583
• Rial, Piotrowska et al. "Outfox: a Postquantum Packet Format for Layered Mixnets." ACM SIGCOMM 2025: https://dl.acm.org/doi/full/10.1145/3733802.3764062
• Mahdi Rahimi. "MOCHA: Mixnet Optimization Considering Honest Client Anonymity." ePrint 2025/861 / IH&MMSEC 2025.
• Nym FOSDEM 2026 slides: https://fosdem.org/2026/events/attachments/U3UCKS-nym-mixnet/slides/267338/nym_fosd_x6ixavy.pdf
• Cloudflare — "Policy, privacy and post-quantum: anonymous credentials for everyone": https://blog.cloudflare.com/pq-anonymous-credentials
• Nym HOPE_16 talk (Aug 17 2025): https://www.youtube.com/watch?v=OCc5pIFJ7zY

Repositories and project pages

• Nym: https://github.com/nymtech/nym
• I2P Java: https://github.com/i2p/i2p.i2p
• I2P C++ (i2pd): https://github.com/PurpleI2P/i2pd
• I2P Rust (emissary): emerging — see https://i2p.net/en/blog
• Katzenpost: https://github.com/katzenpost/katzenpost
• HOPR: https://github.com/hoprnet/hoprnet
• Arti: https://gitlab.torproject.org/tpo/core/arti

Primary sources

• MOCHA: ePrint 2025/861