Skip to main content

The ZEQ Envelope

The envelope is a core primitive of the framework, on the same footing as the kernel and the clock: it is how computation becomes value. Every charged compute mints exactly one envelope — an immutable receipt row in tally_tokens, hash-identified, Zeqond-stamped, and signed. Credits are the fuel that goes in; the envelope is the only thing of value that comes out.

The mint curve — complexity and precision are priced in​

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

cost already scales with operator count and cross-domain coupling, and quality rewards how far inside the ≤0.1% bound the result landed — so a complex, high-precision compute mints a more valuable envelope with no extra rule. The 2× cap bounds supply. A compute that lands exactly on the bound mints V = cost; a perfect-precision compute mints V = 2 × cost. (computeEnvelopeValueZqt in economyConfig.ts.)

Who owns it — funding decides​

  • Paid-funded compute → the whole envelope mints to the user, movable. No split.
  • Free-funded compute → the whole envelope mints to the Foundation; the computing user keeps the soulbound light proof (minted-by stamp + Ed25519 signature + chain seal — the provenance that never moves, even if the envelope is later transferred).
  • Burn-funded compute → no envelope mints at all. See the valve below.

What an envelope is — the record​

Each row carries: token_id / token_hash (deterministic over machine, Zeqond, result digest, operator chain) · value_zqt · funding tags (free_funded_zqt / paid_funded_zqt) · minted_by + issued_to · home_origin (the issuing mother chain — its sole serializer for life) · spend_seq (strictly monotonic per-coin counter, incremented under the same row lock as every ownership change, making the serializer's ordering auditable) · an Ed25519 signature by the node key, with the compute's zeqProof as the proof value.

The utility set​

The envelope's worth is its utility, not a quoted price:

  1. Proof of compute — a portable, re-verifiable receipt.
  2. Transfer — POST /api/tally/envelopes/transfer, the only transfer in the framework; whole-envelope ownership moves, private by default, idempotent, audited on both chains.
  3. Bearer coins — export to a PIN-locked .ZEQ file or QR/NFC payload (status becomes bearer, escrowed on-chain); redeem on any domain.
  4. Governance weight — voting within the ecosystem lands in the near future, denominated in the envelopes you hold.
  5. Burn — the one-way valve back into compute.

The one-way valve​

Envelopes you own can be batch-burned for burn-credits at 1:1 par (BURN_RATE_BPS = 10000): an envelope always redeems its face value in compute.

curl -sS -X POST https://www.zeq.dev/api/tally/envelopes/burn \
  -H "Authorization: Bearer <session or zsm_ admin key>" \
  -H "Content-Type: application/json" \
  -d '{ "ids": ["ZT-…", "ZT-…"] }'
# → { ok, burn_tx, zeqond, burned, sum_value_zqt, rate_bps: 10000,
#     credited, destroyed, envelopes: [...] }

The rules that make it un-gameable:

  • A compute funded by any burn-credits mints no envelope — value can exit the token loop into compute but can never re-enter it. Even at 1:1 the chain terminates in one hop.
  • All-or-nothing batches: one ineligible envelope aborts the whole burn.
  • Eligible = owned by you, active (bearer exports must be reclaimed first), movable (light proofs can't burn), not staked in a vote, homed on this chain.
  • Replay-idempotent: the burn_tx id is deterministic over the sorted id set; retrying a completed burn returns the original receipt.
  • Every burn is a Zeqond-stamped envelope_burn transition on your entangled state — irreversible, and a burned envelope carries no future voting weight. Compute now, or voice later.

Spend order​

Fuel pools draw in a fixed order: free claim → burn-credits → purchased. Balances surface on GET /api/tally/credits/:zid as free_credits, burn_credits, paid_credits.