Skip to content
VERTEX
RU

What's under the hood

Vertex is a small set of design choices applied consistently. This page goes deeper than the home page — same six pillars, with the cryptography and the configuration spelled out.

End-to-end encryption

Every packet between your device and the exit server is sealed with ChaCha20-Poly1305 using a session key derived from an X25519 Diffie-Hellman exchange done at connect time. The relay vertex has no key material; even if it logged every byte it relayed, it would have only ciphertext. The session key is per-device-per-connect, giving you Perfect Forward Secrecy at the session level.

  • X25519 ephemeral keypair on every connect
  • HKDF-SHA256 derives 256-bit session key
  • ChaCha20-Poly1305 AEAD on every packet
  • 12-byte random nonce + 16-byte auth tag (28 B overhead)
  • No persistent shared secrets between client and exit 
session_key = derive(client_pub || exit_pub)
ciphertext, auth_tag = seal(session_key, nonce, plaintext)

Multi-vertex fan-out

Vertex runs several independent relay vertices, hosted with different infrastructure providers in different regions, with no replication or clustering between them. Exit servers connect to all vertices; clients keep an ordered list and reconnect to the next available vertex on failure. The handoff is roughly 100 ms — fast enough that streaming media and SSH sessions usually survive without dropping.

  • Multiple independent relay vertices, hosted across different infrastructure providers
  • No replication or clustering between vertices — each is fully standalone
  • Vertex list is discovered automatically; clients always reach the freshest set
  • Exit servers connect to every vertex, replies travel back through the path the client used
  • Sticky reconnect: last-good vertex is tried first 
vertices = [
  v0,  // primary
  v1,  // backup
  ...  // additional standalone vertices
]
# ordered failover, sticky to last-good

Auto exit-select

On connect the client measures the round-trip to each reachable exit and reads its current load. It picks the lowest RTT under load weighting and routes through that exit. Re-evaluation happens every five minutes; a manual override in the UI takes immediate precedence.

  • Exits announce themselves with periodic, lightweight heartbeats
  • Score balances measured RTT against current load — RTT-dominant
  • Re-evaluate every 5 minutes
  • Manual exit pin overrides auto-select
  • Multiple production exits across independent regions 
score(exit) = rtt + load_penalty
pick min(score) over reachable exits

Device identity (TOFU)

Each client generates an X25519 keypair on first launch and keeps the private half on the device (Keychain on Apple, EncryptedFile on Android, file on Linux). The public half is sent to the exit during the join handshake; the exit pins it the first time it sees it (Trust On First Use) and refuses any future connection from the same username with a different identity. A leaked password is not enough to get into the network.

  • X25519 keypair, 32 bytes public + 32 bytes private
  • HMAC-SHA256 proof signed with a fixed device-identity label
  • TOFU pinning kept on each exit server
  • Reset via support email if you reinstall or migrate device
  • Private key never leaves the device 
shared = ECDH(identity_priv, exit_pub)
proof  = HMAC-SHA256(shared, device_label)

Split routing

On-device CIDR table for Russian network space (8 585 subnets) keeps RU-bound traffic outside the tunnel; only foreign destinations go through the relay vertex. The result: lower latency for domestic services and no spurious geo-blocks on banking, payments or government portals.

  • 8 585 RU subnets baked into each release
  • iOS / macOS: NEPacketTunnelNetworkSettings excludedRoutes
  • Android: VpnService.Builder excludeRoute (capped at 1 500 entries)
  • Linux gateway: ipset ru-nets + iptables MARK
  • Toggle in app: full tunnel ↔ split 
# RU CIDR set, sample
2.56.0.0/16, 31.13.144.0/21, 77.88.0.0/18, 87.250.224.0/19, 213.180.192.0/19, ...

Censorship-resistant transport

Vertex does not carry the wire signature of a typical VPN. To passive observers, the connection blends in with normal encrypted web traffic — so it keeps working on networks that filter dedicated VPN protocols. The client tries the preferred path first and silently falls back to alternatives when something on the way refuses to cooperate.

  • No dedicated VPN port or protocol fingerprint
  • Looks like ordinary encrypted web traffic at the network layer
  • Multiple transport paths chosen at connect time
  • Automatic fallback when the primary path is blocked
  • Continually re-evaluated against new filtering techniques 
transport: prefer → standard
           fallback → web-stream
           mode      → adaptive