Skip to main content

GET /api/chain/seal

Auth none · Rate limit read tier · Cache public, max-age=60 · Source shared/api-core/src/routes/chain.ts, lib/proofOfElapsedZeqonds.ts

The Proof-of-Elapsed-Zeqonds (PoEZ) read surface. Returns the VDF seal spine plus the audit-row window it binds — everything a stranger needs to verify the whole entangled state offline with the served script /verify-zeq-chain.mjs.

Why it exists​

A hash chain is tamper-evident but cheap to recompute: whoever owns the database could rewrite their private history quickly. The seal spine adds a mathematical cost. Each seal is a Verifiable Delay Function over the previous seal plus the 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}) × 2048          (squarings per elapsed Zeqond)

Repeated squaring in a group of unknown order is sequential (no known parallel shortcut), unique (y is fully determined by x and T), and cheap to verify via a Wesolowski proof — O(log T), a handful of mz, fully offline. Rewriting history from seal k onward costs sequential work proportional to the elapsed Zeqonds being forged. Time is the only currency. No witness, no consensus, no third party.

The modulus is the RSA-2048 challenge number (RSA Factoring Challenge, 2001) — nobody, including this project, publicly knows its factorization, so nobody holds a trapdoor. Seals land every 1,287 Zeqonds (the clock's own number — roughly a quarter hour).

Request​

Query paramTypeDefaultNotes
sealsnumber200How many seals to return (1–2000), ascending seal_index.

Response (shape)​

{
  "protocol": "ProofOfElapsedZeqonds",
  "format": "PoEZ-v1",
  "origin_id": "zeq-dev:zeq07064481773",
  "constants": {
    "squarings_per_zeqond": 2048,
    "seal_cadence_zeqonds": 1287,
    "modulus_sha256": "…",
    "modulus_name": "RSA-2048 challenge (RSA Factoring Challenge, 2001)"
  },
  "genesis": {
    "seal_y": "…",
    "seal_y_recipe": "sha256(\"zeq-seal-genesis|\" + origin_id)",
    "audit_genesis_prev_hash": "…",
    "audit_genesis_recipe": "sha256(slug + \"|\" + genesis_zeqond)",
    "machine_slug": "zeq07064481773",
    "genesis_zeqond": 2278000000
  },
  "identity": { "alg": "ed25519", "public_key": "…", "sig_payload": "canonicalJson(SealRecord without sig)" },
  "seal_count": 200,
  "seals": [ { "seal_index": 0, "from_zeqond": 0, "to_zeqond": 0, "head_state_hash": "…", "head_prev_hash": "…", "x_hex": "…", "y_hex": "…", "pi_hex": "…", "t_iterations": 0, "sig": "…" } ],
  "audit_window": [ { "zeqond_number": 0, "state_hash": "…", "prev_hash": "…" } ],
  "row_hash_recipe": "next.prev_hash = sha256(zeqond_number + \"|\" + state_hash + \"|\" + prev_hash)",
  "verify": { "script": "/verify-zeq-chain.mjs", "docs": "COMPUTE-DETERMINISM.md §3 + PR#4 Phase 5" }
}

The audit_window (up to 20,000 rows) lets the verifier re-link the hash chain and match each seal's head row. Every recipe and constant needed for offline verification rides in the payload — distribution of a self-verifying artifact, not an external anchor.

Runnable example​

curl -s "https://zeqstate.com/api/chain/seal?seals=50" > seal.json

curl -fsSO https://zeqstate.com/verify-zeq-chain.mjs
node verify-zeq-chain.mjs seal.json     # zero dependencies, zero network

The verifier checks: format tag, monotonic Zeqond arithmetic (T = gap × 2048 — a too-small T is exactly a sped-up rewrite), the x-derivation binding spine to chain head, the Wesolowski proof, the hash links, and the Ed25519 seal signatures.

Honest limits​

  1. The VDF binds relative sequential time. An attacker with K× the pinned squaring throughput recomputes the spine K× faster than real time — a native/FPGA attacker is plausibly 10–100× faster than the Node.js sealer. The spine makes silent rewrites expensive and detectable-by-cost, not impossible.
  2. Anyone who could factor RSA-2048 could forge delays. That event would be world news; rotating to a fresh class group is the planned response.
  3. History before the first seal is tamper-evident only (hash chain). The spine protects forward from seal 0.

See also​