Skip to main content

ZTB1 — The Zeq Timebase Bridge

The Zeqond is the framework's native time — the computational clock every computation runs on and every result is stamped to. ZTB1 is how that clock interoperates with the outside world: a lossless conversion between the Zeqond and ordinary Unix time, so you can hand the framework normal timestamps and get Zeqond-stamped, verifiable results back.

The formula​

ZTB1(t, from_base, to_base) = (t × conv_factor) + phase_offset

Where:

  • conv_factor = 1 / 0.777 ≈ 1.287 when converting Unix → Zeq (Zeqonds per Unix second — t_Zeq = t_Unix / T_Z).
  • conv_factor = 0.777 when converting Zeq → Unix.
  • phase_offset is the framework's epoch phase (0 at the Unix epoch, 1970-01-01 00:00:00 UTC).
  • T_Z = 0.777 s — the one definitional anchor: 1 Zeqond = 777,000,777 ns exactly.

Zeqond count and phase​

zeqond = floor( unix_ms / 777 )        # integer Zeqond count (1 Zeqond = 0.777 s)
phase  = ( unix_ms mod 777 ) / 777     # ∈ [0, 1)
phi    = 2π · phase                     # radians, if you want them

This is the canonical formula the pulse and the audit chain both use (zeqondClock.ts, computePulse). Two properties follow:

  1. Lossless & exact. The reduction is integer arithmetic on the millisecond clock — round-trip Unix → Zeq → Unix recovers the input, and the tick carries no float residue.
  2. Computed, not received. The tick is a deterministic function of the timestamp — no time-server, no consensus round — so two nodes reading the same instant compute the same Zeqond without ever talking. (The defined constant is τ = 777,000,777 ns; the operational tick uses its 777 ms integer form so pulse and chain always agree.)

Passing Unix time​

You normally pass ordinary Unix timestamps; the framework reduces them to the Zeqond internally. Every result carries the Zeqond it ran at, so you can always see — and independently recompute — which tick a computation was stamped to:

const r = await zeq.compute({
  domain: "Signal Processing",
  inputs: { /* your Unix-timestamped data */ },
});

r.zeqState.zeqond;   // the integer Zeqond this ran at
r.zeqState.phase;    // the phase in [0,1)

Because the reduction is floor(t_ns / 777,000,777), you can reproduce zeqond and phase from the timestamp yourself — no trust required.

When to pass Zeqonds explicitly​

The SDK accepts either timebase for most protocols. Use Zeqonds when:

  • You're chaining CKOs and want bit-exact reproducibility. Zeqond counts are integers, so there's no float in the chain.
  • You're working with phase-driven expressions (including the referential research surface) that read phase directly.
  • You're doing multi-party attestation and want to include the signed Zeqond tuple in your message.

Use Unix seconds everywhere else. Most real-world data is timestamped in Unix, so this is the default ergonomic choice.

Self-hosted vs hosted time​

There is no oscillator to keep in sync. The Zeqond count and phase are a deterministic function of the timestamp, so any two hosts — hosted edge or self-hosted — that agree on the Unix time for an instant compute the same Zeqond and phase for it. NTP simply keeps the underlying wall clocks aligned, as it does for any distributed system.

For verifiable multi-party timing, the hosted API returns a signed tuple (zeqond_count, t_unix, phi, sig) you can include in a CKO — so a third party can confirm exactly which Zeqond a result was stamped at, without trusting either party's local clock.