Foundation 06 · Verification without permission
Offline operation
Offline operation is the primitive. Proof, Identity, Ownership, authorship, value, and Settlement execute from carried truth; servers and databases only synchronize verified additions beneath it.
What this enables
The solved state
Record, seal, preserve, inspect, and verify proof objects without network authority. On a qualified custody installation, create, receive, settle, and resend whole-value Offline Notes without an external witness.
Governing statement
Verification travels with the artifact
Offline verification validates the sealed artifact from its carried proof material. Network and server systems may distribute verified objects and successors later; they do not grant the artifact its existing truth and do not append to the proof object by distributing it.
The artifact brings the evidence needed for verification. A connection can help discover more verified history, but the connection is not the original authority.
- What was broken
- Server-dependent records become unusable or unverifiable when an account, service, or network is unavailable.
- What is established
- The sealed artifact and verifier establish the proof boundary locally.
- What you can do now
- You can inspect and verify supported artifacts directly from their bytes without waiting for a service response.
- Why it matters
- The proof object and its carried verification material remain available to the person who holds it instead of becoming permission rented from an online system.
The offline verifier reads a sealed artifact, recomputes integrity, and reports the verification result without requiring a signed-in session.
docs/offline-verified-register.mdapp/lib/documentSeal/offlineSeal.tspackages/receiz-sdk/src/artifactVerification.ts
Governing statement
Offline truth does not wait to become real
Offline authorship and accepted local transitions create causally identified truth. Later global sync may publish or distribute that already-settled truth; it does not create, confirm, complete, or revoke the local result.
Work can happen without a connection and remain complete without one. If the holder later connects, sync can reveal verified additions to more participants. The server and database are optional global coordination, never permission for local existence.
- What was broken
- Offline work is often treated as an inferior temporary copy that can be discarded or overwritten during reconnection.
- What is established
- Deterministic Identity, Kai causality, local verification, and append-only history preserve the offline event as settled proof truth.
- What you can do now
- You can complete supported work locally, continue from it immediately, sync it later, or never sync it.
- Why it matters
- Connectivity changes who else knows the truth and when. It does not decide whether the accepted local event happened.
An offline-sealed successor is admitted and used immediately. Optional publication later distributes the same already-admitted append globally without changing its identity, Kai order, proof head, or local verdict.
docs/verified-history-first-principles.mddocs/superpowers/specs/2026-07-28-v114-5-offline-publication-release-design.mdapp/lib/documentSeal/__tests__/offlineStudioV115CaptureSigningContract.test.tsapp/components/pwa/__tests__/offlineAppendProjectionContract.test.ts
Governing statement
One held Note head becomes one whole-value successor
A transferable Offline Note begins from the verified receiz.account.state.v3 Receiz Key/Identity proof that carries Reserve. The external funded event is first sealed into receiz.offline-reserve.funding-binding.v1 against that exact account head and a preselected qualified Reserve-custody commitment; legacy or unbound Reserve cannot enter Offline Note issuance. Local issuance composes one Reserve-debit account-state successor and one qualified held-bound whole-value Note genesis, canonical-verifies both successors, then activates that exact Note genesis in qualified irreversible custody. Supabase, server, database, session, and publication may project the verified successors later; they never gate release, authorize issuance, establish Settlement, or replace either proof object. Server and database are not transition authority. Cash Send is the default and requires no identity: every Offline Send canonical-verifies the exact held head, consumes that head once inside its qualified custody slot, binds the complete successor basis to one anonymous qualified next-custody commitment, preserves the whole value, seals one canonical successor, and permanently retires the predecessor's Send authority. The recipient canonical-verifies and activates that exact successor locally. Activation completes Settlement; later publication only distributes the already-settled history.
Note value is subtracted from the carried Reserve proof at the edge, not released by a service. The locally verified account successor proves the Reserve debit; the canonically verified held-bound Note genesis proves where that same whole value went. The receiver later supplies an anonymous qualified custody commitment, not an identity. The sender's qualified slot can authorize the exact current Note head only once and commits the receiver, predecessor, whole value, Kai position, and successor basis before the successor leaves the sender. The recipient accepts only the successor addressed to that qualified slot. Once activated, the recipient holds the only active Send position and can repeat the same whole-value handoff. A copied or previously consumed predecessor remains authentic history, but it has no Send authority.
- What was broken
- Ordinary digital money becomes unusable when the payment service, account database, chain connection, or network disappears.
- What is established
- The verified account/Identity proof carries the Reserve source; local issuance appends its exact debit and the qualified held-bound Note genesis together. The Note then carries its value proof, exact predecessor, Kai order, anonymous custody handoff, one-use consumption evidence, whole-value ownership history, and canonical verification material with the object itself.
- What you can do now
- On a qualified installation, you can subtract Reserve locally from the verified account proof, activate the canonically verified whole-value Note genesis, hand its whole value to another qualified custody slot, complete Settlement, and send it again without a network or external witness.
- Why it matters
- Money becomes a held proof object instead of remote database permission. A former holder can retain or copy historical bytes, but cannot recover the consumed transition authority that moved the value forward.
A verifies the receiz.account.state.v3 proof carrying Reserve, locally appends a Reserve-debit successor and its whole-value held-bound Note genesis, verifies both, and activates that exact Note in qualified custody. B then creates an anonymous receiving-custody commitment and gives it to A. A canonical-verifies the held Note, irreversibly consumes its exact head, and seals one whole-value A → B successor bound to B's commitment. B verifies and activates those exact bytes locally; Settlement is complete. A's predecessor remains verifiable evidence but cannot Send. B may later repeat the same sequence to C. No server releases the Note, chooses the owner, or completes either transition; optional publication only makes the verified chain globally discoverable.
packages/receiz-sdk/src/identity.tsapp/lib/auth/receizKeyLocalExport.tsapp/lib/auth/receizAccountStateHead.tspackages/receiz-sdk/src/offlineNoteIrreversibleCustody.tspackages/receiz-sdk/src/offlineNoteWebAuthnCustody.tsapp/lib/wallet/kairosNoteQualifiedCustodyTransition.tsapp/lib/wallet/kairosNoteBoundGenesisArtifact.tsapp/lib/wallet/kairosNotePwaCustodyAdapter.tsdocs/verified-history-first-principles.md
The category break, end to end
Money no longer waits for a network.
The Note is not a payment message waiting for a database to honor it. It is the sealed whole-value instrument. Qualified irreversible custody and canonical verification let the receiver activate the exact successor locally; that activation is Settlement.
- 01
Verify carried Reserve
Canonical verification opens the receiz.account.state.v3 Receiz Key/Identity proof and its exact current Reserve head.
- 02
Subtract and seal locally
One local issuance composes the Reserve-debit account successor and the equal whole-value held-bound Note genesis, verifies both, then activates that exact Note in qualified custody.
- 03
Prepare anonymous receipt
The receiver creates a qualified next-custody commitment. Cash Send needs no username, Receiz ID, account, session, server, or database.
- 04
Consume once and seal
The sender canonical-verifies and irreversibly consumes the exact held head before sealing one whole-value successor to the receiver commitment.
- 05
Deliver and activate
Send the verified successor by direct file transfer, email, QR transport, or any file channel. The receiver verifies and activates those exact bytes locally.
- 06
Settlement is complete
Receiver activation is complete local Settlement. No live payment rail or external witness is required.
- 07
Hold or send again
The receiver now controls the successor’s one-use custody position and can repeat the same whole-value transition to another qualified installation.
- 08
Publish later—or never
Settlement is already complete. A later sync may make the transition globally discoverable, but it does not create, confirm, complete, or revoke the local Settlement—and the parties never have to sync.
What travels in the Note
The receiver gets the whole-value proof object, not a promise.
- Exact value and value-source state
- Stable Note and artifact identity
- Qualified one-use custody evidence
- Kai Pulse and deterministic order
- Provenance and predecessor head
- Anonymous next-custody commitment
- Whole-value canonical successor basis
- Integrity and verification material
- Consumption, activation, and replay rejection
Authority split
Local Settlement is complete. Global knowledge is optional.
- The file
- Carries the value-bearing proof object and the exact state being transferred.
- Kai Pulse
- Places the verified transition in deterministic causal order.
- Qualified custody
- Consumes the exact predecessor once and binds the whole-value successor before release.
- Local verifier
- Verifies or rejects the successor and its carried receipts from the evidence in hand.
- Server / database / chain
- May publish, index, reconcile, or distribute later. They do not manufacture the Settlement.
Why the old holder cannot spend you out of the history
The old holder cannot erase the next holder.
A successor does not edit its predecessor. The qualified custody position consumes the exact held head once, binds the anonymous next-custody commitment and complete whole-value successor basis, and releases only the canonically verified successor. The old file remains authentic historical proof without Send authority.
- B prepares qualified custody
B creates an anonymous receiving-custody commitment from a profile whose physical one-use behavior has passed the normative conformance vectors.
- A → B
A verifies the exact Note head, binds B’s commitment and the complete whole-value successor basis, irreversibly consumes A’s custody position, then seals and verifies one successor.
- B activates
B verifies that the successor, predecessor, whole value, Kai position, consumption receipt, and receiving commitment all agree. Activation completes local Settlement.
- A → X is rejected
A’s predecessor remains authentic history, but its exact custody position is consumed. Copying, renaming, wrapping, restoring, reinstalling, uploading, or reverifying those bytes cannot recreate Send authority.
- B → C
B can consume B’s exact successor head once and seal the next whole-value successor to C’s anonymous qualified custody commitment.
The exact boundary: an installation qualifies only when its registered physical profile proves non-backup exact-head consumption, rollback rejection, crash-safe retirement, and portable signed evidence under the normative vectors. Generic WebAuthn, software storage, browser branding, or a caller-supplied label is not enough.
What the receiver proves before accepting
You receive the money and the complete reason it is yours.
The verifier does not ask B to trust A’s screen, message, session, or server. It walks from the verified account/Identity proof and local Reserve-debit successor through the held-bound genesis and exact consumed predecessor to the whole-value successor B is activating.
- The value is exact
The verifier binds the whole-value Note genesis to the locally verified Reserve-debit successor of the receiz.account.state.v3 proof.
- The sender had the current head
The successor names and verifies the exact predecessor artifact and proof-history head it consumes.
- This successor is for this custody
Your anonymous qualified receiving commitment is bound before predecessor consumption. Identity is optional policy, never value or transition authority.
- Your exact bytes become live custody
Only activation through the matching qualified custody position admits the successor. A forwarded file remains verifiable but cannot silently activate elsewhere.
- The former holder is spent locally
The Send consumes the predecessor’s exact one-use custody authority before the canonically verified successor can be released.
- No sibling can be authorized
The qualified physical custody position cannot produce a second valid consumption from the same exact head. Publication order has no authority because there is no second authorized successor to choose.
The receiver-safe conclusion: on a qualified installation, the activated file is a real value-bearing Note, not an IOU or pending payment message. Its exact predecessor was consumed once, its value remained whole, and no external witness selected the successor. An unqualified installation can still Verify and use the separately governed connected Send route, but it cannot create, receive, activate, or Offline Send a transferable Note.
What this unlocks now
Anywhere files can move, supported value can move.
Dead-zone commerce
Exchange a verifiable value instrument where terminals and payment networks cannot reach.
Asynchronous delivery
Seal the successor to an anonymous qualified custody commitment now, then deliver those exact bytes by email or file whenever the receiver is ready.
Resilient operations
Keep value moving through outages, disasters, remote work, travel, or deliberate network separation.
Private local circulation
Complete supported transfers locally and choose whether the settled history ever needs wider publication.
Portable custody
Move value between devices and holders while retaining exact origin, order, and successor continuity.
Cash Image
Carry encrypted spend authority, transfer it by Kai Pulse, and reconcile with a chain only if and when required.
One qualification law
A consumer PWA profile or Receiz Certified Device qualifies only by proving the same irreversible exact-head consumption law. Commercial participation never purchases a passing result.
Governing statement
Existing money can become an offline proof object
Cash Image carries encrypted spend authority in a bearer proof object, transfers offline through a separately verified custody and provenance successor bound to the exact held Cash Image head and Kai Pulse, rotates custody into that verified successor, and treats later chain reconciliation as optional coordination beneath the already-admitted transfer.
Value that began on a chain can leave the chain interface as a held object. The current holder can pass it to the next holder offline; the predecessor becomes spent, the successor receives protected authority, and the causal transfer remains verifiable before any chain reconciliation occurs.
- What was broken
- Crypto ownership is usually trapped behind wallet software and live chain access even when the value itself is supposed to be bearer-controlled.
- What is established
- Encrypted spend authority, bearer state, Kai Pulse transfer, exact-head custody and provenance succession, predecessor spend state, and successor rotation travel as one proof-native value object.
- What you can do now
- You can upgrade supported value into a Cash Image, verify it offline, transfer it by Kai Pulse, and give the recipient a new protected successor before optional chain reconciliation.
- Why it matters
- The chain becomes a reconciliation rail rather than permission to possess, inspect, or locally transfer the carried value object.
A Cash Image moves in person while both parties are offline. The separately verified successor binds the exact held head, recipient, and Kai Pulse, marks the issuer object spent, rotates encrypted authority into recipient custody, and can reconcile on-chain later without rewriting the offline transfer.
app/lib/proofObjects/cashImage.tsapp/lib/proofObjects/__tests__/cashImage.test.tsdocs/releases/v83.0.0-product-truth.md