The machine
A state machine is your private computational backend — a per-user virtual machine you spin up and own. It holds three things that make everything else on the framework possible: a pair of keys, a hash-linked audit chain that records every computation as tamper-resistant state, 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, and your identity is what owns it.
You spin one up in the browser, free — it provisions on our nodes and hands you the machine's keys and your recovery equation. Nothing to install, nothing to host.
The two keys
Every machine is addressed by two keys with different powers. Keeping them separate is what lets you hand out compute access without handing over control:
zeq_ak_… — the compute key
Runs computations and reads state against your machine. Safe to embed in a client or a CI job; it cannot administer the machine.
zsm_… — the admin key
Administers the machine: deploys contracts, rotates keys, changes settings. The credential you protect.
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. Because a machine is node-local and deterministic (not consensus-based), it lives on the node where it was spun up — but its proofs verify anywhere on the lattice.
Explore
The model
How a machine is structured, addressed, and observed.
- State machines — spin-up, keys, the audit chain, namespaces
- The provisioner — how a paid machine becomes an isolated container
- Observing a machine — the explorer, the live observer, and the time machine
The full machine and audit-chain HTTP surface is in the reference.