Operate / Finance and value operators

Settlement operations

Operate proof-native Settlement, Reserve, Note, certificate, and transfer state through exact governed terminal states.

settlementverified receiz.account.state.v3, paired local Reserve-debit and held-bound Note successors, deterministic Kai Pulse, qualified irreversible custody, exact one-use consumption, and optional global publicationComplete production checklist

Implementation rail · verified receiz.account.state.v3, paired local Reserve-debit and held-bound Note successors, deterministic Kai Pulse, qualified irreversible custody, exact one-use consumption, and optional global publication

Exact execution and operator checks

01
Operator check
Subtract Reserve into paired local successors
Canonical-verify the receiz.account.state.v3 Receiz Key/Identity proof and exact Reserve head. Locally compose one Reserve-debit account successor and one equal whole-value held-bound Note genesis, canonical-verify both, then activate that exact Note in qualified irreversible custody.
Substantive records: /learn/offline-operation · /trust/conformance
Expected: The Reserve debit and Note genesis settle locally as verified successors; no Supabase, server, database, session, or external witness gates or releases them.
02
Operator check
Consume once and seal each later successor
Canonical-verify the exact held Note head, atomically consume it, append one whole-value successor, bind it to the receiver's anonymous qualified custody commitment, and release it only after canonical verification.
Substantive records: /learn/offline-operation · /trust/conformance
Expected: The predecessor can authorize no second successor, and the receiver activates the successor as complete local Settlement.
03
Exact mechanic
Run test:settlement-conformance
```
pnpm test:settlement-conformance
```
Mechanic
pnpm test:settlement-conformance
Authentication and account boundary
Authorized local repository checkout; the command proves only the checked repository boundary.
Exact source
package.json · SHA-256 132f99232dfaf26f7186b73752938d1377042808f42d60d374fe7b2e57c7646b
Expected: Exact Reserve head, equal debit/genesis value, amount precision, value source, Kai ordering, predecessor, exact one-use consumption, append-only history, whole-value conservation, and terminal-state contracts pass.
04
Operator check
Choose whether to publish
Optionally publish the unchanged account and Note successors so a wider named domain can discover them. Global publication changes distribution only; it does not gate release, authorize issuance, select the lawful successor, validate it, or complete Settlement.
Substantive records: /learn/offline-operation · /trust/hierarchy
Expected: The parties may publish the same settled truth later, or may never sync.

Complete operating anatomy

Every boundary required to ship.

Solved outcome: Verified account Reserve is locally subtracted into one account-state successor and one equal whole-value Note genesis; each later qualified Note head becomes one canonical successor and complete local Settlement without an external witness.
Prerequisites: For genesis, hold the verified receiz.account.state.v3 Receiz Key/Identity proof, exact current Reserve head, qualified custody receipt, exact amount and value-source inputs, deterministic Kai Pulse, and permitted terminal states. For Send, hold the complete sealed Note and its exact current head. Cash Send needs no intended recipient identity; an optional identity lock remains subordinate.
Exact primitive: settlement
Governing law: Settlement operations is governed by settlement-boundary: Value transition, consent, exit, and rollover remain auditable without renaming Settlement into a generic balance. settlement-conformance: A passing execution confirms the checked settlement invariants for the exact repository state exercised. economy-conformance: A passing execution confirms the checked proof-native economy invariants for the exact repository state exercised.
Source-of-truth order: Receiz law → sealed artifact truth → deterministic proof object state → verified durable local or register truth → authenticated snapshot → server distribution, synchronization, indexing, and publication → database, session, observability, and interface projections.
Expected artifact, receipt, or state: A verified account-state successor and Settlement Note proof bound to operation identity, exact Reserve head, amount precision, value source, Kai Pulse, exact Note head, qualified custody, one-use consumption, whole-value successor, status, and verification evidence.
Inspection: Inspect the receiz.account.state.v3 proof, Reserve-debit successor, held-bound Note genesis or later Settlement proof, value-source inputs, deterministic math, Kai order, exact custody and consumption receipts, whole-value successor, provenance append, and terminal state. Inspection exposes structure and receipt fields; inspection never establishes verification.
Independent verification: Independent verification for settlement: pnpm test:settlement-conformance. This establishes only the settlement boundary named by the bound sources; The implementation rail remains beneath proof authority: verified receiz.account.state.v3, paired local Reserve-debit and held-bound Note successors, deterministic Kai Pulse, qualified irreversible custody, exact one-use consumption, and optional global publication.
Offline behavior: Canonical-verify receiz.account.state.v3; locally compose and verify the Reserve-debit successor and equal whole-value held-bound Note genesis; activate that exact Note in qualified custody; then consume each held head once into one verified whole-value successor. Cash Send is anonymous by default, identity lock is optional, and global publication changes distribution only: it may publish the settled successors later, or the parties may never sync.
Identity and account boundary: Public Record Moment, Seal File, Verify, Export, and public proof reading are account-free. Identity is optional and adds continuity, custody, recovery, and governed private controls after proof admission.
Security boundary: Protect the account/Identity proof, exact Reserve head, and one-use custody authority; reject unqualified custody, unequal debit/genesis value, invalid predecessor, value mutation, or replay; keep Supabase, server, database, session, and publication beneath both proof objects.
Conformance command: pnpm test:settlement-conformance
Deployment checks: Qualify local Reserve subtraction, paired account-state and held-bound Note successors, canonical verification before activation, exact amount precision, predecessor and custody binding, Kai ordering, atomic one-use consumption, whole-value canonical succession, receiver activation, append-only admission, replay rejection, local terminal state, and optional publication without authority inversion.
Production checklist: Test invalid account proof, stale Reserve head, insufficient Reserve, unequal debit/genesis value, fractional-value rejection, unqualified custody, invalid or stale Note predecessor, reused consumption receipt, conflicting replay, invalid Kai order, value mutation or splitting, mutation of admitted history, anonymous offline receipt, successor activation, and optional global publication of the unchanged verified successors.
Rollback and containment: Containment for settlement: Local issuance or transfer is rejected before Note activation. Correct the exact carried inputs and present new paired successors against the verified current proof head. No second authorized successor or conflicting Settlement append is admitted. Continue from the already-activated whole-value successor or preserve the rejected bytes as non-authorizing evidence. Complete local Settlement remains valid and usable. Keep operating from the admitted local successor; publish later if the parties choose. Preserve every stronger held artifact and admitted state while the named boundary is corrected.

