Skip to main content

The machine

A state machine is your private computational backend — a per-user virtual machine you spin up and own. It holds a hash-linked audit chain that records every computation as tamper-resistant state, at least one API key bound to it, and its own clock ticking on the 1.287 Hz HulyaPulse. Contracts run inside it, channels are hosted on it, proofs are stamped by it.

Where it lives — and where your identity lives

This is the part earlier versions of this page got wrong. They said a machine "provisions on our nodes," as though the fleet were one pool you land somewhere inside. It isn't. There are eighteen nodes, each with its own Postgres and its own Redis, and:

Your machine is created on the node you were talking to, and it stays there. Not scheduled across a pool, not replicated for safety. GET /api/fleet/nodes on zeq.me on 2026-09-03 returned {"self":"machine-zeqme","nodes":["machine-zeqme"],"count":1} — the placement ring resolves everything local, on every node. Wherever you signed in is where your machine was born.

Your ZID is not created anywhere. It is computed from your account equation, so every one of the eighteen derives the same ZEQ7… from the same equation. Signing in works on any node without account-linking or key exchange.

Those two facts pull in opposite directions, and the gap between them is the single most useful thing to understand about this system:

Your ZIDYour machine
Made bycomputation from your equationa write to one node's Postgres
Same on every node?yesno — it exists on exactly one
Sessionissued separately by each node
If that node is downyou can still sign in elsewhereunreadable, from anywhere

Signing in on a node that does not home you gets you a working session, a valid ZID, and an empty identity. Nothing is lost; you are looking at the wrong node. Your identity and your home node is the page that tells you which one — GET /api/identity/home/:zid asks every peer what it holds for you and names your primary home.

One ZID, possibly several machines, on several nodes

A ZID can own a machine on more than one node, and the directory reports homes as a list for exactly that reason. If you spin up in two places you have two machines, not one machine seen twice. See state machines.

Keys are bound to one machine on one node

Every key is a row in that node's state_machine_api_keys, with state_machine_id pointing at one machine. Two forms are minted at spin-up:

zsm_… — the machine key

The state-machine key. It carries an explicit scope — read, write or admin — so a read-only key can never write. Stored as an HMAC; the framework never holds the raw value.

zeq_ak_… — the publish key

Issued by issuePublishKey() alongside the machine, for the hosted-pages surface. Also accepted as a bearer token on the API.

The prefix matters less than the binding. A key minted for one machine cannot write to another, even if you put it in the wrong header — the check is canWrite(machine, zid, role) against the ZID the key resolves to, not a trust in the token itself. And because sessions and keys are both per-node, a zsm_… from zeq.me answers for nothing at zeqproof.com.

What lives inside

Your machine's history is an entangled-state audit chain — each recorded computation hash-links to the one before, so the past cannot be rewritten without breaking the links. Every row names the operator it ran, the result, and the Zeqond it happened at, and carries a ZeqProof any node can re-verify.

The chain is node-local and deterministic, not consensus-based: a contract fire waits on no quorum. Its proofs verify anywhere on the lattice, because verification needs the envelope and the maths — not the machine.

What is shared across the eighteen is a separate, narrower thing: the WORM issuance spine, which carries network-level events like issuance, treasury flows and your machine's birth record (machine_genesis) — but never its contents. See what actually travels.

Explore

The model

How a machine is structured, addressed, and observed.

Built on it

Everything the machine carries.

  • Contracts — deployable logic that runs inside the machine
  • Channels — hosted pages served on the machine
  • Proofs — why every transition is verifiable

The full machine and audit-chain HTTP surface is in the reference.