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 integer arithmetic against the exact kernel constant τ = 777,000,777 ns:

zeqond_number = floor(unix_nanoseconds / 777_000_777)
phase         = (unix_nanoseconds mod 777_000_777) / 777_000_777   ∈ [0, 1)

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.

Zero drift — why the phase never wanders​

Phase is computed in integer nanoseconds against the exact constant, never as t mod 0.777 in floating point. This is the whole reason the clock has zero drift:

  • f · τ = 1 holds exactly in ℚ (f := 1/τ), because τ is defined as an integer count of nanoseconds — 777,000,777 — not a rounded decimal. There is no 0.777 float to accumulate error against.
  • (t_ns mod 777_000_777) repeats over exactly one Zeqond at any t, for all time. The phase returns to 0 at every tick boundary with no residue, so it cannot creep forward or backward across billions of ticks.
  • Two nodes, or a pulse and its audit chain, that both evaluate the same integer formula land on the same tick and phase forever — there is nothing to re-sync, because there was never any drift to correct.

Contrast the failure mode this design rules out: a clock kept as an accumulating float, or one tick source using floor(sec / 0.777…) while another uses a rounded-millisecond form, will silently diverge over time (an earlier audit caught exactly that and pinned everything to one formula). The integer-nanosecond definition removes the possibility at the root — drift is zero by construction, not by periodic correction.

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.