Skip to main content

What is Zeq

Zeq is one computational surface for physics on a single time base, and ZeqVM is the virtual machine that runs it. The front page makes the case for why — the 1.287 Hz HulyaPulse and 0.777 s Zeqond that every computation runs on, one surface for quantum, classical, and relativistic physics with no translation layer between regimes. This page is the practical answer to the next question: what is Zeq actually made of, and how do you build on it?

If you want the engineering account of how a query becomes a verified result — the kernel, the seven-step pipeline, the solvers, the proof stack — read How Zeq computes. This page is the orientation; that section is the depth.

The framework — three foundations​

  1. A time base — the foundation. The HulyaPulse at exactly f = 1.287 Hz, ticking once per Zeqond (τ = 0.777 s, fixed exactly at 777,000,777 ns so f·τ = 1). Every computation runs on this clock; every result is phase-stamped to it in integer nanoseconds; every state transition is Zeqond-stamped. This shared computational time base is the framework's defining constant — the thing that lets operators from different regimes compose on common ground.
  2. An operator catalogue. 1,500+ catalogued operators across 65 domains — quantum mechanics, Newtonian mechanics, general relativity, computer science — including a referential frontier research surface. Each is a standard formula the framework identifies and computes with a dedicated CODATA-backed solver; the IDs are a reference vocabulary. (The 230 named protocols now ship as state contracts — deployable, fireable programs over this catalogue, not just formulas you compute. 316 contract templates in all.)
  3. A runtime you own — ZeqVM + state contracts. The language runs on ZeqVM, and you get your own instance: a state machine bound to your ZID, with an entangled state (hash-linked audit log), a ZEQ balance, and a page surface at /s/<machine>/. On it you author state contracts — deployable JSON programs that run on triggers (every Zeqond, cron, on-event, on-aggregate, with dry-run and replay). This is the programmable foundation: protocols are formulas you compute; state contracts are programs you deploy onto your own machine's clock, every fire Zeqond-stamped onto your entangled state.

What errorPct means​

errorPct is the tolerance a computation is held to. For closed-form physics (the compute() path) it is the solver's numeric-accuracy bar — results match the textbook value. For the dynamical solve() path it is the integration tolerance: the energy-drift budget the symplectic integrator holds to (≤0.1%), reported live. It is a tolerance, not a "this isn't accurate" disclaimer — the number tells you how tightly the computation was held, not that it's approximate.

What you build on — the ZeqVM​

The language is what you compose; ZeqVM is what runs it, and you get your own instance — a state machine bound to your ZID. One user, one state machine. It holds an entangled state (the hash-linked, Zeqond-stamped audit log), a ZEQ balance, a page surface at /s/<machine>/, your API keys, and your contracts.

  • State machines — your per-user computational backend; every transition is hash-linked and tamper-evident.
  • State contracts — JSON programs that run on triggers (every Zeqond, cron, on-event, on-aggregate, dry-run, replay). This is the developer-programmable surface; the 230 former protocols now ship as 316 deployable contract templates.
  • State channels — live pages your machine hosts at /s/<machine>/p/<page>/. Every version is hash-committed to your entangled state, and the page gets a same-origin compute proxy into the kernel — no separate Vercel, Netlify, or CDN to wire up. The pages the world sees, served by your machine.

The three state primitives — a state machine (your namespace + identity), the state contracts that run logic on its clock, and the state channels that host the pages on it. Together they're how you ship a real system on Zeq.

  • Nano-zeqond engines — sub-Zeqond integration of the master equation: the field evolver, the velocity-Verlet MD engine, and the WebGL2 GPU field kernel, all energy-validated to ≤0.1%.

How you reach it​

  • Any language, own registry. npm config set @zeq:registry https://zeq.dev/registry && npm install @zeq/sdk — the framework hosts its own npm (no npmjs in the loop). 12 client languages + raw HTTP all make the same wire calls.
  • Connect any AI (MCP). @zeq/mcp exposes 18 live tools over stdio or POST /api/mcp. An AI mints a demo key, calls zeq_spin_up to get its own machine + key, then computes, builds & fires contracts, publishes pages, and reads the Observer — every result carrying a verifiable ZeqProof. See hand it to an AI.
  • Version your work (ZeqGit). zeq.dev/zeqgit — the framework's own git + PDF repository: one ZID = one account, per-project repos, a Zeq-branded PDF reader, every push ZeqProof-anchored to your entangled state.

