Mystic: our own VPN protocol, how it differs and why it stays closed for three years

We are building Mystic, our own VPN protocol and a reusable Rust core for the VPN products we develop. On October 21, 2026 we finished the specification: requirements, wire format, architecture, threat model and a test plan. The next step is implementation.

This is an announcement of an experimental protocol, not of a finished product. There are no benchmarks yet, and we deliberately make no claims about speed or availability that we haven't measured. Below we explain why we need our own protocol, how it is designed, how it differs from existing protocols, why we will use it in our products and why the source code will stay closed for at least three years.

Why we need our own protocol

Our VPN apps currently rely on existing engines. They are good engines, but each was built for its own conditions: some are fast UDP tunnels, others carry traffic over TLS or QUIC, and some are proxies rather than full network tunnels. A product that has to work across very different networks ends up combining several of them, each with its own configuration, lifecycle and failure modes.

We want one core that we own. It should keep a single connection alive while the network changes, spend extra traffic only when needed and within a known budget, plug into our existing backend and run in every product we build, from a Linux server to mobile apps.

What Mystic is

Mystic is a full L3 tunnel: it carries IPv4 and IPv6 traffic of the whole device, with DNS inside the tunnel. If the tunnel fails, the client blocks direct traffic, including IPv6 and DNS, instead of quietly leaking it.

The main design decisions:

• ✦Standard cryptography. The handshake is Noise IK, from the same Noise framework WireGuard is built on. The transports use regular TLS 1.3 and QUIC. We do not invent ciphers.
• ✦Three real transports. Plain UDP for speed, HTTP/3 over QUIC and HTTP/2 over TLS 1.3. These are genuine protocol implementations, not imitations of their headers.
• ✦One logical session. When a path degrades, the connection moves to another transport. The session and the user's IP address inside the tunnel stay the same, and each path has its own keys.
• ✦Adaptive modes. The light mode runs by default and aims to stay close to WireGuard speed. The shaped and heavy modes turn on when the network gets worse.
• ✦Traffic shaping from real recordings. In the stronger modes, packet sizes and timing follow statistical profiles recorded from real traffic. Profiles are signed, and only verified ones are accepted.
• ✦A hard budget for extra traffic. Padding and cover traffic may add at most 10% to the useful bytes in each direction over a session. Cover traffic is sent only inside the authenticated tunnel and never to third-party services.
• ✦Operator control. Each node keeps its own list of users. Disabling or deleting a user is designed to stop all of their connections on every transport within one second, and a temporary backend outage doesn't disconnect users who already have access.
• ✦A portable core. The Rust core doesn't depend on TUN devices, the database, the HTTP API or Linux system calls. The same code is meant to run on Linux now and inside iOS and Android apps later.

How Mystic differs from existing protocols

Most building blocks in Mystic already exist somewhere. Multiple transports, padding and real HTTP stacks are not new, and we don't claim to have invented any of them. What is new is the combination: one L3 session across several transports, an adaptive controller with a measurable cost and an SDK we control.

We will compare Mystic with these protocols on the same hardware, with fixed versions and settings. We plan to publish the methodology together with the results, including the cases where Mystic loses.

What we promise and what we don't

For the first private beta we set measurable targets:

• ✦in the light mode, at least 80% of the throughput of userspace WireGuard on the same machine;
• ✦no more than 5 ms of added latency at the 95th percentile;
• ✦no more than 10% of extra traffic from padding and cover;
• ✦access revocation within one second.

These are acceptance targets, not results. If the prototype doesn't reach them, we keep the existing protocols in our apps and don't move users to Mystic.

Just as important is what Mystic does not promise. It is not undetectable: real TLS and QUIC and careful shaping make traffic analysis harder, but they don't make it impossible, and we will measure this risk on data the system wasn't tuned on. It can't help if the server's IP address is blocked on every transport. It is not an anonymity tool: like any single-hop VPN, the node sees your traffic as it leaves the tunnel. What we can promise is minimal logging: the node doesn't record destination addresses or traffic content, metrics carry no per-user labels, and operational logs are kept for seven days.

Why we will use it in our products

• ✦One core for every app. We stop maintaining separate integrations of other engines and get one session lifecycle across Linux, iOS and Android.
• ✦Our own wire format and SDK. We decide when and how the protocol changes and don't wait for someone else's roadmap.
• ✦A controlled cost. Extra traffic is always within a known budget, so we can plan server capacity and costs.
• ✦Integration without rewrites. Mystic connects to our existing backend through a management API. Billing and accounts stay where they are.
• ✦Fast access control. Revocation and key rotation are part of the protocol, not an afterthought.

The rollout will be gradual and opt-in. The first users will get Mystic only after an independent security review, and the existing protocols will remain in our apps as an alternative.

Why the code stays closed for at least three years

We won't publish the Mystic source code for at least three years, so not before October 2029. Whether we publish it after that will depend on how mature the protocol is.

It is important to be precise about why. Closed code doesn't protect users. Their security rests on standard cryptography and on an independent review, and the risk of traffic analysis is reduced by design and measurements, not by hiding the code. Our reasons are practical:

• ✦The wire format will change. Version 1 is experimental, and the independent review may require changes. Publishing it now would invite third-party implementations of a format we plan to break.
• ✦Review before reuse. We don't want other projects to build on a protocol that hasn't passed an external cryptographic review and real measurements yet.
• ✦Focus. We are a small studio. Supporting an open protocol means issues, compatibility and community work, and right now that time belongs to the product.
• ✦It is built for our products first. The core, the API and the operator tools are designed around our backend and our apps.

Meanwhile we plan to write here about the progress and share measurement results when we have them.

What comes next

The plan has five stages. The first is a reproducible build and the contracts. The second is an encrypted UDP tunnel with replay protection. The third adds HTTP/3 and HTTP/2, session migration and instant revocation. The fourth brings the recorded traffic profiles and budgets. The fifth covers benchmarks, fuzzing, failure recovery and an independent security review, ending in a decision on a private beta. Our estimate is 12 to 16 engineering weeks plus the external review. We don't name a release date: some of the work is research, and the review may change the protocol.

The first release targets a Linux server and a command-line client. iOS and Android apps on the same core will follow in a separate release.