Receiz/Economy/Offline Settlement Notes

Offline notes

Offline Notes package value as sealed instruments for portable transfer. The receiver verifies the held Note locally and accepts its claim at a deterministic Kai Pulse. That accepted local claim is Settlement. Account posting and global sync are optional later projections; neither makes the Settlement real.

Settlement Ledger Unit (SLU): Settlement Ledger Unit (SLU) is the canonical non-USD settlement custody unit used to keep online ledger replay and offline note settlement deterministic. For protocol compatibility, SLU micro-values are persisted in `phi*` field names (for example `amountPhiMicro` and `balancePhiMicro`).

Institutional core: one deterministic custody unit across ledger posting, replay, and offline note settlement. Approachable edge: USD-first account UX with explicit field-level SLU compatibility for integrators.

Instrument, not attachment

An offline note is a sealed value instrument with deterministic fields and claim semantics, not a screenshot, message, or informal promise.

Offline continuity layer

A qualified-custody-bound Note can move without network dependency, verify locally, and settle at its deterministic Kai Pulse. Global ownership publication is optional.

File-compatible surface

Users can send and receive standard file formats (PNG, PDF, JSON) while the underlying settlement contract preserves deterministic replay and proof continuity.

Device result

Qualified or unavailable.

Every device gets the same automatic opportunity to prove attested, rollback-resistant custody. If the exact environment supplies the required evidence, Offline Cash works immediately. If it does not, no value moves and connected Send remains available.

Receiz Certified

Compatibility, proven at the device boundary.

Device manufacturers can implement the Receiz custody law and certify exact model and firmware profiles against the same executable corpus. Certification guarantees Offline Note compatibility; it never weakens the law or creates a different class of Note.

Executive summary
  • Portable settlement instrument with strict redemption rules.
  • File-native transfer path with cryptographic verification.
  • Local verification gates claim acceptance; invalid, conflicting, or replayed transitions hard-fail.
  • The accepted local claim is Settlement. Later account posting or global sync distributes that settled truth; it does not create it.
  • Every Offline Send irreversibly consumes the exact current head before one whole-value successor is released.
  • If a device cannot prove that transition law, it cannot create or Offline Send a Note.
Send policy

Cash by default. Identity only when the sender chooses it.

Both policies preserve the same Note, whole-value conservation, exact-head consumption, and canonical verification. Optional identity changes who may activate one successor; it never changes what makes the Note spendable.

Default

Cash Send

The Note moves whole from one qualified custody boundary to the next. No person, username, Receiz ID, account, session, server, or database is required for the offline transfer.

Optional advanced policy

Identity-Locked Send

A sender may require the named identity to activate one handoff. That condition cannot create value, cannot consume the current head, cannot select the lawful branch, and cannot authorize a second Send. Qualified irreversible custody still performs every value-bearing transition. Current PWA activation support remains unavailable until its executable contract passes release conformance.

Normative requirements
O-001

Offline note packets SHALL persist `amountUsdCents`, `amountPhiMicro`, and `usdPerPhiMicrocents` together.

O-002

Note creation SHALL verify the exact local account-state and Reserve heads, consume the qualified Reserve head once, and admit one equal-value Reserve-debit account successor together with one held-bound Note genesis before releasing either successor.

O-003

Optional ownership publication SHALL canonically verify the complete sealed artifact before projecting its ownership head.

O-004

Invalid, missing, or conflicting Note states SHALL block optional ledger credit without changing accepted local Settlement.

O-005

Posted note events SHALL remain replayable from persisted integer value fields and rate snapshot.

O-006

Private and public ledger surfaces SHALL preserve the accepted local Settlement when projecting a Note claim.

O-007

Conflicting Note transitions SHALL follow verified Kai order, predecessor binding, custody authority, and replay protection; server append order cannot replace that proof-domain order.

O-008

Every transferable Note head SHALL bind to one anonymous qualified custody commitment. Identity, username, account, session, and server state SHALL NOT be Offline Send authority.

O-009

Global publication SHALL preserve every verified competing artifact as evidence, use causal reconciliation rather than arrival order, and never create Settlement.

Execution sequence
  1. Before Offline Note funding becomes spendable Reserve, the external funded event is sealed against the exact receiz.account.state.v3 predecessor and a preselected qualified Reserve-custody commitment. Legacy or unbound Reserve cannot enter this path.
  2. The creator installation proves qualified irreversible Note and Reserve custody, then verifies that exact account proof, sealed funding binding, and current funded Reserve head.
  3. One irreversible local transition binds the exact Reserve subtraction to an equal whole-value held-bound Note genesis. Both sealed successors are canonical-verified and admitted together; no server releases either proof object.
  4. The creator PWA activates that exact Note genesis in qualified custody, commits the successor Reserve head, and only then releases the sealed Note file.
  5. For a transfer, the next installation supplies one anonymous qualified custody commitment.
  6. The sender verifies its active exact head, irreversibly consumes that exact authority, and seals the whole-value successor to the next custody commitment.
  7. The recipient verifies and activates the successor locally. Settlement is complete; no server, database, or chain is required.
  8. Optional publication later projects verified ownership history. Siblings remain evidence and deterministic capacity reduction admits one value branch.
  9. Qualified consumer profiles and Receiz Certified devices satisfy the same binary transition law. Certification guarantees compatibility; it does not create a different Note.
