Velnx Protocol

Velnx is a decentralized, anonymous transport-layer privacy protocol. It replaces the single-operator VPN model with a permissionless mesh of independent relays connected by onion-encrypted WireGuard tunnels, settling bandwidth payments in the native KLX token. The design eliminates the trust assumption inherent to commercial VPN providers: no single party in the path observes both the user's identity and their destination. Velnx targets sub-30ms median added latency, making strong privacy operationally viable for interactive use.

Conventional VPN services are a single trust anchor. The provider terminates all user tunnels, observes plaintext destination metadata, and operates the billing system that links payment identity to IP allocation. Any compromise — legal, operational, or commercial — collapses the privacy guarantee in full.

Log-retention pressure is structural. Providers domiciled in jurisdictions with mandatory data-retention statutes, mutual legal assistance treaties, or undisclosed national security orders cannot credibly promise non-retention. "No-logs" audits capture a moment in time, not a guarantee against future coercion.

The same operator runs ingress and egress. A single subpoena, warrant, or insider correlates source to destination trivially. Traffic analysis against a single-hop tunnel reduces to bookkeeping.

Finally, payment is the weak link. Card processors, PayPal, and most fiat rails bind the subscription to a legal identity. Even a perfectly operated VPN leaks identity through its billing relationship.

A Velnx session traverses at least three independent operators selected by the client: an entry node, one or more relays, and an exit node. Each hop terminates one layer of encryption. No single operator possesses both the user's source address and the final destination address simultaneously.

Nodes register on a public directory authority maintained by stake-weighted consensus among KLX holders. The client downloads a signed consensus document, filters by latency and reputation, and constructs paths locally. There is no central dispatcher.

Encryption is layered. The client establishes pairwise WireGuard sessions with each hop via X25519 ephemeral key exchange. Each outbound packet is wrapped n times; each hop strips exactly one layer and forwards the remainder. The exit node decrypts the innermost layer and emits the cleartext payload to the public Internet.

   [client] --L1+L2+L3--> [entry] --L2+L3--> [relay] --L3--> [exit] --> Internet
                              \                \                \
                          knows: client     knows: entry      knows: relay
                                                              + destination

No operator learns the full path. The entry sees the client but not the destination; the exit sees the destination but not the client; the relay sees neither endpoint, only its two neighbors. This is the standard onion-routing invariant, applied over WireGuard's transport.

Naiad is the wire protocol that carries Velnx traffic. It combines QUIC/UDP transport, TLS-1.3 handshake disguise, multi-hop onion encryption, and browser-fingerprint mimicry into a single layered stack — defeating active probing, DPI classification, and traffic correlation simultaneously.

The current generation of censorship-resistant transports converges on two design families: QUIC-based UDP protocols (Hysteria 2, Brutal CC) solve performance on lossy links; TLS-disguise protocols (REALITY, Trojan, NaiveProxy) solve active probing and DPI. Each family is strong in its lane, but no deployed transport combines (i) loss-tolerant UDP performance, (ii) active-probing resistance, and (iii) multi-hop onion anonymity. Naiad fills the gap.

3.1 Transport — QUIC + Brutal CC

The wire transport is QUIC (RFC 9000) over UDP. QUIC is chosen over TCP for three reasons: native multiplexing eliminates head-of-line blocking across the onion's nested streams; 0-RTT resumption masks the rekey cost of frequent path rotation; and the connection ID decouples the cryptographic session from any 5-tuple, allowing seamless migration across NAT rebindings and mobile handoffs.

Congestion control is a Brutal-derived rate controller on the outermost (client-to-entry) hop only. The client declares an upstream and downstream budget; the controller paces to that budget and treats loss as adversarial. Inter-relay hops retain BBRv2 (§7), since relay-to-relay links are high-quality backbones where loss does signal congestion. The two regimes are negotiated per-hop.

3.2 Handshake disguise — REALITY-style SNI sponging

Each Naiad listener is paired with a public cover host — a high-traffic TLS site whose CDN edge serves a real certificate (e.g. www.cloudflare.com, cdn.jsdelivr.net). On inbound connection, the relay performs a TLS 1.3 handshake on behalf of the cover host: ClientHello is forwarded to the cover, the genuine ServerHello and certificate are returned, the handshake completes against the real CA chain. Inside the encrypted handshake, the client presents an X25519 authenticator derived from the relay's public key and a session nonce. If it verifies, the post-handshake stream enters the Naiad data plane; if not, the relay proxies the bytes to the genuine cover host and the client receives that site's real content.

The censor's view: an indistinguishable TLS 1.3 session to a major CDN, terminating with a valid certificate from a public CA. Active probing of the relay's IP returns the cover site verbatim. No proxy-specific fingerprint at any byte of the handshake.

3.3 Onion encryption — ChaCha20-Poly1305 / X25519

