The lattice

The framework runs as a lattice of nodes. Every node serves a byte-identical API surface — you don't have to take that on faith, you can hash it: GET /api/endpoints on any two nodes returns the same bytes. The kernel, the operator registry, the constants, the clock, and the proof formats are identical on every node by construction, and that's precisely what lets a ZeqProof made on one node be re-verified on another.

Machines are node-local and deterministic — not consensus-based. A machine lives on the node where it was spun up; there is no global ledger and no voting. What travels between nodes is verification, not state:

See the live nodes →

Proofs travel

A result's ZeqProof re-verifies on any node, because every node runs identical maths and constants.

History stays

Your machine's audit chain lives on its home node. It isn't replicated or gossiped — it's yours, in one place.

No consensus latency

Your machine's clock ticks locally. Nothing waits on a quorum, so computation is immediate.

Verify parity yourself

# the surface is identical on any two nodes — the hashes match
curl -s https://zeqsdk.com/api/endpoints | sha256sum
curl -s https://www.zeq.dev/api/endpoints | sha256sum

Explore

How the fleet works

Node-locality and the parity guarantee.

• Nodes and node-locality — byte-identical surfaces, determinism, what travels vs what stays

Your data across it

Portability without linking or key exchange.

• Data sovereignty — log into any node and bring your data with you, by ZeqID

Naming & self-hosting

Resolve nodes, and join the lattice as a peer.

• ZeqDNS — resolve a domain by computing its address, plus .hz names
• Mesh & self-hosting — the gossip mesh, ZeqSSL, and standing up a node

The network APIs live in the reference.