Realms

Realms decide which machines can exchange data, and admins mint, rename and archive sub-realms in the console.

Who: Admins mint, rename and archive. Every role reads
Where: Console → Realms

The Organisation's Tree

Your sovereign network is one tree of realms. Your organisation's own realm, the guardian realm, is at the top. Its key is sealed in the guardian, and only the guardian's signer uses it. The guardian realm is never archived.

The machines in the guardian realm are your bootstrap nodes. A bootstrap node is a publicly reachable machine that every other machine starts from. Bootstrap nodes relay traffic for everything below them and carry no user data of their own.

Sub-realms sit directly below the guardian realm, one for each site, department or team. A sub-realm never sits below another sub-realm. Each sub-realm has an address range that you choose. Data never crosses between sub-realms, so two sub-realms can share a range, and a site can keep its existing address plan.

Fig. 01 — The organisation's tree

The guardian realm is at the top of your tree, and its key is sealed in the guardian. Sub-realms sit directly below it, never below each other. The guardian runs an admin node in every realm, the guardian realm included. Data never crosses between sub-realms, so two sub-realms can use the same range.

Sub-Realm Levels

Your realm credential, which VeilNet issues, decides whether anything can sit below the guardian realm. VeilNet signs it with a number of sub-realm levels, and the credential's tier names that number:

Tier	Sub-realm levels
`tier1`	None
`tier2`	One
`tier3`	Two

The levels signed into the credential are what count. The console shows the tier for information only.

With no levels, every machine sits in the guardian realm as a bootstrap node with a public address. Every machine can exchange data with every other machine, and the New sub-realm button is greyed out.
With at least one level, an admin can mint as many sub-realms as you need. Minting does not use up a level. Each sub-realm is signed one level below the guardian realm.

To see what your credential allows, open Realms. The tiles at the top show the tier, the levels in the credential and the levels left below your deepest realm.

Guardian console — RealmsIllustrative

Realmsguardian-adminRealmsA root key and the credentials it signs. Not the realm people sign in to.+ New sub-realmTiertier2display only — not enforcedDelegation levels1signed into the chain; read back after verifying itLevels left0more sub-realms, but none beneath themoffice14 nodesHQ workstations and the site gateways that connect their LAN.10.20.0.0/16range shared with fieldDelegation150 days7 Mar 2027field11 nodesRugged laptops and the vehicle uplink, often off the network for weeks.10.20.0.0/16range shared with officeDelegation120 days5 Feb 2027lab9 nodesTest bench, kept apart from everything else.10.30.0.0/16Delegation61 days8 Dec 2026

Planning Sub-Realms

Plan your sub-realms before you commission machines into them. To move a machine to another sub-realm, you must commission it again, which gives it a new identity and a new address. Follow these rules:

Put machines that must exchange data in the same sub-realm. Data never crosses a realm boundary, whatever else you configure.
Keep a subnet gateway and every device that reaches its network in one sub-realm. A gateway routes only for devices it can exchange data with.
To divide a sub-realm further, use taints rather than more sub-realms. An admin can move a running machine between compartments from the console.
Reuse address ranges freely across sub-realms. An address only resolves among machines that can exchange data.

Minting a Sub-Realm

To mint, or create, a sub-realm, you need the admin role and at least one sub-realm level in your realm credential.

0 of 3 done

In the console, open Realms and choose New sub-realm. The dialog reminds you that every sub-realm is delegated from the guardian realm and has no realm below it.

Reading a Realm's Page

Every realm has a page that every role can read, and some parts appear only to the roles that use them. To open it, choose the realm on Realms or in the sidebar.

Part	What it shows	Who sees it
Nodes	Every machine in the realm, with its address and the days left on its credential. A blocked machine has a blocked badge	Every role
Delegation	The days left on the realm's delegation, its range, when it lapses, who created it and that its root key is sealed	Every role
Blocks	The blocks in force in the realm: which machine, why, since when and until when. See Blocks in Force.	Every role. Admins also see Unblock
Control from the CLI	Where to issue a control credential, shown only when console control is off. See Acting from the CLI.	Managers and admins
Control activity	Every action an operator took on the realm's machines, refusals included. See Control Activity.	Auditors and above

Guardian console — A sub-realmIllustrative

officeguardian-adminofficesub-realm · depth 1realm1nj7dhj29tz3huwenv23lpuxn3qxlfve3sv9f55RenameArchive+ Commission into officeNodes14 commissioned · role member, derived from where it sitsgateway-390 dayskiosk-lobby71 daysprinter-hq64 daysws-ops-0190 daysold-kioskblockedrevoked · 62d leftShowing 1–5 of 14Delegation150days · renewed here, from the root key this host holdsRange10.20.0.0/16Not after7 Mar 2027Created8 Sep 2026 · a.morganRoot keysealed · AES-256-GCMTaintofficeBlocks1 in forceold-kiosk“Revoked old-kiosk”6 Oct 10:15 · until unblockedUnblockEvery sub-realm is flat. A subnet gateway and every device that reaches its network must be here together. A lapse above this guardian does not stop this realm.Control activitywhat operators did to machines here · newest first8 Oct 10:41a.morgan moved the compartments of printer-hq · done2 compartments · generation 18 Oct 09:58j.okafor set the networks served by gateway-3 · doneserves 192.168.10.0/247 Oct 16:20a.morgan unblocked kiosk-lobby · donereached 127 Oct 09:05a.morgan blocked kiosk-lobby · done“Screen cracked, sent for repair” · reached 126 Oct 10:15a.morgan blocked old-kiosk · done“Revoked old-kiosk” · reached 12

A sub-realm's delegation is the credential that the guardian realm signs for it. It lasts 180 days by default, and the guardian renews it 14 days before it lapses. A machine's credential never outlasts its sub-realm's delegation. See Credential Lifetimes.

Admin Nodes

Every realm has an admin node, also called the root node. It is the guardian's own anchor in that realm, and it runs inside the guardian stack. The admin node collects telemetry from every member. It also carries out the actions that operators take in the console: blocks, compartment moves and changes to the networks a router serves.

The guardian creates each realm and its admin node together. The guardian realm's admin node is created when the guardian adopts its realm credential.

Orders and blocks stay inside the realm where they are issued, so each realm needs its own admin node. For the same reason, the guardian delegates all four powers to every sub-realm: telemetry, block, taint and subnets. Your machines hold no powers, so a stolen machine cannot act on anything.

The guardian realm can pass on only the powers that its own credential grants. Settings → Realm control shows each power as granted or withheld. If a sub-realm's delegation lacks a power that the guardian realm has, the guardian signs the delegation again. The sub-realm's machines pick up the change at their next renewal.

Renaming and Archiving

An admin renames or archives a sub-realm with the buttons at the top of its page. The guardian realm cannot be renamed or archived.

Rename changes only the name and the description. The range never changes, because the realm's machines hold addresses from it.
Archive retires a sub-realm you no longer need. The guardian refuses to archive a sub-realm that still has active machines, so revoke each machine first. See Revoking a Machine.
After you archive a sub-realm, the guardian stops renewing its delegation and removes its admin node at the next round. Archiving does not revoke any machine by itself.