Once the outer TLS session is established, the inner data plane is the WireGuard-baseline cryptographic construction: pairwise X25519 between the client and each of the N hops, ChaCha20-Poly1305 AEAD, N nested layers per outbound packet. Each hop strips exactly one layer; session keys rotate on the WireGuard schedule (120 s or 2^60 frames).

The onion is layered inside the QUIC stream. The outer TLS session terminates at the entry node; the entry decrypts one layer and re-tunnels the remainder over a fresh Naiad session — TLS-mimic and all — to the next hop. Each hop is its own indistinguishable HTTPS conversation.

3.4 Obfuscation — uTLS and optional padding

The ClientHello is synthesized by a uTLS-equivalent library. Fingerprint profiles ship for current and previous stable Chrome, Firefox, Safari, and Edge; the active profile is selected per-session to match the host OS's expected browser. Extension order, GREASE values, ALPS, and post-quantum key share (X25519-Kyber768) are reproduced verbatim. The profile catalog updates out-of-band.

Optional record padding adds random-length suffix bytes to a tunable fraction of outbound records, defeating size-based classification. Off by default (it costs throughput); enabled by a single flag on classified networks.

3.5 Failover and fragmentation resistance

Each client maintains 3–5 candidate entry nodes warmed with 0-RTT tickets. On (i) handshake failure, (ii) consecutive loss above threshold while upstream budget is unfilled, or (iii) latency above the path's rolling p95, the client migrates within one RTT via QUIC connection migration. Mid-circuit failover at relay or exit hops is handled by the same mechanism one layer in.

Path MTU is discovered per hop with DPLPMTUD (RFC 8899); the smallest hop MTU governs the circuit. Naiad never sets DF unconditionally — fragments are tolerated and reassembled in the QUIC layer to survive middleboxes that mangle IP fragments.

Layered packet structure

+-----------------------------------------------------------+
| IP / UDP                                                  |  ← public network
+-----------------------------------------------------------+
| QUIC long header  (cover-host SNI in ClientHello)         |  ← REALITY mimic
| +-------------------------------------------------------+ |
| | TLS 1.3 record  (uTLS Chrome fingerprint)             | |  ← §3.4
| | +---------------------------------------------------+ | |
| | | Naiad authenticator  (X25519 PSK proof)           | | |  ← §3.2
| | +---------------------------------------------------+ | |
| | | Onion L1  =  ChaCha20-Poly1305 ( client → entry ) | | |  ← §3.3
| | | +-----------------------------------------------+ | | |
| | | | Onion L2  =  ChaCha20-Poly1305 ( … → relay )  | | | |
| | | | +-------------------------------------------+ | | | |
| | | | | Onion L3  =  ChaCha20-Poly1305 ( … → exit)| | | | |
| | | | | +---------------------------------------+ | | | | |
| | | | | | Application payload (HTTP, DNS, etc.) | | | | | |
| | | | | +---------------------------------------+ | | | | |
| | | | +-------------------------------------------+ | | | |
| | | +-----------------------------------------------+ | | |
| | +---------------------------------------------------+ | |
| +-------------------------------------------------------+ |
+-----------------------------------------------------------+

Why this stack

KLX is the protocol's native token. Fixed supply of 1 billion, no inflation. 70% of supply funds operator mining; the protocol collects a 10% relay-fee tariff from user payments, which after ecosystem grants funds open-market buyback-and-burn. The supply curve is deterministic from genesis; price support is bounded by realised network utility.

4.1 Supply

Total supply is fixed at 1,000,000,000 KLX (one billion), minted in full at genesis. There is no inflation, no protocol-level issuance, no validator block reward, and no on-chain mechanism capable of expanding supply. Slashing burns reduce supply; buyback-and-burn (§4.3) reduces supply. Supply is monotonically non-increasing for the lifetime of the protocol.

The supply ceiling is enforced at the token contract level and is not a governance parameter. Governance can adjust fee floors, bond sizes, and slashing fractions; it cannot mint.

4.2 Distribution

The node-mining share is intentionally lower than comparable token-incentivized bandwidth markets (70% vs. 88%) because Velnx earmarks an explicit 10% ecosystem bucket. Without funded ecosystem applications, the relay network is a commodity; the application layer is what differentiates Velnx.

4.3 Three Revenue Pillars

4.4 Financial Forecast

Conservative ranges, modeled on documented privacy-software adoption curves (Tor ~2M daily users after 15 years; Mullvad ~700k subscribers after 15 years). The ranges below are protocol-network targets, not promises.

Targets are reset annually based on operator-count and bandwidth-served telemetry, published on the protocol dashboard. The curve is deliberately compressed relative to consumer-VPN comparisons because privacy-protocol adoption follows a shallower S-curve.

