VeilNet
Gossip Mesh
There is no central server. Each node verifies its peers' post-quantum credentials independently, learns the state of the network through gossip with its neighbours, and relays traffic for others without being able to read it.
- Key exchange
- Identity
- Encryption
- Round trip, median
No gateway, vendor cloud or coordination server in the traffic path
Each generation of remote access addressed the limits of the last but kept a central component: a gateway, a vendor's cloud or a coordination server. Each concentrates risk in a single place. A VeilNet realm has no such component. Every node verifies admission against a signed credential chain, ML-KEM and ML-DSA are mandatory on every connection, and the realm runs entirely on your own infrastructure.
Tunnel into the network
- IPsec
- OpenVPN
- WireGuard
- Weak point
- An internet-facing gateway that exposes the entire network once breached.
- Sovereignty
- In-house.
- Post-quantum
- Retrofitted, where it exists.
Hide services behind a cloud
- cloudflared
- Twingate
- Weak point
- All connections route through the vendor's cloud, so an outage there is an outage for you.
- Sovereignty
- Leased. Identity and policy are held in the vendor's console.
- Post-quantum
- Retrofitted, where it exists.
Connect machines directly
- Tailscale
- NetBird
- ZeroTier
- Weak point
- A coordination server controls membership, and relay servers carry traffic that NAT blocks.
- Sovereignty
- Held by the vendor unless the control plane is self-hosted.
- Post-quantum
- Retrofitted, where it exists.
Remove the centre
- No central component to target. Any node can relay for others without access to the traffic it carries.
- Fully in-house, from the root of trust to every node.
- Required on every connection: ML-KEM-1024 and ML-DSA-87.
Products are placed by their core architecture. Self-hosting changes who runs the centre, not whether there is one.
Everything you run.
One post-quantum network.
VeilNet runs as software on the machines you already have. Virtual machines, containers, APIs and the devices on your sites join one network where every connection is post-quantum, and existing workloads run unchanged.
Servers and VMs as subnet routers
Today each site needs a local router and a VPN gateway. With VeilNet, one host on the site, bare metal or virtual, routes for the subnet behind it. The machines there install nothing and keep their addresses.
Today these links are protected by IPsec, IKEv2, RSA, DH, all vulnerable to a quantum computer. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
Containers across hosts
Containers on different hosts reach each other directly, with no Swarm or overlay network to run.
Today these links are protected by mTLS, IPsec, ECDHE, ECDSA, all vulnerable to a quantum computer. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
Clusters across clouds and regions
Today every cloud needs its own VPN gateway, a tunnel to every other region, route tables and pod ranges that never overlap. With VeilNet, clusters in different clouds and regions join one network, pod to pod.
Today these links are protected by IPsec, TLS 1.2, ECDHE, RSA, all vulnerable to a quantum computer. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
APIs with no public endpoint
Clients and partners reach the API directly, with no gateway on the internet. The API stays as it is.
Today these links are protected by TLS 1.3, X25519, ECDSA, all vulnerable to a quantum computer. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
High-performance database clusters
Today a cluster that spans regions needs a VPN gateway in each one, tunnels between them and a certificate on every node, and replication takes the long way round. With VeilNet, the database nodes link directly in one hop, and the database itself doesn't change.
Today these links are protected by TLS 1.2, RSA, ECDHE, all vulnerable to a quantum computer. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
Devices on remote sites
Today, getting remote devices to the cloud means adding a VPN gateway or exposing a public API. With VeilNet, the devices and the collector form the network themselves, relaying for each other through NAT with nothing exposed to the internet.
Today these links are protected by MQTT over TLS, ECDH, ECDSA, all vulnerable to a quantum computer. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
Industrial serial lines
VeilNet doesn't need an IP network. It runs over serial lines, so RTUs and PLCs get post-quantum protection without being replaced.
Today these serial links carry Modbus RTU and DNP3 with no IP network beneath them, so TLS and IPsec have nothing to run on. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
Field radio
VeilNet doesn't need an IP network. It runs over HF or VHF radio, so field radios get post-quantum protection without being replaced.
Today these radio links carry data with no IP network beneath them, so TLS and IPsec have nothing to run on. With VeilNet every link is protected by ML-KEM-1024, ML-DSA-87, AES-256-GCM.
Run by its nodes, with identities. No coordination server.
A VeilNet realm is run by its own nodes. Any node whose credential carries a capability can act on the rest of the realm, and every node checks the signed control against the root of trust before it acts. There is no server to host, rent or attack.
- An admin node with the block capability issues a block.
- It passes the block over its links.
- Link by link, it reaches every other node.
- Every node cuts off the blocked node.
Cut a lost or compromised node off from the whole realm in one action, without having to reach it. Lift the block at any time, or let it end on its own.
Isolate a suspect node in quarantine, or move it between environments, instantly and with no restart. It stays reachable for control wherever it goes.
Bring a site's networks onto the overlay, or take them off, remotely. The router keeps the change across restarts.
Check any node's status, routes and counters on demand, with no agent and no polling. Its peers and its traffic stay private.
Quantum resistance in less than a millisecond.
Every packet is encrypted end to end with AES-256-GCM, under keys agreed with hybrid ML-KEM-1024, a post-quantum key exchange. On a 16-vCPU test host, a round trip across the overlay takes 0.79 ms at the median, and one TCP stream runs at 92% of the most the host can encrypt.
Nine-tenths of the ceiling, direct or relayed
The ceiling is the most one core of the test host encrypts with AES-256-GCM, and the share counts every byte the cipher processes. Low-latency mode is tuned for latency, not throughput.
| Path | Share of ceiling |
|---|---|
| File transfer | 93.3% |
| Direct, one TCP stream | 91.6% |
| Through two NATs, hole-punched | 90.9% |
| Through one relay | 90.0% |
| Direct, four TCP streams | 89.8% |
| Forwarded host traffic | 77–78% |
| Low-latency mode | 61.5% |
A relay adds about a third of a millisecond
Ping round trips, including the kernel's routing into and out of the overlay on both hosts. Low-latency mode sends frames as QUIC datagrams.
| Path | p50 | p90 | p99 |
|---|---|---|---|
| Direct | 0.79 | 1.12 | 1.43 |
| Low-latency mode | 0.75 | 1.01 | 1.25 |
| Through one relay | 1.1 | 1.56 | 1.96 |
| Path | Cold | Warm |
|---|---|---|
| Direct | 0.489 | 0.329 |
| Low-latency mode | 0.433 | 0.291 |
| Through one relay | 0.650 | 0.463 |
End-to-end encryption is about 5% of the latency
anchor's own work along the path, translation, switching, queueing and end-to-end encryption, is about 0.015 ms of CPU per packet. The rest is QUIC, system calls and threads waking up.
| Stage | Cold | Warm |
|---|---|---|
| QUIC, kernel UDP and the network | 0.226 | 0.162 |
| Network stack and address translation | 0.123 | 0.071 |
| Hand-offs inside anchor | 0.064 | 0.060 |
| TUN write | 0.048 | 0.018 |
| End-to-end encryption | 0.026 | 0.020 |
| Virtual switch and queues | 0.007 | 0.004 |
Each peer pair gets a core of its own
More streams between the same two anchors add nothing, because one pair's traffic passes through one encryption pipeline. Separate pairs run on separate cores.
| Case | Share of one core's ceiling |
|---|---|
| One peer pair | 92% |
| One anchor, two peers | 147% |
| Three pairs at once | about 200% |
Test setup. Measured in September 2026 on one 16-vCPU QEMU virtual machine running Linux 7.0, with AES-NI and no PCLMULQDQ, so AES-GCM's GHASH runs in software. Sixteen anchors ran in Docker containers on seven bridge networks, behind three NAT translators (one symmetric) and two relays, at anchor commit 4965e6e9 in its default configuration.
Measure it on your own hosts
The pre-release runs on Linux, Windows, macOS and BSD. Put two machines on it and capture the traffic between them with your own tools.