Skip to main content

Synchronisation — the computed clock

Every Zeq computation happens at a tick. Step 6, PULSE, stamps it. The tick is a Zeqond, the framework's native unit of time:

  • 1 Zeqond = 0.777 s exactly (777,000,777 ns — see the constants)
  • the HulyaPulse heartbeat is 1.287 Hz — one pulse per 0.777 s, since f_H · τ = 1
  • durations are quoted in Zeqonds and millizeqonds (mz), never in seconds

But the property that matters for computation is not the unit — it is how a node knows what tick it is.

The tick is computed, never received​

The canonical zeqond number is pure arithmetic:

zeqond_number = floor(unix_milliseconds / 777)

That is the whole formula (zeqondClock.ts, mirrored in computePulse and the cross-node verifierNode). A node does not ask a time-server what tick it is. It does not run a consensus round to agree on the time. It reads its own wall clock and divides. Because the formula is fixed, any two nodes reading the same instant compute the same zeqond number — without ever communicating.

This is why the docs never say a node is "synced". There is no synchronisation event — no handshake, no message, no agreement. The tick is computed, identically, everywhere. Writing "synced" would imply a network step that does not exist.

A 2026-06-12 audit caught and fixed a real bug here: /api/zeq/pulse had been computing the tick as floor(sec / 0.777000777) while the audit chain stamped floor(ms / 777). The two had drifted ~2,292 ticks apart since the epoch. One formula, one truth — both now use floor(ms / 777). The lesson is in the source as a comment.

What the clock coordinates (and what it doesn't)​

Inside a node, a lightweight tick loop drives the compliance and awareness layer: every 0.777 s the node hashes its current state and writes an audited transition row keyed to the framework-wide zeqond_number. To align when it hashes with its peers, a node may subscribe to a shared zeq:tick channel published by a singleton. If that channel goes quiet for three Zeqonds, the node falls back to its own local tick loop and keeps going.

The fallback is safe precisely because the zeqond_number itself is computed, not received. Losing the shared channel changes the coordination cadence — the moment a node chooses to hash — never the tick identity. Two nodes that have never exchanged a packet still stamp the same Zeqond on a result computed at the same instant.

Why a computed clock makes verification possible​

Here is the payoff. A result computed on node A is stamped with the Zeqond it happened on. When node B (or your own machine, or the offline verifier) checks that result, it must agree with A about what that tick was — and it does, automatically, because both derive the tick from the same arithmetic. No trust in A's clock is required.

A blockchain needs every participant to agree on an ordering through consensus. Zeq needs no agreement on time at all — the clock is a function, not a vote. Strangers can check each other's timestamps because they both compute the timestamp the same way.

The computed clock also anchors the proof-of-elapsed-Zeqonds seal: the verifiable delay function chains over the head state every ~1287 Zeqonds, binding the audit chain to elapsed sequential time that anyone can verify offline in O(log t).

The SDK ticks too​

The clock is not server-only. The SDK carries its own tick, so a client device beats on the same 1.287 Hz HulyaPulse and computes the same Zeqond numbers as every node. The clock is a property of the framework, not of any one machine — which is the final reason a result is portable: the time it carries is reproducible by anyone, anywhere.

The tick is computed, not received. That is what lets any node verify any other.