01 — Architecture

A gossip mesh, on a post-quantum PKI tree

Every kind of zero-trust network before VeilNet kept a centre of its own: a gateway, a vendor's cloud, a coordination server. VeilNet has none. Machines admit each other by checking a post-quantum PKI chain, learn about each other by gossip, and relay for each other blind. A realm is run the same way, by signed controls its members hand on to one another. An organisation's private sovereign network is a tree rooted at a node of its own; VeilNet's public network is another, rooted at Traveller.

On this page

A network with no centre

Zero-trust networking has gone through three designs, and each fixed the one before it while keeping a centre of its own. That centre is what an attacker targets, what an outage takes down, and, when a vendor runs it, where control over the network really sits. VeilNet is built without one.

Fig. 01 — Where each kind of zero trust keeps its centre01 / 04
LANGATEWAY

A VPN gateway. Machines tunnel into a network through one internet-facing gateway. The gateway is the target, and once through it, the whole network behind it is reachable.

IPsec · OpenVPN · WireGuard

A reverse proxy. Services hide behind a vendor's cloud, and every connection runs through it. Identity and policy live in the vendor's console, and if the cloud is down, so is access.

cloudflared · Twingate

A mesh VPN. Machines connect directly, but a coordination server decides who is a member and hands out keys and policy, and relay servers carry what NAT blocks.

Tailscale · NetBird · ZeroTier

VeilNet: gossip, not mesh. There is no centre. Each machine checks every peer's credential chain itself, learns about the rest of the network by gossip, and any member relays for the others without being able to read what it carries.

Placed by core architecture. Self-hosting a centre changes who runs it, not whether there is one.

VPN gatewayReverse proxyMesh VPNVeilNet
The centreThe gatewayThe vendor's cloudThe coordination serverNone
Checks membershipThe gatewayThe vendor's cloudEach machine, with keys the server pushedEach peer, against a signed chain to the root
Knows who is whereThe gatewayThe vendorThe coordination serverEvery member, by gossip
Carries what NAT blocksThe gatewayThe vendor's cloudThe vendor's relay serversAny member, sealed end to end
When the centre failsNo accessNo accessMembership and keys stop changingThere is no centre to fail
Post-quantumRetrofitted, where it existsRetrofitted, where it existsRetrofitted, where it existsRequired on every connection

What gossip means here

  • No node classes. Every anchor is at once a peer, a relay and a starting point for newcomers. Whichever one is reachable does the job.
  • Not a full mesh. An anchor holds connections to the peers it needs, not to every member, and reaches the rest directly or through up to five relays.
  • Gossip, not a directory. News of members, their addresses and the routes they offer spreads peer to peer as soon as the network can carry it. There is no directory server to ask, and none to lose.
  • Admission at every peer. Each anchor checks every other's credential chain itself, before any data flows, so there is no gateway to get past and no console to compromise.
  • Blind relays. Traffic is sealed end to end, so a member relaying it cannot read it.

What makes this possible is how membership works: not a list on a server, but a chain of signatures any peer can check on its own.

The post-quantum PKI tree

At the top of every tree is a root key. It signs a credential for each realm beneath it; a realm signs for its sub-realms and for its own machines; and every signature, at every level, is in the one suite the tree was generated with, ML-DSA-87 by default. A machine, an anchor, joins by presenting its chain, and every peer it meets checks that chain back to the root before any data flows.

Fig. 02 — A post-quantum PKI tree
ROOT KEYTOP OF THE TREEREALMSSIGNED BY THE ROOTSUB-REALMSSIGNED BY A REALMANCHORSSIGNED BY A REALMML-DSA-87Root keyREALMrealm aREALMrealm bSUB-REALMsite 1SUB-REALMsite 2SUB-REALMsite 3PRESENTS ITS CHAINEVERY LINK CHECKED BACK TO THE ROOT · NOTHING HELD IN COMMON

Every link is a signature by the level above: ML-DSA-87 in the default suite. An anchor is admitted by presenting its chain, and every peer checks it back to the root before any data flows. There is no shared secret anywhere in the tree, and no ledger: it is a certificate tree, not a blockchain.

