Conservation

Every coin operation — mint-from-balance, split, merge, transfer, export, redeem — preserves total plancks by construction, and each enforces it inside its own transaction. conservation is the probe that recomputes the whole thing from the tables, live, on demand.

$$\underbrace{\text{issuer}}_{\text{unissued reserve}} \;+\; \underbrace{\text{pool}}_{\text{commons}} \;+\; \underbrace{\text{user\_held}}_{\text{everyone else}} \;=\; \underbrace{\text{issued}}_{\text{projected total}}$$

All of it in exact plancks (1 ZEQ = 10⁴³), all BigInt, no float anywhere on the path.

Check it yourself

Open, unauthenticated, on every node:

curl -s https://zeq.me/api/tally/coins/conservation

Read on 2026-09-03 at Zeqond 2,301,712,305:

{
  "ok": true,
  "origin": "https://zeq.me",
  "zeqond": 2301712305,
  "issuer_remaining_plancks": "1813550000000000000000000000000000000000000000000",
  "pool_plancks":             "4364690000000000000000000000000000000000000000000",
  "user_held_plancks":        "5740920000000000000000000000000000000000000000000",
  "coin_token_plancks": "0",
  "coin_token_count": 0,
  "integer_plancks":          "11919160000000000000000000000000000000000000000000",
  "total_plancks":            "11919160000000000000000000000000000000000000000000",
  "issued_plancks":           "11919160000000000000000000000000000000000000000000",
  "network_supply_plancks":    "6178240000000000000000000000000000000000000000000",
  "conserved": true,
  "as_zeq": { "issuer": 181355, "pool": 436469, "coins": 0, "total": 1191916 }
}

as_zeq is the same figures divided by 10⁴³ — a convenience for reading, never the thing to reconcile against. Do the arithmetic in plancks.

Every term

Field	What it sums	Where it comes from
issuer_remaining_plancks	The issuer's unissued reserve	tally_supply row for sm.slug='node': tokens_remaining × 10^43 + bi_accrued_quanta
pool_plancks	The commons / treasury balance	Same expression for sm.slug='pool'
integer_plancks	Every tally_supply row, issuer and pool included	SUM(tokens_remaining × 10^43 + bi_accrued_quanta) over the whole table
coin_token_plancks	Live coin bearer tokens	SUM(value_plancks) over tally_tokens where kind='coin' and status IN ('active','bearer')
coin_token_count	How many such rows exist	COUNT(*) on the same predicate
user_held_plancks	Everyone who is not the issuer or the pool	integer_plancks − issuer − pool + coin_token_plancks
total_plancks	The projected total	integer_plancks + coin_token_plancks
issued_plancks	Same number	In core scope, issued is the projected total
network_supply_plancks	issuer + pool	The figure that must be identical across nodes
conserved	issuer + pool + user_held == total	Boolean

Two details worth pausing on.

status='bearer' counts. A coin exported to a .ZEQ file is escrowed, not destroyed — its row is still there at status='bearer' and its plancks are still in the total. That is correct: the value went offline, it did not leave the economy. A coin burned for a cross-domain migrate goes to status='migrated' and drops out here, because it has been re-minted on the destination chain.

bi_accrued_quanta is the sub-ZEQ remainder. Fractional pro-rata earnings accumulate there (0 ≤ v < 10^43) and roll into the integer balance as they cross one whole coin. Counting it here is what makes the sum exact rather than approximately exact.

What conserved: true does and does not prove

Be clear about this, because the field name promises more than the check delivers.

Substitute the definition of user_held into the test:

$$\text{issuer} + \text{pool} + \underbrace{(\text{integer} - \text{issuer} - \text{pool} + \text{coins})}_{\text{user\_held}} \;=\; \text{integer} + \text{coins} \;=\; \text{total}$$

It cancels. conserved is an algebraic identity — it is true for any values the queries return, and it would stay true if the issuer minted ten times too fast. What it actually verifies is that the BigInt path did not lose a digit between the four SQL reads and the response. That is worth having, and it is not an inflation check.

The checks that do bite are these two:

1. Per-operation conservation, enforced in-transaction

Every coin handler asserts its own sum before committing. From mint-from-balance:

// Conservation: minted coin plancks MUST equal the debited plancks.
if (sum !== totalPlancks) throw new Error("conservation_violation");

Split refuses with 400 sum_mismatch if the children do not sum to the parent's exact face, and asserts again after minting them. Merge sums the consumed inputs and mints exactly that. These run inside the transaction, so a violation rolls the whole operation back — nothing half-minted.

2. Cross-node parity of network_supply_plancks

issuer + pool is the projection that every node must agree on. This is the real audit, and you can run it in one line:

for h in zeq.me zeqproof.com zeqsdk.com; do
  curl -s "https://$h/api/tally/coins/conservation" \
    | python3 -c 'import sys,json;d=json.load(sys.stdin);print(d["origin"],d["zeqond"],d["network_supply_plancks"],d["as_zeq"])'
done

Sampled simultaneously on 2026-09-03:

Node	Zeqond	issuer	pool	user_held	coins	network_supply (ZEQ)	total (ZEQ)
zeqproof.com	2,301,712,304	181,323	436,469	0	0	617,792	617,792
zeq.me	2,301,712,305	181,355	436,469	574,092	0	617,824	1,191,916
zeqsdk.com	2,301,712,307	181,355	436,469	214	0	617,824	618,038

Read that honestly:

• The pool is byte-identical on all three. 436,469 ZEQ everywhere. That is the projection working.
• network_supply matches on zeq.me and zeqsdk.com. zeqproof.com reads 32 ZEQ lower at a Zeqond 1–3 earlier — a projection lag of about 32 Zeqonds, not a divergence. Sample the three within the same tick before calling a difference a fault.
• total_plancks does not match across nodes, and is not supposed to. user_held differs wildly (574,092 / 214 / 0) because per-user balances and envelopes are home-local by design — they do not federate to peers. Only network_supply_plancks is the cross-node figure.
• coin_token_count is 0 everywhere. No ZEQ coin bearer token has been minted on any node sampled. The coin machinery is live and its invariants hold; nothing is using it yet.

The unflattering line

The strongest claim this endpoint supports today is: the projection is internally consistent, the commons balance agrees across three nodes, and every coin operation conserves plancks inside its own transaction. It does not yet demonstrate that the total issued matches an independently reconstructed sum of issuance events — issued_plancks is defined as the projected total, not as a replay of the WORM issuance log. Anyone auditing supply should know that the two are the same number by definition here, not by agreement.

Read next

• Issuance — where the issued total comes from, and the one place a cap is declared but not enforced.
• The ZEQ coin — the operations whose in-transaction assertions are the real guard.
• Transparency — the wider published supply surface.