An encrypted tunnel, not a proxy
The app creates a virtual network adapter and routes your traffic through it. Each packet is encrypted with ChaCha20-Poly1305 under keys agreed in a one-round-trip Noise IK handshake, so a new tunnel is up in a single exchange. Keys are replaced every two minutes without dropping the connection.
Credentials that carry no identity
When you connect, the app presents a signed credential. It contains a validity window, a tier, sixteen random bytes, and a signature. There is no account number, no email, no name — not hidden, absent. The server verifies it on its own and never asks who is connecting, because there is nothing to ask with. The random bytes mean no two credentials are ever identical, so nothing can be matched by comparing them.
Isolated from other users
Any packet a client sends towards another address inside the tunnel network is dropped before it reaches the operating system, then dropped again by a firewall rule in case the first barrier is ever wrong. Source addresses are checked against the lease, so a client cannot pretend to be another.
The tunnel keeps running
The servers that carry traffic hold everything they need to keep a session going. If sign-in is down, existing tunnels carry on. Closing the window leaves the tunnel up — quitting says so — and the background service owns the connection, not the interface.
Full tunnel or split tunnel
The default is everything. Turn "Route all traffic" off and only traffic addressed to the tunnel network goes through it; the rest uses your normal connection. Changing it reconnects, so the routing table is never half-applied.
Selection is by destination today; choosing per application is on the roadmap.
IPv6: carried or blocked, never leaked
A VPN that silently leaks is worse than one that visibly disconnects. Locations with IPv6 carry it: you get a private v6 address behind the gateway’s shared one, with the same client isolation as v4. Under a full tunnel the app refuses to run in any state where IPv6 is neither carried nor blocked.
Hard to knock over
Every handshake message carries a MAC that only a client who knows the gateway’s public key can compute — checking it costs about five hundred times less than the key exchange it protects. Under load the gateway hands out short-lived cookies bound to your address and requires them on the next attempt. Nothing it sends back is larger than what it received, so it cannot be used to amplify an attack on someone else.
Two-factor authentication
Time-based one-time codes from any authenticator app. Enrolment is two steps, so a secret that has never been proved never protects the account. Ten single-use recovery codes are issued once, and disabling the factor requires a code.
Your password never enters the app
Press Sign in and the app opens the account site in your browser, where you sign in as usual — second factor included. You approve the connection there, with the app’s name and platform shown, and the app receives its own session over a one-time code. No password field in the app means no password for it to mishandle, and a sign-in page in a real browser is one your password manager already knows.
All your devices
Each app you sign in gets its own session. End one from that app, or end all of them at once from the portal — changing your password does the same. We do not limit how many.
Card details we never see
The card form is served by the payment processor and the browser confirms the payment with them directly. We hold the last four digits and the expiry for display, and nothing else.
Paying with cryptocurrency is planned but not built.
DNS that never meets a third party
Each location runs its own resolver on its tunnel address, and the app is told about it in the handshake. Your queries travel inside the tunnel, are resolved recursively from the root — not handed to any third-party DNS provider — and leave the node mixed with everyone else’s. No query is logged or retained. With blocking off, the part of the gateway that carries DNS interprets not one byte of it; switch blocking on, and it reads exactly one thing — the name being asked — and still records nothing.
The Linux app still uses the machine’s own resolver; it follows.
Ads, trackers and malware, stopped at the resolver
The tunnel’s own resolver keeps a second address that answers “no such domain” for names on well-studied public blocklists and resolves everything else exactly as before. It is domain-level blocking, honestly framed: it will not catch every ad, and an app that ships its own encrypted DNS can sidestep it. What it never does is log, retain or count your queries — filter, forward, forget. Off by default; applies instantly when you flip it.
Part of the Plus plan.
A kill switch that holds
On Windows it is a default-deny rule in the system firewall, not a promise kept by a running program: only the tunnel, the path to the gateway, loopback and DHCP may send. It is armed before the tunnel comes up and holds through a crash or a reboot until you disconnect on purpose. On iOS it has two levels: the system re-establishes the tunnel on its own, and a strict mode where nothing leaves the device unless the tunnel carries it. Either way, a tunnel that dies is reconnected automatically — nothing leaks while it happens.
On Windows and iOS, under “Route all traffic”. Off by default — a dropped connection blocking everything is a trade-off you choose, not one we choose for you. Linux and macOS follow.
Split-trust routing
Your tunnel runs to an exit through an entry node that only relays it. The entry sees your network address and which exit you chose — never a destination, never content, because what it relays is ciphertext it cannot open. The exit sees destinations — never your address, only the entry’s. The app always pairs an entry and exit from different hosting companies on different networks, and if no independent pair is available it says so rather than quietly running a single hop. Part of the Plus plan.