LevelWhat it isWhat it signs
Root keyThe key the whole tree descends fromA credential for each realm directly beneath it
RealmA key of its own, with a credential from the level aboveCredentials for its own anchors, and for sub-realms, as many levels deep as its own credential allows
Sub-realmA realm one level down, with its own key and an IPv4 range of its own. Its IPv6 addresses sit in the tree's one /48Credentials for its own anchors
AnchorA machine whose identity is its own ML-DSA key, admitted by its realmNo credentials for others. It signs what it says about itself, such as its departure and the taint record a move leaves, and with a power on its credential it also signs orders and entries in its realm's knowledge. It presents its chain, and checks everyone else's
  • Post-quantum at every link. Identities and credentials are ML-DSA signatures, and every connection between anchors requires ML-KEM key exchange, so neither a credential nor recorded traffic yields to a future quantum computer. The default suite is ML-DSA-87 with ML-KEM-1024; a tree can instead be generated in a category-3 suite, ML-DSA-65 with ML-KEM-768, for smaller handshakes.
  • No shared secret, anywhere. Membership is a signature, not a password or a list on a server, so there is no network-wide key to steal.
  • Everything derives from the root. The tree's IPv6 address space and its compartment tags are computed from the root key at the top, the genesis every member pins, not from each realm's own key. So a realm needs no configuration beyond that key and its own credential.
  • Data stays in its realm. A realm above can carry its descendants' traffic, sealed, but cannot read it, send into it, shut their machines out or question them, and sibling realms never meet.
  • A certificate tree, not a blockchain. There is no ledger, no consensus and no history. The anchor protocol covers the tree in depth.

Where the tree is rooted

The tree has the same shape wherever it is deployed. What changes is who holds the root key, and so who mints credentials. Nothing else sits at the root. The control plane and the data plane both run on the anchors: they admit each other, find each other, route and carry each other's traffic sealed, and stay silent to anyone without a chain.

Fig. 03 — Where the tree is rooted01 / 02
GUARDIAN REALM · ROOTGuardianROOT KEY HELD BY THE ROOT NODEGENESIS TIERSUB-REALMoffice10.20.0.0/16SUB-REALMfield10.20.0.0/16SUB-REALMlab10.30.0.0/16PRIVATE SOVEREIGN NETWORK · EVERY LAYER IN-HOUSE

A private sovereign network is rooted at the organisation's own root node. Its genesis tier is a few of the organisation's publicly reachable nodes, and beneath it sits a sub-realm for each site, department or team.

Sub-realms can reuse an address range, because data never crosses between them. Nothing in the tree is ours, so it keeps working cut off from the internet.

The public network is rooted at Traveller, hosted by VeilNet. Beneath it, two ghost realms carry two products.

Alpha is open to anyone, with no account and nothing stored. Beta is the VPN, where every exit is tagged with the country its traffic leaves from. Nothing crosses between the two.

Two separate trees. Nothing in the first one is ours, and nothing in it needs to reach us.

Private sovereign network

A private sovereign network is rooted at a root node: an anchor with full capability, which holds the realm's key, mints every credential beneath it and signs the gossip controls its realm is run by. The key never leaves that node. Like every anchor, it runs the network with its peers rather than over them. The network is four layers, each with one job.

LayerWhat it isWhat it does
Guardian realmThe root of the treeIts key is held by the root node, which mints every credential beneath it, renewals included.
Genesis tierA few of the organisation's own nodes with public addresses, in the guardian realm itselfEvery machine's bootstrap list names them, and they relay for everything beneath. They hold no user data of their own; what they relay for members arrives sealed, and they cannot read it.
Sub-realmsOne per site, department or teamEach has an IPv4 range of its own choosing, while every IPv6 address sits in the tree's one /48. Data never crosses between sub-realms, so two of them can use the same IPv4 range.
Member nodesEvery other machineA member needs no public address. It exchanges data only inside its own realm, and only with machines whose taints are compatible with its own.

The same 10.20.0.5 in two sub-realms is two addresses that never meet, so a sub-realm for each site can keep the address plan that site already has. How many levels of sub-realm a deployment may create is fixed by its realm credential. Through a guardian, every sub-realm sits directly beneath the guardian realm, and the realm credential's tier decides whether there can be any at all. On a tier with none, every machine is a member of the guardian realm itself.

Built to run cut off

Nothing in the tree needs to reach us. The realm credential the root node starts from is issued by VeilNet, and can be delivered physically. From then on, the root node, its realms and every node run on the organisation's own infrastructure, connected to the internet or not. If that credential is ever allowed to lapse, nothing inside the tree stops.

The guardian is optional