Why a timebase?​

Most numerical systems inherit time from whatever host they run on — Unix seconds, CPU ticks, framework loops. This is fine for simple work and fragile when you compose operators from different domains at different scales. A general-relativity operator measures proper time; a quantum-mechanics operator advances by ℏ-scaled phase; a signal-processing operator samples at some arbitrary rate. They don't agree unless you force them to.

Zeq puts them on one clock: the HulyaPulse. The Zeqond count and phase are a deterministic function of the timestamp — exact integer arithmetic on the millisecond clock, so they never drift and two nodes that never talk still agree on the tick:

zeqond = floor( unix_ms / 777 )        # integer Zeqond count (1 Zeqond = 0.777 s)
phase  = ( unix_ms mod 777 ) / 777     # ∈ [0, 1), exact — no float, no drift

The tick is computed, never received — no time-server, no consensus round. Unix time isn't replaced — the temporal-bridge operator ZTB1 converts between Unix and Zeqonds losslessly. (The defined constant is τ = 777,000,777 ns; see the constants.) This is how every computation is phase-locked to the same clock.

The math, in one page​

The full mathematics lives in the SDK's Core Math section — here's the shape, with links.

  • The master equation (full page) — a nonlinear ϕ⁴ field, □ϕ = ∇²ϕ − μ²ϕ − λϕ³ plus a coupling term weighted by the operators you pass. The nano-zeqond engine integrates it with a symplectic integrator, energy conserved to ≤0.1%. This is what solve() and multibody() run.
  • The functional equation (full page) — a single scalar E = P_φ · Z(M, R, δ, C, X) that characterizes a solve() run (RMS field momentum × an environment scale factor), returned as functionalEnergy. A diagnostic, never a change to the physics.
  • The spectral-topological equation (full page) — the propagator form Ψ = ∭ K ϕ, exact for the linear field and the oracle the engine is checked against to machine precision.
  • KO42 (full page) — the HulyaPulse modulation R(t) = 1 + α·sin(2π·f·t), α = 10⁻³, bounded to ≤0.1% by construction. Averaged over one Zeqond it integrates to the identity, so it phase-stamps and reparametrizes time without changing the physics value.

The 7-step pipeline​

Every compute() call runs the same seven steps on the server (the SDK does it for you):

  1. SELECT — resolve the operator(s) for your domain and inputs. KO42 is always included; up to three domain operators join it.
  2. BIND — attach the CODATA constants the solver needs.
  3. VALIDATE — dimensional check. Inputs that don't engage the chosen solver are rejected loudly, rather than answered from defaults.
  4. COMPUTE — evaluate the domain's dedicated closed-form solver against your inputs.
  5. VERIFY — check the result against the numeric tolerance, and where possible re-evaluate the closed form independently.
  6. PULSE — stamp the Zeqond and phase in integer ns; apply the KO42 modulation as bookkeeping.
  7. RETURN — assemble the CKO with the ZeqProof HMAC and Ed25519 signature.

When you POST to /api/zeq/compute (from curl, zeq.py, the CLI, any SDK client, or an MCP-connected AI), these seven run server-side and the CKO you receive is signed and independently verifiable. The framework's design rules — KO42 always on, ≤4 operators per call, operators matched to the domain, held to the ≤0.1% tolerance — are enforced across these steps.

Who this is for​

If you build anything that composes math from more than one domain, Zeq saves you work. Typical use cases:

  • Physics simulators — wind tunnels, fluid dynamics, thermodynamics, electromagnetism.
  • Science applications — medical imaging, pharmacokinetics, genomics analysis, forensic tools.
  • Engineering — structural analysis, seismic modeling, aerospace re-entry modeling.
  • Crypto & messaging — Zeq Message, Zeq Mail, and zeq-vault, secured with standard audited cryptography (AES-256-GCM, HMAC-SHA256, PBKDF2), every action Zeqond-stamped and signed to your entangled state.
  • ML and signal work — signal classifiers, neural architectures, RL playgrounds.

If you're doing arithmetic on numbers that don't need phase-locked composition, Zeq is overkill — use NumPy.

The mathematical reality — the equations behind every result: