Cross-domain economy

Value crosses domains without consensus, without a shared ledger, without a blockchain. Every coin has one home chain that serializes it; the math makes that home unforgeable, tamper-evident, and replay-proof. Everything here is live and verified across two domains.

The honest theorem (read this first)

Double-spend cannot be prevented by per-coin math alone — that is a theorem, not a gap. Signatures, ZeqProofs, and conservation laws prove a coin is authentic and compute-produced (validity). "Has this exact coin already moved somewhere I can't see?" is a different question — uniqueness/ordering — which is equivalent to distributed consensus and provably needs an ordering authority. We do not claim to have replaced consensus with mathematics.

What Zeq relies on instead is structure an open network doesn't have: every coin has exactly one home — its issuing mother chain. That domain's api-core is the single writer for coins it issued; the atomic ownership UPDATE is the serializer. One writer ⇒ no double-spend, by construction, no consensus. A coin minted on domain A stays serialized by A even when a machine on domain B holds it. Per-coin home-chain authority, not network consensus.

The math's job is to make that single-writer authority trust-minimized: unforgeable supply (no coin without real compute), a tamper-evident hash chain, a verifiable spend-sequence, and signed receipts a peer verifies against the home chain — never against the messenger. Symmetric/hash crypto only (HMAC-SHA256), consistent with the post-quantum posture.

The pieces

Concept	What it is
home_origin	Stamped on every coin at mint — the issuing mother chain, its sole serializer for life.
spend_seq	A strictly-monotonic per-coin counter. Every transfer increments it under the same lock — single-use, replay/reorder become detectable.
Reassignment receipt	HMAC-SHA256 over token_id|from|to|to_origin|spend_seq|zeqond|home_origin. Portable; verified at the home chain.
Claim	The receiving domain's verified record that a local ZID holds a peer-homed coin. A view, never an authority.
Claim ticket	A home-issued bearer capability bound to (token_id, holder, spend_seq) that lets a remote holder authorize the coin's next move with no account on the home chain. Single-use (seq-bound).
Anchored receipt	A public, is_public_payload row a recipient publishes to their observer, pointing back to the home chain — so a published transfer is verifiable from both explorers.

The flow (A → B, then onward)

1. Send to a peer-domain recipient. On the home chain A: POST /api/tally/envelopes/transfer { token_id, to, to_origin: "https://B" }. A serializes (spend_seq++), returns a receipt and a claim_ticket.
2. Recipient claims on B. POST /api/tally/claims/import { …receipt fields, claim_ticket }. B verifies the receipt against A over HTTP (/receipt/verify), then records a local claim. The coin now shows in the recipient's B wallet; authority stays on A.
3. Onward transfer (no account on A). The holder presents the ticket: POST /api/tally/envelopes/transfer-claim { token_id, holder_zid, to, claim_ticket } on A. A re-derives the ticket, confirms the holder, serializes the move, and mints a fresh ticket. The used ticket is now dead (seq advanced). From a client you'd route this through your own domain: POST /api/tally/claims/transfer (server-side proxy to the home).
4. Publish (optional). POST /api/tally/claims/publish { token_id } writes a public, home-anchored receipt to your domain's observer. Private by default.

Establishing the channel — ML-KEM-768 first contact (ZeqKeyEx)

Two machines that never shared a secret can establish one with no human in the loop, using ML-KEM-768 (NIST FIPS 203) via the audited @noble/post-quantum.

1. The responder publishes its public key: GET /api/keyex/:slug/pubkey → { public_key, fingerprint, alg: "ML-KEM-768" }. (Lazily generated; the secret key is sealed at rest under the deployment's ZEQ_FIELD_KEY.)
2. The initiator encapsulates to that public key → a ciphertext + a shared secret, and HKDF-derives the AES-256 record key.
3. POST /api/keyex/:slug/handshake { cipher_text } → the responder decapsulates, derives the same record key, stores the session, and returns a confirmation sealed under that key. The initiator opens it with its own key — if it decrypts, both sides hold the identical key.

The record layer is unchanged (AES-256-GCM); ZeqKeyEx only supplies the key — symmetric/hash only, consistent with the post-quantum posture.

Honest boundary: a bare KEM is unauthenticated. This closes harvest-now-decrypt-later (a passive attacker can't recover the secret), but first-contact MITM needs a trust anchor for the responder's public key — pin the published fingerprint against the machine's observer (and, ahead, the global identity layer). We do not claim authenticated first contact from the KEM alone. Verified live: a two-party handshake on zeqstate + zeqond derives an identical key with no prior secret.

Verify it yourself

Action	Endpoint
Coin's home + spend height	GET /api/tally/envelopes/:tokenId/authority
Verify a receipt (against the home)	POST /api/tally/receipt/verify
List your cross-domain claims	GET /api/tally/claims/:zid
Onward-transfer a claim (proxy)	POST /api/tally/claims/transfer
Publish a claim to your observer	POST /api/tally/claims/publish

From the CLI: send claims, send claim <token> <ZID> [to_origin], send claim publish <token>.

What this is not

• No consensus, no mempool, no global ledger, no validators. One home per coin.
• No claim that math prevents double-spend. Math secures validity, ordering-auditability, and tamper-evidence around a single-writer serializer.
• Same ZID across domains = same identity, not merged balances. Each domain keeps its own sovereign state; the identity layer is global, the data plane is federated.

See it live

• Observer (/state/) — a published cross-domain receipt appears here, anchored to its home chain.
• Source — shared/api-core/src/routes/tallyProtocol.ts, app/lib/db/src/schema/{tally,remote-claims}.ts. Full plan: DOUBLE-SPEND-ROADMAP.md.