An operator can mint every credential with the CLI on the root node, and a replacement for each machine before its credential expires, and the network needs nothing more. The guardian stack is a bolt-on for operators who want it easier: it runs alongside the root node, has it mint through its API, renews machines automatically, and adds a console for managing credentials and a view of the telemetry machines report. It issues none of the gossip controls, and it is on no path, control or data.

Public network

VeilNet hosts the public network for personal use, trials and our own consumer products. It is three layers deep.

RealmWho is in itWhat it is for
TravellerVeilNet's own anchorsThe genesis realm: the root of the public tree. It delegates the two ghost realms beneath it.
Ghost realm alphaAnyone — conflux machines and phones, with no accountMessaging, and the free tier conflux joins. An identity is issued to whoever asks and recorded nowhere. Alpha has no exits.
Ghost realm betaPaying VPN users, and VeilNet's exit nodesInternet egress. Every member carries the realm's common taint, zz, and each exit adds one for its country. Every exit also helps new members find the realm.

Alpha and beta never exchange data

They are separate realms on purpose. An anchor exchanges data only with members of its own realm, so an alpha user and a beta user cannot open a session with each other however either is configured. That is a property of the tree, not a setting somebody could get wrong.

Inside beta, taints keep users apart

Every anchor in beta carries zz. An exit adds its country, so the Australian one is {zz, au}. A phone adds the countries its user chose, from one to thirty, and a tag of its own, t- and an HMAC of its user's id. Written short, Alice's phone is {zz, au, us, t-alice}. The containment rule does the rest. {zz, au} is contained in {zz, au, us, t-alice}, so Alice's phone reaches the Australian exit, and the American one too. Bob chose only Australia, and of {zz, au, us, t-alice} and {zz, au, t-bob} neither contains the other, so the two phones cannot reach each other. How taints work is in the anchor protocol documentation.

On alpha, no taint unless the caller asks

An alpha device carries no taint by default. That puts it in the realm's default compartment with every other untainted device, which is what lets any user message any other. A caller may instead name labels of its own when it enrols, and the credential commits to them: devices that name the same label reach each other, and none of the untainted rest.

What we keep

  • Alpha keeps nothing. Enrolment is one call that returns an identity and a credential and records neither, so there is no account, no record and no second copy.
  • Beta keeps each device's identity, so that a paying user can download it again onto a rebuilt phone.
  • Neither can read traffic. Any member may relay for the others, and what it carries is sealed end to end.

Who runs what

Private sovereign networkPublic network
Root keyHeld by the organisation's root nodeHeld by VeilNet
Mints credentialsThe root node, from its CLI or through a guardianTraveller, hosted by VeilNet
Admission, routing and dataEvery node, among its peersEvery node, among its peers
Gossip controlsThe root node, and any member it grants a powerNone: nothing in either ghost realm holds a power
Console and telemetryAn optional guardian, on the organisation's own infrastructureNone
Bootstrap and relayThe organisation's genesis tier, and any memberVeilNet's anchors, and any member
Getting a credentialCommissioned in advance: one file per machineconflux up enrols itself, with no account
Credential lifetimeThe operator's choice. From the root node's CLI, thirty days by default, run to expiry and then replaced; through a guardian, ninety days by default and at most, renewed automaticallyThirty days, renewed automatically
Removing a machineFor good, by expiry: stop renewing it, or mint it no replacement. Sooner, by a block order from the root node, or any member holding the block powerNot by renewal: alpha records nobody, so anyone holding an identity can renew it
CompartmentsSub-realms, and taints within themTaints
ExitsAny machine the operator makes oneBeta's country exits
Air-gappedYesNo

Control and data

Both planes run on the nodes, over the same links. The root node mints a credential, the machine presents it to its peers, and from then on the peers decide everything among themselves: who is admitted, where everyone is, which way traffic goes, and whom to refuse. No service outside the mesh is in that loop, so there is nothing outside it whose outage can take the network down.

Fig. 04 — Control and data both run on the nodes
OPTIONALGuardianROOT NODEMINTS WITH ITS KEYSIGNS THE CONTROLSAPIGENESIS NODERELAYS BLINDnodenodenodeCONTROLDIRECTRENEWALTELEMETRYON BY DEFAULT

Solid: data, straight between machines unless a relayed path is clearly better, and relayed through a node that carries it sealed and cannot read it. Dashed: control over the same links, node to node, meaning admission, gossip and routing, and the gossip controls the root node signs, handed on member to member within its realm. Dotted: a guardian, where one runs. It reaches the root node through its API, and machines only for renewal and for telemetry, which is on by default. It issues no controls, and is on neither plane.

