2.0 QLEAP VPN
Three hops. Zero memory.
Built as a three-hop onion of post-quantum-keyed tunnels with operator-owned exits, post-quantum DNS, and a killswitch that fails closed. Once the relays run distributed, no single hop will see both ends of your connection; in the single-site relay mode every layer key is registered with the relay, so hop separation is a deployment property, not a structural one.
Arrives in a later update, after the messenger.
- IN DEVELOPMENT
- FIPS 203
- FIPS 204
- CNSA 2.0 — asymmetric core conformant (R-1 scoping)
- Per-hop KEM ML-KEM-1024
- Layer AEAD ChaCha20-Poly1305
- Hop keys HKDF · QLEAP-HOP-v1
- Directory signatures ML-DSA-87
Ride the pulse. Three hops, one circuit.
-
Hop 1/3 · Entry — outer layer
The entry sees you. Never your destination.
Your packet arrives wearing three encryption layers. The entry relay peels the outer one — keyed by its own fresh ML-KEM-1024 encapsulation — and learns exactly one thing: the next relay.
-
Hop 2/3 · Relay — middle layer
The middle sees neither end.
It takes ciphertext from a relay and hands ciphertext to a relay. Who you are and where you are going stay sealed inside layers it cannot open.
-
Hop 3/3 · Exit — final layer
The exit sees your destination. Never you.
The final layer peels and your traffic leaves through an operator-owned exit listed in the signed directory. The only address it can name upstream is a relay.
-
Delivered
Every shell flash was a layer peeling.
Three ChaCha20-Poly1305 layers, each keyed by a fresh ML-KEM-1024 encapsulation, each removed at exactly one hop, so no hop holds the key to the layer before or after its own. The layering is identical in every deployment; whether it also separates machines, so that none of them sees both you and your destination, depends on the relays running as a distributed fabric rather than one process.
The circuit, lettered.
┌─────────┐ ┌─────────┐ ┌─────────┐
you ────▶ │ ENTRY │ ───▶ │ RELAY │ ───▶ │ EXIT │ ───▶ destination
└─────────┘ └─────────┘ └─────────┘
layers 3 ▸ 2 2 ▸ 1 1 ▸ 0
sees you neither end destination
blind to your destination both ends you
The per-hop wrap
Every packet is wrapped three to seven times before it leaves your device. Each layer is a fresh ML-KEM-1024 encapsulation fed through HKDF under the QLEAP-HOP-v1 context into a ChaCha20-Poly1305 seal, with the hop index, frame type, and size bound as associated data. Forward secrecy holds across hops: a recorded ciphertext cannot be replayed into the circuit later.
- Layers
- 3 minimum · 7 maximum
- Re-key
- every 2 hops along the circuit
- KEM
- ML-KEM-1024 (FIPS 203)
- Key schedule
- HKDF · ctx QLEAP-HOP-v1
- AEAD
- ChaCha20-Poly1305 (RFC 8439)
- AAD
- hop index + frame type + size
- Replay guard
- bounded LRU of (hop id, nonce)
The signed directory
Your device builds circuits only from relays it can verify. The relay list is signed with ML-DSA-87 under the FIPS 204 context QERYX-QLEAP-DIRECTORY-v1; your device checks it against a pinned operator key, a generation counter that only counts up, and a 24-hour signing window. An impersonated relay, a replayed list, and a stale list all fail the same check. Each relay additionally attests its own keys and self-tests on key load.
- Signature
- ML-DSA-87 (FIPS 204)
- Context
- QERYX-QLEAP-DIRECTORY-v1
- Trust root
- pinned operator key
- Freshness
- monotonic generation + ±24 h signing window
- Per-relay
- attestation ctx QERYX-QLEAP-RELAY-ATTEST-v1
Continent-diverse circuits
Circuit selection scores the relay set 0 to 100 for geographic diversity and prunes candidates that stack the same network or the same continent, so a circuit’s hops answer to different jurisdictions and different backbones.
Leak protection
The tunnel carries all traffic. DNS resolves inside it, IPv6 is closed at the tunnel boundary, and killswitch and split-tunnel are mutually exclusive — the configuration that would leak cannot be expressed. When the tunnel drops, the killswitch fails closed: traffic stops rather than escapes.
Zero memory, grounded
Zero memory is a claim about state. Relays hold no connection state past the flow they carry; the directory lists relays and holds no record of you; the replay cache is a bounded LRU of (hop id, nonce) — a filter, never a log.
The adversary we do not defeat
A global passive adversary — one that can watch timing on every hop at once — can attempt end-to-end correlation. Three to seven hops raise that cost sharply against typical adversaries; constant-rate cover traffic for bulk flows is future work, and we say so here rather than let the globe imply it.
Four threat models, one dial.
Pick the adversary you expect. NOMAD rides three hops and rotates its circuit every thirty minutes; OPERATOR rides seven and rotates every five. Longer circuits trade latency for unlinkability — you choose per session, and the killswitch holds either way.
Each hop peels exactly one layer, and never the one below it.
Measured, footnoted, device-scoped.
3 ms1
full three-hop post-quantum circuit handshake
~600 ns1
per-packet three-layer onion wrap
84 B1
per-packet layered-tag overhead
42
relays in the signed directory, across 2 circuits
1 — MEASURED ON PHONE-CLASS HARDWARE; METHOD AND RAW RUNS AT /TRUST METHODOLOGY. 2 — THE FLEET AS LISTED IN THE ML-DSA-87-SIGNED DIRECTORY. RELAY STATUS AND LATENCY ARE PUBLISHED ONLY ONCE THEY CAN BE PUBLISHED TRUE — UNTIL THEN THEY ARE ABSENT, NEVER ESTIMATED.
| Parameter | Value |
|---|---|
| Hops per circuit | 3 - 7 |
| Re-key cadence | every 2 hops |
| Per-hop KEM | ML-KEM-1024 (FIPS 203) |
| Hop key derivation | HKDF - ctx QLEAP-HOP-v1 |
| Layer AEAD | ChaCha20-Poly1305 (RFC 8439) |
| Directory signature | ML-DSA-87 (FIPS 204) - ctx QERYX-QLEAP-DIRECTORY-v1 |
| Relay attestation | ctx QERYX-QLEAP-RELAY-ATTEST-v1 |
| Replay guard | bounded LRU (hop id, nonce) |
It carries the rest of the stack.
Messenger
Messages are sealed end-to-end before QLEAP ever sees them. Through the tunnel, the message relay sees an exit — never your address.
QMail
Sealed mail through the same three hops. The portal your recipient opens sees a QLEAP exit, never your address.
HydraSIM
When a bearer dies and the path swaps under you, the killswitch holds closed across the swap — traffic waits, never leaks.
How it compares.
| QERYX QLEAP | Single-hop VPN class | No VPN | |
|---|---|---|---|
| Compromise and seizure | |||
| One relay compromised | One hop of ciphertext — at most one end of the connection | All traffic — one hop is the whole tunnel | No relay exists; every network on the path watches |
| Infrastructure subpoenaed | Routing metadata per hop; no content, no endpoint pairings | Full connection logs, wherever they were kept | Carrier records: who, when, from where |
| Recorded today, decrypted later | Fresh ML-KEM-1024 per hop | Classical tunnel — readable once the math falls | Already plaintext to the path |
| Failure and hostility | |||
| Operator turns hostile | Signed directory + pinned key: substitution is detected | Trust is policy only | No operator to trust |
| Tunnel drops mid-session | Fails closed — traffic stops, never leaks | Often fails open | Nothing to fail |
The hard questions.
What does a subpoena of hop 2 yield?
Ciphertext and routing metadata for the flows that relay carried — never both endpoints of a connection, and never content. Hop 2 is the strictest case: it receives from a relay and hands to a relay, and it holds no connection state past the flow. The box arrives with no pairings inside it.
Does any hop see who I am and where I go?
No. The entry knows you and not your destination; the exit knows your destination and not you; the middle knows neither. That separation is structural — it does not depend on a promise.
Who runs the exits?
The operator. Every relay — entry, middle, exit — is listed in an ML-DSA-87-signed directory your device verifies against a pinned key before it builds a circuit.
What will happen when the tunnel drops?
The killswitch will fail closed: traffic stops rather than leaks. DNS rides inside the tunnel, so a drop cannot spill your lookups either.
What does QLEAP not defend against?
A global passive adversary correlating timing across all hops at once. Three to seven hops raise the cost sharply against typical adversaries; constant-rate cover traffic for bulk flows is future work, and we say so.
Is this a volunteer onion overlay?
It is an operator-run three-hop onion with post-quantum hop keys and a signed directory — an architecture class, verified per relay, not a volunteer overlay. You get fewer relays than a volunteer network, and a verification story for every one of them.
Why can't the operator swap in a malicious relay list?
A new list must verify under the key your device pinned, carry a higher generation number, and sit inside a 24-hour signing window. A rotated key hard-fails until you deliberately reset trust — substitution is detected, never silent.
What does the CNSA 2.0 badge mean?
CNSA 2.0 — asymmetric core conformant (ML-KEM-1024 + ML-DSA-87 at Category V; SHA-512 at or above the hash floor). The AEAD is ChaCha20-Poly1305 (RFC 8439), a documented deviation; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002. Pre-evaluation checklist (internal self-assessment against the NIAP Common Criteria bar, latest pass 2026-06): 0 algorithm-layer non-conformances, 5 documented deviations; no accredited-laboratory evaluation has begun.