Skip to main content

Nodes and node-locality

The lattice is not an open-ended fleet. It is eighteen named nodes, and the roster is a live endpoint rather than a sentence in a document:

curl -s https://zeq.me/api/mesh/peers \
| python3 -c "
import sys,json
d=json.load(sys.stdin)
rows=[(d['self']['node_id'], d['self']['base_url'])] + [(p['node_id'], p['base_url']) for p in d['peers']]
for nid,url in sorted(rows): print(f'{nid:<28} {url}')
print(len(rows), 'nodes')
"

Ask any of the eighteen and the answer is the same shape: 1 + 17 = 18.

The roster​

Measured 2026-09-03 from GET /api/mesh/peers. Every entry carries tcp_port 18870 — the mesh port nodes dial each other on.

Node idOrigin
machine-1287hzhttps://1.287hz.com
machine-hulyafieldhttps://hulyafield.com
machine-hulyapulsehttps://hulyapulse.com
machine-hulyasmathhttps://hulyasmath.com
machine-hulyasorghttps://hulyas.org
machine-kinematicspectrumhttps://kinematicspectrum.com
machine-zeq-devhttps://machine.zeq.dev
machine-zeqapihttps://zeqapi.com
machine-zeqcashhttps://zeq.cash
machine-zeqdevhttps://zeq.dev
machine-zeqdigitalhttps://machine.zeq.digital
machine-zeqenvelopehttps://zeqenvelope.com — the issuer
machine-zeqmehttps://zeq.me
machine-zeqondhttps://zeqond.com
machine-zeqproofhttps://zeqproof.com
machine-zeqsdkhttps://zeqsdk.com
machine-zeqstatehttps://zeqstate.com
machine-zeqvmhttps://zeqvm.com
Two node ids differ by one hyphen

machine-zeqdev is zeq.dev; machine-zeq-dev is machine.zeq.dev. They are different nodes with different databases. Read the id carefully before you conclude two readings disagree.

Exactly one of them seals issuance. machine-zeqenvelope is the configured issuer; the other seventeen run with ZEQ_MESH_ISSUER=false, compute nothing and mint nothing. The live replication cursors agree — it is the only origin whose federated sequence advances. See the issuer and failover.

1 — The surface is byte-identical​

Every node exposes the same API surface. Don't take that on trust — hash it:

for h in zeq.dev zeqsdk.com zeqstate.com zeq.me zeqproof.com hulyas.org; do
  printf '%-16s ' "$h"; curl -s "https://$h/api/endpoints" | shasum -a 256 | cut -c1-16
done
# 2026-09-03: 763 endpoints, digest 230bc03c9f673d33 on all six

Deploys keep it that way: one bundle is built, copied to every node's container, and md5-verified in place. The full parity gate — dist md5, git_sha and treasury pool each collapsing to one distinct value across all eighteen — is described on the mesh page, along with the honest caveat that a rolling deploy is deliberately not identical while a wave is in flight.

2 — A node is a whole machine, not a replica​

Each of the eighteen has its own Postgres, its own Redis, its own genesis zeqond, and its own Ed25519 node identity published at GET /api/node/status. Same schema, different rows. The sweep that returns one pool balance returns eighteen different local states:

for h in zeq.me zeqproof.com hulyas.org zeqenvelope.com zeqsdk.com; do
  printf '%-18s ' "$h"
  curl -s "https://$h/api/worm/status" \
  | python3 -c "import sys,json;d=json.load(sys.stdin);print(d['worm_mode'], d['ledger_count'], d['ledger_root'][:12])"
done
zeq.me             off  648     63dbe7542ff9
zeqproof.com       off  186     c90c60510ed2
hulyas.org         off  23412   6ed993289e2c
zeqenvelope.com    off  154388  74af68c2796e
zeqsdk.com         off  7       64523859a6e9

Eighteen different roots, ledger counts from 7 to 154,388. That is expected — the local chain is per-node. Governance mode is a one-way ratchet (off < evident < enforced); on 2026-09-03 sixteen nodes read off and two (hulyafield.com, machine.zeq.digital) read evident.

3 — Your machine is node-local​

Your machine is deterministic, not consensus-based, and it lives on the node where it was spun up. Its state, its chain and its clock are there, and a machine key presented to a different node answers for nothing — sessions and zsm_… keys are scoped to one node.

  • no consensus latency — your machine's clock ticks locally at the Zeqond rate, and a contract fire doesn't wait for a quorum;
  • a single, sealed history — one chain, one seal spine, no fork-choice ambiguity about what happened;
  • portability by envelope, not by replication — contracts export and tally coins migrate as verified envelopes; the history stays where it was made.

What is global is verifiability: a ZeqProof produced on one node can be checked on any other, because verification needs the envelope and the maths — not the machine.

A ZID, though, is the same on every node, so signing in works anywhere while your data stays put. That gap is the subject of your home node.

Two roster endpoints, only one of which you want​

  • GET /api/mesh/peers — the live mesh_peers registry, and the table above. Use this.
  • GET /api/mesh/status — a legacy counter fed from the static ZEQ_MESH_PEERS environment seed. On zeq.me on 2026-09-03 it still reported meshSize 4, activeNodes 3, lastGossip 0. That is a bootstrap list, not the fleet.

The fleet fabric​

Nodes are joined by two transports — a raw-TCP replication channel on port 18870 and a signed HTTPS peer protocol — plus a node-scoped naming layer and cross-node attestation for the disputed verdict in precision & proof. Aggregators read every public machine on a node through one SSE feed (GET /api/chain/aggregate/sse). Those are the next pages in this section.