The control plane is the gossip controls

A realm is run by its gossip controls. The root node's credential carries the realm's powers (telemetry, subnets, block and taint), and with them it signs two kinds of control.

  • Orders, from one member to one other: read a machine's telemetry, move it to other compartments, or change the networks a subnet router serves. Each is signed by its issuer, carries the issuer's chain, crosses on a stream sealed end to end, and lives ten minutes at most.
  • Entries in the realm's knowledge: blocks and unblocks, and the taint record a moved machine publishes, carrying the order that moved it. Every member holds them, writes them down and hands them on in a tree eight wide, so the whole realm has them in a handful of hand-overs, and a member that was away is caught up when it is back.
  • Not gated by taints. Taints partition a realm's data and nothing else, so a machine in a compartment of its own still takes the realm's orders and knowledge.

The controls stop at the realm boundary. A realm above carries a sub-realm's traffic, but can neither shut out nor question its machines: an order goes only to a member of its issuer's own realm, and knowledge never leaves the realm it was signed in. Each realm is run by members of that realm holding powers, and the root node holds every power in its own. The guardian console issues none of the controls itself. How the gossip controls work.

Data, and what reaches a guardian

  • Machines talk directly, unless a relayed path is clearly better: the router weighs the direct connection against the relayed paths by what each is measured to cost, and may prefer a relay. A relay is any member that can reach both ends. It carries the traffic sealed end to end and cannot read it.
  • Where a guardian runs, machines send it two things. One is requests for renewal, which it has the root node mint. The other is telemetry, on by default for the whole deployment, each node reporting with a collector credential of its own: its metrics, and per-flow records too (addresses, ports, byte counts, the peer and the relays) if its flows signal is turned on. The contents of traffic are never sent. This is separate from the telemetry order, which a member holding the telemetry power sends over the mesh.
  • If the guardian goes down, the network carries on, and automatic renewal waits until it is back. A credential minted at the root node's CLI has no renewal to wait for: it runs to its expiry, and a replacement is minted and installed before then.

Joining, renewal and removal

  1. 01
    Join

    On a private sovereign network, the root node mints the machine's credential in advance, from its CLI or through a guardian, and the machine's operator installs the one file that produces. On the public network, conflux up draws an identity and a credential in one call.

  2. 02
    Renew

    On the public network, and on a private one where a guardian runs, a credential is renewed automatically at two thirds of its life, without dropping a session. A machine that was switched off past its expiry renews on its next start, and keeps its identity and its address. Without a guardian, a credential minted at the root node's CLI carries no way to renew: it runs to its expiry, and the operator mints and installs a replacement before then.

  3. 03
    Remove: expiry and blocks

    Removal has two mechanisms. Expiry is permanent: stop renewing a machine, or mint it no replacement, and once its credential lapses every peer refuses it. A block is sooner. Issued by a member of the machine's own realm holding the block power, which in the root node's realm is the root node, it makes the machine an outsider to every member it reaches as it spreads, until a member lifts it or, if it was given an end, until then. The machine is not stopped, and is told nothing.

    A block leaves the credential untouched, so removing a machine for good is still expiry. Use both to shut a machine out now and remove it for good. Neither needs the machine to be reachable, and a member that was away is handed the block when it is back. How each one works.

  4. 04
    Cut, never collapse

    When a realm's own credential lapses, the tree is cut at that edge. Everything beneath carries on as a tree of its own, and nothing in it is revoked.

Fig. 05 — Removing a machine: expiry, a block, or both
ExpirySTOP RENEWINGSTILL ADMITTED UNTIL IT LAPSESREFUSEDBlockUNTIL LIFTEDAN OUTSIDERA MEMBER AGAINBothPERMANENTSHUT OUT, AND NEVER RENEWEDDECIDEDLIFTED OR ENDSCREDENTIAL LAPSESAS IT SPREADS

Expiry is permanent but waits out the credential's lifetime. A block holds on each member as it arrives and lasts until its end or until a member lifts it, and it leaves the credential untouched. Together they shut a machine out now and remove it for good.

Where next

  • The guardian stack: the optional console beside a private sovereign network's root node, for managing credentials and watching telemetry.
  • The anchor protocol: identity, realms, powers, taints, admission, routing, the gossip controls and revocation, the model every node in both networks follows.
  • Conflux: putting a machine on either network, and exposing a service once it is there.