FastSox 2026 Roadmap: QUIC Transport, Post-Quantum Keys, and the Mesh Architecture

FastSox started as a simple WireGuard wrapper with smarter server selection. Over three years it grew into a global edge network processing millions of sessions daily. This post covers where we've been, what we learned, and the three big bets that define our 2026 roadmap.

Development Journey

2023 — Starting Point

The first version of FastSox was embarrassingly simple: a WireGuard config generator with a REST API that picked the geographically nearest server. The team was three people. Infrastructure was four bare-metal boxes in three datacentres.

What that version got right: zero logging from day one. We decided early that not storing data was easier than securing stored data. Every architectural decision since has been shaped by that constraint.

What it got wrong: static server selection. Users in Seoul connecting to the Tokyo node were often better served by Singapore because of peering agreements between their ISP and our upstream. Geography is a bad proxy for latency.

2024 — The AI Routing Layer

We replaced geographic routing with the ML model described in our architecture post. The rollout taught us two things:

1. A/B testing network routing is hard. You can't randomly assign users to routing strategies and then compare their experience — too many confounders. We ended up using per-user session interleaving: odd sessions use the ML model, even sessions use geo-routing, compared within the same user.

2. Model freshness matters more than model complexity. A simple gradient-boosted tree retrained daily beats a deep model retrained weekly. Congestion patterns change faster than model architecture can compensate.

2025 — Scale and Protocol Diversity

By mid-2025 we had 1,000+ edge nodes across 65 countries. The operational burden of managing that many WireGuard peers manually was unsustainable, so we built a control-plane-as-code layer: every node's allowed-peers list is computed from a central state store and pushed via gRPC in under 2 seconds.

We also added IKEv2 as a fallback for corporate networks that block UDP 51820. This was harder than expected — IKEv2 session state has to be kept in sync across multiple control-plane replicas, and NAT traversal behaviour differs significantly between carriers.

2026 Roadmap

Q1 2026: QUIC Transport Layer (In Progress)

WireGuard over UDP works well, but UDP is blocked or throttled on a non-trivial number of networks (hotel WiFi, some enterprise firewalls, certain mobile carriers in Southeast Asia). Our current workaround is TCP encapsulation, which adds overhead and breaks our latency targets.

QUIC solves this cleanly: it runs over UDP but looks like HTTPS traffic on port 443, so it passes through almost every firewall. More importantly, QUIC's connection migration lets a session survive an IP address change (WiFi → LTE) without re-handshaking.

What we're building:

• A QUIC-based transport adapter that sits between the WireGuard kernel module and the IP stack
• Multiplexed streams so a single QUIC connection carries both control messages and data
• Connection migration support for mobile clients

Target: production rollout to 10% of iOS users by end of Q1 2026.

Q2 2026: Post-Quantum Key Exchange

The current WireGuard handshake uses Curve25519 for key exchange. This is secure against classical computers but vulnerable to a sufficiently powerful quantum computer running Shor's algorithm. Harvest-now-decrypt-later attacks are a real concern for sensitive data.

We're integrating ML-KEM-768 (formerly Kyber-768, now standardised as NIST FIPS 203) as a hybrid alongside Curve25519:

Final session key = HKDF(
    X25519(ephemeral_client, ephemeral_server)  // classical
 || ML-KEM-768.Decapsulate(ciphertext, server_sk) // post-quantum
)

The hybrid approach means security is maintained if either algorithm is broken. The ML-KEM public key adds ~1.2KB to the handshake — acceptable on mobile.

Rollout plan: opt-in beta in Q2, default-on for all new sessions in Q3.

Q3 2026: Mesh Architecture

Today FastSox is a hub-and-spoke model: every client connects to one of our edge nodes, which then connects to the destination. This is simple to operate but creates an unnecessary hop for clients who are geographically close to each other.

The mesh architecture will let FastSox clients form direct encrypted tunnels to each other when both endpoints are FastSox users — relevant for:

• Remote teams sharing files or accessing a self-hosted service
• Site-to-site connectivity for small businesses
• Developers who want a private overlay network without running their own VPN server

Implementation uses a distributed peer exchange (similar to BitTorrent's DHT): the control plane introduces two peers and they negotiate a direct WireGuard tunnel. If direct connectivity fails (strict CGNAT), it falls back to relay through the nearest shared edge node.

Target: private beta for Teams plan users in Q3 2026.

Q4 2026: Programmable Network Policies

Enterprise customers keep asking for policy enforcement at the network level: "block traffic to category X for users in group Y between hours A and B." Today this requires client-side configuration that users can bypass.

In Q4 we'll move policy enforcement to the edge node level using eBPF:

# Example policy (declarative YAML, pushed via API)
policies:
  - name: no-social-media-during-work-hours
    match:
      group: employees
      schedule: "Mon-Fri 09:00-18:00 Europe/London"
      destination_category: social_media
    action: block
    log: true

Categories are determined by SNI for TLS traffic and IP-to-category lookup tables maintained by our threat intelligence feed.

Commitments and Non-Commitments

We will not:

• Add advertising to the free tier
• Sell or share user metadata
• Introduce mandatory account creation for basic usage

We will:

• Maintain the zero-log architecture as an invariant, not a feature
• Publish the full source of the client applications (already done for iOS and Android)
• Complete a third-party security audit before shipping the mesh architecture

Our next scheduled independent security audit is September 2026. Results will be published in full at fastsox.com/security.

Questions about the roadmap? Open a discussion on our GitHub or reach out at hello@fastsox.com.