Issuance

Compute does not mint ZEQ. The clock does. One ZEQ is issued per Zeqond, network-wide, whether anyone computes anything or not. This page is the arithmetic, the exactly-once mechanism, and the split — with every constant traced to the file or endpoint it came from.

The amount is a pure function of the tick

The per-Zeqond amount is not a configured number. It is the product of two kernel constants every node already shares:

$$\text{rate} = f \cdot \tau_Z = 1.287\ \text{Hz} \times 0.777000777\ \text{s} = 0.999999999999$$

shared/api-core/src/lib/meshIssuance.ts:

export const HULYA_FREQ_HZ   = 1.287;          // f
export const ZEQOND_SECONDS  = 0.777000777;    // T_Z  (777,000,777 ns exactly)
export const ZEQ_MINT_RATE_PER_ZEQOND = HULYA_FREQ_HZ * ZEQOND_SECONDS;
export const ISSUANCE_WINDOW = 1;              // one issuance event per Zeqond

The Zeqond is defined as 1/f, so the product is 1 to one part in 10¹² — but it is derived, never typed. That is the whole point: two honest nodes compute the same amount for the same tick by arithmetic, so issuance needs no proposer, no vote and no quorum. The kernel's Zeqond is an integer nanosecond count (TAU_ZQ = 777_000_777 / 1e9), not a rounded 0.777, precisely so this identity holds.

Read it live for any tick:

curl -s https://zeq.me/api/mesh/issuance/at

{
  "ok": true,
  "node": "machine-zeqme",
  "z": 2301712291,
  "window": 2301712291,
  "key": "zeq-issuance-v1:w2301712291",
  "rate": 0.999999999999,
  "amount": "0.999999999999",
  "phase": 0.9999813430986576
}

phase is the HulyaPulse modulation $R(t) = 1 + \alpha\sin(2\pi f t + \varphi_0)$ at that tick, with $\alpha = 1.29\times10^{-3}$. It is recorded as metadata only — deliberately not folded into the mint amount, because a float multiplication in the ledger is exactly how nodes drift apart.

Exactly once, by key — not by agreement

Every node's daemon may append the window's deterministic issuance to the replicated WORM log. What stops two nodes minting the same window twice is not a vote; it is that they produce the same key:

export function windowFor(z: number, window = ISSUANCE_WINDOW): number {
  return Math.floor(z / Math.max(1, Math.floor(window)));
}

export function issuanceEventKey(z: number, window = ISSUANCE_WINDOW): string {
  return `zeq-issuance-v1:w${windowFor(z, window)}`;
}

Key-uniqueness in the replicated log collapses duplicate appends to one entry. This is the mesh-scope version of the single-node watermark, and it is why the design carries no consensus layer: a vote on a pure function of z proves nothing.

There is a history behind that guard. The watermark used to live in process memory, so two app processes sharing one database each kept their own copy and both minted the same window — two ZEQ per Zeqond, network-wide. It now lives in tally_supply.last_mint_zeqond, advanced inside the same row-locked statement that mints.

What actually writes the balance today

Be precise here, because the designed path and the live path are two different numbers.

The balance-writing function is zeqIssuance.issueNetworkZeq(). It applies a pure forward mint from a frozen anchor, so the result is reproducible on restart rather than accumulated:

$$\text{minted} = \left\lfloor\ \text{baseline} \;+\; \text{rate} \times (\text{now} - \text{anchor}) \times \text{KEEP}\ \right\rfloor$$

Term	Value	Source
rate	1	tally_supply.mint_rate_per_zeqond on the issuer row, seated by nodeIssuer.ts
KEEP	0.999	DETERMINISTIC_KEEP = 1 − 0.001, zeqIssuance.ts (the locked burn floor)
anchor	seeded once to the cutover Zeqond, then frozen	tally_supply.last_mint_zeqond
baseline	frozen pre-cutover total	tally_supply.auto_minted_total

So the integer supply advances at 0.999 ZEQ per Zeqond, while /api/mesh/issuance/at publishes 0.999999999999. Both are "one ZEQ per Zeqond" at any human scale, and both are deterministic — but they are not the same constant, and a reader reconciling supply against the published rate should know which one is doing the writing.

KEEP uses only the framework's locked floor, never a node-local error median. That was a real bug: folding a per-node accuracy burn into issuance made minted supply node-dependent, and two nodes measured 46,579 against 356,287 whole ZEQ for the same chain.

One issuer, and what that costs

lib/nodeIssuer.ts provisions exactly one machine that issues: the reserved slug node, purpose='master', mint_rate_per_zeqond = 1. Every other machine carries rate 0 and issues nothing. Replicas are gated out of both minting and distribution by ZEQ_MESH_ISSUER=false, and the mint statement additionally refuses any machine whose home_node is a peer, so a projected balance is never locally re-minted.