Fail closed

Mutation and failure matrix

Account proof, Reserve head, debit value, Note genesis value, amount precision, predecessor proof, qualified custody, consumption receipt, or Kai order differs.

Effect: Local issuance or transfer is rejected before Note activation.
Retry: Never ask a server to repair, release, authorize, round, split value, rewrite, or substitute a predecessor under the same transition.
Recovery: Correct the exact carried inputs and present new paired successors against the verified current proof head.

The exact predecessor has already been consumed or a replay conflicts with admitted local history.

Effect: No second authorized successor or conflicting Settlement append is admitted.
Retry: Re-present identical proof only for verification; never create another successor from the consumed head.
Recovery: Continue from the already-activated whole-value successor or preserve the rejected bytes as non-authorizing evidence.

Optional global publication is unavailable or rejects the projection.

Effect: Complete local Settlement remains valid and usable.
Retry: Retry publication only with the exact already-settled transition.
Recovery: Keep operating from the admitted local successor; publish later if the parties choose.

Retry, idempotency, and recovery

Retry and recovery for settlement: Account proof, Reserve head, debit value, Note genesis value, amount precision, predecessor proof, qualified custody, consumption receipt, or Kai order differs. Retry: Never ask a server to repair, release, authorize, round, split value, rewrite, or substitute a predecessor under the same transition. Recovery: Correct the exact carried inputs and present new paired successors against the verified current proof head. The exact predecessor has already been consumed or a replay conflicts with admitted local history. Retry: Re-present identical proof only for verification; never create another successor from the consumed head. Recovery: Continue from the already-activated whole-value successor or preserve the rejected bytes as non-authorizing evidence. Optional global publication is unavailable or rejects the projection. Retry: Retry publication only with the exact already-settled transition. Recovery: Keep operating from the admitted local successor; publish later if the parties choose.

Exact authority

Claim-to-source bindings

Value transition, consent, exit, and rollover remain auditable without renaming Settlement into a generic balance.
docs/perpetual-rollover-kernel.mdnormative-doctrine · SHA-256 4cad3f91ebae948610e1292fc18854351df65edeaeb03bbd12942b6e74c89b69
A passing execution confirms the checked settlement invariants for the exact repository state exercised.
scripts/test_settlement_conformance.tsexecutable-conformance · SHA-256 021f52595eaaa948337dbe5e01fd4d053a1bab161aea1cad7d053ee1886836ba
A passing execution confirms the checked proof-native economy invariants for the exact repository state exercised.
scripts/test_economy_conformance.tsexecutable-conformance · SHA-256 58bbd2f7b5d79dccee1382da2c7719a42db637e4448dc6348efc472494a9d335

One complete system

Exact execution and operator checks

Subtract Reserve into paired local successors

Consume once and seal each later successor

Run test:settlement-conformance

Choose whether to publish