Skip to main content

Proof of Elapsed Zeqonds

Source: shared/api-core/src/lib/proofOfElapsedZeqonds.ts.

A hash chain is tamper-evident but cheap to rewrite: a machine that owns its own database can recompute a private history in milliseconds. The seal spine adds a mathematical cost so the chain becomes tamper-resistant — with no witness, no consensus, and no third party.

The mechanism​

Each seal is a Verifiable Delay Function (VDF) over the previous seal and the current chain head:

x_k = SHA-256( y_{k-1} ‖ head_state_hash_k ‖ z_k ‖ origin_id )
y_k = x_k ^ (2^T_k)  mod N          # T_k sequential squarings
T_k = (z_k − z_{k-1}) × SQUARINGS_PER_ZEQOND

Repeated squaring in a group of unknown order is:

  • sequential — no parallel shortcut is known, so producing y_k takes wall-clock time proportional to T_k;
  • unique — y is fully determined by x and T (no choice, no grinding);
  • cheap to verify — a Wesolowski proof checks it in O(log T), milliseconds, offline.

To rewrite history from seal k onward you must recompute every T from k to now — sequential work proportional to the elapsed Zeqonds you are trying to forge. Time is the only currency.

The group​

The modulus N (VDF_MODULUS) is the RSA-2048 challenge modulus — a number of unknown factorisation, which is what makes the order of the group unknown and the delay non-shortcuttable. SQUARINGS_PER_ZEQOND and SEAL_CADENCE_ZEQONDS set the work rate and how often a seal is laid.

What it protects​

The seal chain binds the per-machine entangled-state audit chain: every ZeqProof-carrying transition is anchored under a seal, so the ordering and timing of a machine's private history cannot be silently rewritten after the fact.