ZEQ economy

Credits are fuel. Envelopes are the token. Rewritten 2026-06-04 for the envelope economy (P18). Everything below matches the running code — if an older page contradicts this one, this one is canonical.

ZEQ is the framework's metered compute utility. You spend credits to run physics; every compute mints a ZEQ envelope — an immutable, signed proof-of-compute receipt that carries value. The envelope is the transferable token; credits never are. Value enters the system only when someone computes. There is no off-chain ledger — every charge, claim and envelope mint lives in tally_supply, tally_tokens and tally_transitions on your state machine's chain.

The two fuel pools

Pool	How it fills	Transferable?
Free credits	1,287 on signup (the welcome package) + 777/day by explicit claim	Never — fuel only
Paid credits	Purchased via subscription or swap	Never — fuel only

Credits never move — free or paid. The only transferable asset in the framework is the ZEQ envelope coin: your share of each envelope is held as coins on the envelope itself (never blended into fuel), and transfers move whole envelopes (POST /api/tally/envelopes/transfer).

Spending order is fixed: free credits first, then paid ZEQ. The free pool lives on your account (users.promo_credits_zeqali, 10¹⁸ Zeqali per credit); paid ZEQ lives in your machine's ZEQ balance (tally_supply.tokens_remaining).

The daily claim (777)

Free credits are claimed, not dripped: POST /api/tally/credits/claim (authenticated; also a button in your Vault). Claiming refreshes the free pool to 777 — the Zeqond constant — with GREATEST() semantics: it never reduces a balance (a welcome-day user stays at 1,287) and never stacks (you can't bank a month of free fuel). One claim per UTC day, enforced by a unique ledger row — concurrent claims can't double-fill. Idle and fake accounts accrue nothing.

The spend path (fuel is consumed)

Every paid action calls chargeForCompute() atomically before work runs:

1. Cost is computed from complexity (calculateComputeCost — operator count, cross-domain coupling, proof generation).
2. The free pool absorbs what it can; the balance pays the remainder. The WHERE tokens_remaining >= cost clause is the lock — no over-spend, no race.
3. Fuel is consumed: tokens_remaining falls, tokens_burned rises (it now means "fuel consumed by compute"). Nothing is redistributed — no owner rebate, no foundation cut from fuel.
4. Insufficient balance → 402 Payment Required (free tier). Active paid tiers never wall: the unfunded remainder lands in the overage ledger and reconciles to Stripe at month end.

The envelope mint — V = f(complexity)

Each successful compute mints one ZEQ envelope whose value rewards harder, better computes:

quality = 1 − precisionActual / 0.001        ∈ [0, 1]
V       = round( cost × (1 + quality) )      ∈ [cost, 2 × cost]

Operator count and cross-domain coupling already scale cost; precision scales the multiplier. The KO42 ≤0.1% gate is the mint curve: land on the bound and the envelope is worth what you paid; land near perfect precision and it's worth up to twice that.

Who owns the envelope — split by funding ratio:

Funding	You	Foundation
Paid ZEQ	80% of the paid fraction of V	20% + rounding
Free credits	0%	100%
Mixed	80% × paid fraction	the rest

The free-funded rule is the anti-gaming sink: the daily 777 buys you real results, never transferable value. Your envelope share is held as coins on the envelope — it is never credited back into your fuel balance. A high-precision paid compute earns up to 1.6× its cost in coins — quality compute is how the coin supply grows, and the Foundation takes its share of every mint (as fuel for its pot, which funds the swap).

Each envelope is an immutable tally_tokens row: token_id (ZT-<machine>-<zeqond>-<hash8>), the operator sequence, the signed zeqProof as proof value, and the value columns (value_zqt, free_funded_zqt, paid_funded_zqt, user_share_zqt, foundation_share_zqt). Supply credits and tally_transitions audit rows (envelope_user_share:<id>, envelope_foundation_share:<id>) commit in the same transaction.

Supply properties

• No passive movement. The per-Zeqond drip mint, the tier burn, the heartbeat burn and the burn-ratio redistribution were all retired on 2026-06-04. Balances move only when a compute or paid operation runs.
• Bounded expansion. A compute can mint at most 2× the fuel it consumed, and only paid-funded value reaches users.
• Foundation income = 20% of every paid envelope + 100% of every free-funded envelope — proportional to real engine usage, not to time.
• Forks issue their own token. Every fork of the framework runs this same mechanism on its own chain with its own symbol — Zeq issues ZEQ; your fork issues yours.

The API

What	Endpoint	Notes
Claim the daily 777	POST /api/tally/credits/claim	auth; one per UTC day; GREATEST refill
Balances	GET /api/tally/credits/:zid	owner-gated; free_credits, paid_credits, envelopes{count, your_share_total}
Your envelopes	GET /api/tally/envelopes/:zid	owner-gated; last 100, with value + split per envelope
Send an envelope coin	POST /api/tally/envelopes/transfer	{ token_id, to } — whole-envelope ownership move, idempotent, audited. The only transfer in the framework; /tally/credits/transfer is 410 Gone
Compute (mints an envelope)	POST /api/zeq/compute	response carries tally_charge (funding tags) + zeq_envelope (V, shares, precision)

What was retired (June 2026)

If you see any of these described as current, the page is stale: the 98.713% burn ratio · the 77.2-Zeqond heartbeat burn · the per-Zeqond drip mint ("1 ZEQ/Zeqond from genesis") · tier burn rates · the daily 100-token claim · owner-rebate/burn/foundation splits applied to spend. The canonical mechanics are on this page and in shared/api-core/src/lib/{computeSpend,tally,economyConfig}.ts.

See it live

• Your Vault (/vault/) — free credits, paid ZEQ, envelopes, claim.
• Transparency Oracle (/transparency/) — network-wide supply state.
• Your chain (/state/) — every charge and mint, hash-linked.