This is a single point of failure and the design documents say so plainly. MESH-ISSUANCE.md calls one-node issuance wrong and specifies retiring the node issuer once mesh issuance is live, with the final state carrying zero rows at mint_rate_per_zeqond > 0. That retirement has not happened: the node issuer is still rate 1 and still the writer.

The split — 5% treasury, 95% contributors

Each settlement window the mint accrued since the last one is divided by lib/nodeDistribution.ts:

export const TREASURY_SHARE = 0.05;              // fixed carve to the pool-treasury
export const NODE_SHARE = 1 - TREASURY_SHARE;    // 95% contributor budget
export const SETTLEMENT_WINDOW_Z = ZEQONDS_PER_HOUR;  // 4633.200000004633 Zeqonds ≈ 1 hour

• 5% carve → the pool-treasury (slug='pool', purpose='treasury'). This is the commons / common fund, not the Foundation — a distinct machine from any Foundation account.
• 95% budget → paid to each contributing machine at the absolute rate D/H, by the Zeqonds of sealed compute it supplied in the window. Work is read from agent_sandbox_runs.duration_mz, and only successful runs (exit_code = 0) on active, paid-plan machines count.
• Residual → whatever the 95% budget does not pay out also goes to the pool.

Conservation is exact at planck resolution inside the transaction:

$$\text{carve} + \textstyle\sum \text{allocations} + \text{residual} = \text{issued}$$

Sub-hour contributors accrue their exact fractional share in bi_accrued_quanta (0 ≤ v < 10⁴³) rather than flooring to zero; whole ZEQ roll into the integer balance as the remainder crosses one coin. The whole settlement is one transaction — claim, deduct the issuer, credit contributors, credit the pool — so a failure rolls the period back and it is retried.

The honest state: nobody is earning

GET /api/contribute/census on zeq.me, read 2026-09-03:

{"ok":true,"node":"https://zeq.me","live":{"contributing":0,"experimenting":0,"idle":0},"total":0}

Zero contributors. So every window pays distributed: 0, nodes: 0 and the treasury receives carve + residual = 100% of the mint. That is not a policy choice; it is the 95% budget with nobody to pay. It shows in the balances: the pool holds 436,469 ZEQ, byte-identical on all three nodes sampled, while the issuer holds ~181,355.

There is a structural reason as well as an empty-network one. The sandbox enforces a hard per-agent daily cap of 60,000 millizeqonds — 60 Zeqonds of compute per agent per day — and a contributor must supply ⌈H⌉ = 4,634 Zeqonds in a single ~1-hour window to earn even one whole ZEQ. Those two numbers are 77× apart, so at current sandbox limits a single agent cannot reach the first whole coin.

The supply cap, and the caveat

export const Z_PER_DAY = 86400 / TAU_Z;              // 111196.8000001112
export const SUPPLY_CAP_ASYMPTOTIC = 111_196_800;    // ZEQ

The cap is exactly 1,000 days of issuance: 111,196.8 ZEQ/day × 1,000. It comes from the decayed series $S_\infty = 111{,}196.8 / (0.001 + e)$, evaluated at median error $e = 0$, where 0.001 is the same burn floor that gives DETERMINISTIC_KEEP its 0.999.

The caveat, stated plainly: SUPPLY_CAP_ASYMPTOTIC is a declared constant, not a live guard on the issuer. issueNetworkZeq gates on the issuer row's own column — (max_supply = 0 OR tokens_minted < max_supply) — and nodeIssuer.ts seats that row with max_supply = 0, which the code comments describe as an "unlimited lifetime cap". So the asymptotic cap is a property of the decay model rather than something the mint statement currently enforces.

Constants on this page

Constant	Value	Source
HULYA_FREQ_HZ (f)	1.287 Hz	meshIssuance.ts; live /api/tally/transparency → pulse.hz
ZEQOND_SECONDS (τ_Z)	0.777000777 s	meshIssuance.ts; live pulse.zeqond_sec_exact
ZEQ_MINT_RATE_PER_ZEQOND	0.999999999999	meshIssuance.ts; live /api/mesh/issuance/at → rate
ISSUANCE_WINDOW	1 Zeqond	meshIssuance.ts
Window key format	zeq-issuance-v1:w<window>	issuanceEventKey(); live /api/mesh/issuance/at → key
DETERMINISTIC_KEEP	0.999	zeqIssuance.ts
TREASURY_SHARE	0.05	nodeDistribution.ts
NODE_SHARE	0.95	nodeDistribution.ts
SETTLEMENT_WINDOW_Z	4633.200000004633 Zeqonds	nodeDistribution.ts = ZEQONDS_PER_HOUR
Z_PER_DAY	111,196.8000001112	economyConfig.ts = 86400 / τ_Z
SUPPLY_CAP_ASYMPTOTIC	111,196,800 ZEQ	economyConfig.ts

Read next

• Conservation — check the issued total against the balances yourself.
• Compute-hours — the D/H peg the 95% is paid at.
• Contributed compute — how a machine becomes eligible to earn.
• The ZEQ coin — what an issued ZEQ becomes once a holder wants it in hand.