4.5 Token Flow

                 emission curve (8-yr halving)
                            │
                            ▼
              ┌──────────────────────────┐
              │  Node mining rewards     │
              │  (70% of supply)         │
              └──────────────┬───────────┘
                             │  earned per byte forwarded
                             ▼
              ┌──────────────────────────┐
   users ───► │  Operators (relays)      │ ◄─── KLX
              └──────────────┬───────────┘
                             │  10% relay-fee tariff
                             │  +  Channel app fees
                             │  +  slashed bonds
                             ▼
              ┌──────────────────────────┐
              │  Protocol revenue pool   │
              └──────────────┬───────────┘
                             │  50–80% (governance)
                             ▼
              ┌──────────────────────────┐
              │  Open-market buyback     │  ←── DEX
              └──────────────┬───────────┘
                             │
                             ▼
              ┌──────────────────────────┐
              │  Burn                    │  → supply down
              └──────────────────────────┘

This loop is sustainable, not Ponzi-shaped, because the buyback is funded only from realised user payments and slashing — never from new token issuance, never from treasury sales, never from speculative reserves. If revenue is zero, the buyback is zero and supply simply stops contracting. The price-support mechanism is therefore bounded above by network utility and cannot exceed it. Mining-side emissions are pre-committed and decay on a fixed schedule, so the supply curve is deterministic from genesis.

Flywheel direction: more users → more relay fees → larger protocol revenue → larger buyback → tighter supply → higher operator economics (fiat-denominated) → more operators → more capacity and geographic diversity → better UX → more users. Each arrow is causal; none assumes a price target.

Anyone with a public IPv4/IPv6 endpoint, sufficient bandwidth, and a KLX bond may register as an operator. The bond is posted to a slashing contract and locked for the duration of node operation plus an unbonding period. Bond size scales with declared capacity to deter Sybil flooding.

Misbehavior is detected by clients and challenge-response audits. Verifiable offenses — failing a non-logging challenge, presenting an inconsistent exit certificate (MITM), advertising capacity not delivered — result in partial or full bond slashing. Slashed KLX is burned, not redistributed, to align incentives without creating bounty-hunter games.

Governance is on-chain and minimal. KLX holders vote on parameter changes (bond sizes, slashing fractions, fee floors), protocol upgrades, and the directory authority signing set. Day-to-day routing decisions are made by clients locally and are explicitly out of governance scope; the protocol governs rules, not paths.

Velnx defends against three classes of adversary. First, network observers on any single link learn only the previous and next hop on that link; ciphertext is indistinguishable from random and timing is shaped. Second, individual node operators — including malicious exit nodes — learn at most one endpoint of the circuit, never both. Third, payment correlation is broken by KLX channel funding, which is not bound to legal identity.

Velnx does not defend against a globally passive adversary capable of observing every link simultaneously; this is a documented limitation of low-latency onion routing and is shared with Tor. Statistical traffic confirmation remains possible against such an adversary, particularly under sustained sessions. Cover traffic and Loopix-style mixing are research directions for later phases (§8).

Velnx is a network-layer tool. It cannot protect against a compromised endpoint, malware, browser fingerprinting, logged-in accounts, or the user voluntarily disclosing identity to a destination service. Privacy is a system property, not a checkbox. The protocol's job ends at the exit node.

Sub-30ms median added latency is achievable through three mechanisms. Geographic routing heuristics select hops to minimize total great-circle distance subject to the diversity constraint that no two hops share an autonomous system. BBRv2 congestion control on inter-node links sustains throughput across long fat networks without the latency inflation of loss-based controllers. Optional parallel paths split a single flow across two disjoint circuits for tail-latency reduction at the cost of bandwidth.

Benchmarks should be reproduced by the reader against the reference client using the methodology in Appendix A of the protocol spec: idle RTT measured via ICMP to a fixed target, throughput via iperf3 over 60s windows, jitter sampled per 100ms. We publish median, p95, and p99 across operator geographies but do not quote single representative numbers; performance is a function of the path, not the protocol.

1. Langley, A., Hamburg, M., Turner, S. Elliptic Curves for Security. RFC 7748, IETF, January 2016.
2. Nir, Y., Langley, A. ChaCha20 and Poly1305 for IETF Protocols. RFC 8439, IETF, June 2018.
3. Donenfeld, J. A. WireGuard: Next Generation Kernel Network Tunnel. Proceedings of NDSS '17, San Diego, 2017.
4. Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., Danezis, G. The Loopix Anonymity System. Proceedings of the 26th USENIX Security Symposium, 2017.
5. Diaz, C., Halpin, H., Kiayias, A. The Nym Network: A Decentralized Mixnet for Privacy-Preserving Communication. Nym Technologies, 2021.
6. Dingledine, R., Mathewson, N., Syverson, P. Tor: The Second-Generation Onion Router. Proceedings of the 13th USENIX Security Symposium, 2004.
7. Cardwell, N., Cheng, Y., Yeganeh, S. H., et al. BBR Congestion Control. IETF Draft draft-cardwell-iccrg-bbr-congestion-control-02, 2022.
8. Frolov, S., Wustrow, E. The use of TLS in Censorship Circumvention. Proceedings of NDSS '19, San Diego, 2019.