Packet contract shape
{
  "kind": "kairos_note_packet_v2",
  "noteId": "...",
  "noteToken": "...",
  "amountPhiMicro": "...",
  "amountUsdCents": "...",
  "usdPerPhiMicrocents": "...",
  "noteState": "held_bound",
  "holderCustodyCommitmentDigest": "...",
  "holderInstallationCommitment": "...",
  "predecessorArtifactSha256": null,
  "acceptedAtKai": "..."
}
Claim authority policy
  • The accepted local claim at the deterministic Kai Pulse is Settlement. Its verified append-only history is complete without a server, database, or global sync.
  • Verified Kai order, predecessor binding, custody authority, and replay protection govern conflicting Note transitions.
  • Optional server publication coordinates wider discovery and account projection beneath already-settled local truth.
  • Offline Send irreversibly consumes the exact active authority before releasing one successor; replay and restored state fail closed.
  • The anonymous next-custody commitment binds one successor to one qualified installation without making identity or username authoritative.
  • Receiz Certified is the device-manufacturer compatibility program for guaranteed implementation of the same universal custody law.
Claim-to-code traceability
ReqSource Route / FunctionVerification Method
O-001app/lib/wallet/kairosOfflineCashBrowserRuntime.ts, app/lib/wallet/kairosNoteArtifact.tsMinted packet includes amount and quote tuple fields required for deterministic replay.
O-002packages/receiz-sdk/src/offlineReserveFundingBinding.ts, app/lib/wallet/kairosOfflineCashFundingArtifact.server.ts, app/lib/wallet/kairosOfflineCashBrowserRuntime.ts, app/lib/wallet/kairosOfflineNoteLocalIssuance.ts, app/lib/wallet/kairosNoteQualifiedGenesisClient.ts, app/lib/wallet/kairosReservePwaCustodyAdapter.tsThe sealed funded event binds the exact account predecessor and preselected custody before the verified Reserve subtraction, equal Note value, canonical Note artifact, and irreversible Reserve receipt are admitted locally and released.
O-003app/api/wallet/notes/status/[noteId]/[proof]/publish/route.ts, app/lib/wallet/kairosNoteOwnershipPublicationServer.tsThe installed canonical verifier admits the complete portable Note before subordinate publication.
O-004app/lib/wallet/kairosNotePortableCarrier.ts, app/lib/wallet/kairosNoteReceiver.tsInvalid artifact truth, broken history, wrong custody, stale heads, and consumed predecessors fail without changing local Settlement.
O-005app/lib/wallet/amounts.ts, app/api/wallet/ledger/route.tsReplay can recompute deterministic value outcomes from persisted integer fields + rate tuple.
O-006app/api/wallet/ledger/route.ts, app/api/wallet/ledger/public/route.tsIdentity visibility differs by route while value/proof semantics remain compatible.
O-007app/lib/wallet/kairosNoteLocalTransition.ts, app/lib/wallet/kairosNoteOwnershipPublicationServer.tsCausal reconciliation and whole-value subtraction are invariant to candidate upload order; every sibling remains preserved evidence.
O-008packages/receiz-sdk/src/offlineNoteAttestedCustody.ts, packages/receiz-sdk/src/offlineNotePlatformAttestation.ts, app/lib/wallet/kairosNotePwaCustodyAdapter.tsThe anonymous next-custody commitment identifies one automatically attested, rollback-conformant installation boundary without introducing person or account authority.
O-009app/api/wallet/notes/status/[noteId]/[proof]/publish/route.ts, app/lib/wallet/kairosNotePortableCarrier.tsOptional publication accepts only canonically verified complete Note artifacts and remains a discoverability projection beneath the already-settled file-carried history.
Capability comparison
Portable transfer medium
Offline note

Sealed file packet (PNG/PDF/JSON) with embedded settlement contract fields.

Legacy offline handoff

Payment message, screenshot, or reference code with no verifiable payload contract.

Ownership publication
Offline note

Canonical verification gates optional global ownership-head projection after local Settlement is complete.

Legacy offline handoff

Manual interpretation and reconciliation across fragmented systems.

Deterministic replay
Offline note

Ledger replay from persisted integer value tuple and rate snapshot.

Legacy offline handoff

Post-hoc reconstruction from inconsistent logs and mutable references.

Audit continuity
Offline note

One append-only settlement trail from issuance to claim.

Legacy offline handoff

Split evidence across channels with continuity gaps.

Open Settlement AccountPublic LedgerOffline SettlementDownload Offline Claim-Bundle InspectorSettlement MathTransfer RunbookLedger Contract