Wallet-local possession is the category difference behind Z00Z. A user owns because their wallet can recognize, decrypt, verify, store, and later spend a confidential object under canonical settlement state. Checkpoints remain authoritative for finality, but private meaning stays in the wallet.
This design changes custody, payments, rights, recovery, and privacy. It makes
the wallet role more important than a public account browser, and it makes
wallet safety part of protocol comprehension. z00z_wallets is the open-source
reference/demo implementation; a compatible custom wallet may use a different
internal design while preserving the canonical network-facing contract. The
Wallet SDK
owns the technical compatibility rule.
Wallet Object Map
The map shows that possession is an active local process. The wallet combines secrets, receiver material, package verification, and recovery state to decide what the user can hold or spend.
Possession Versus Custody
In the reference wallet’s self-custodial design, the user controls the relevant keys and the wallet processes local possession material. Actual custody, recovery, account, and service responsibilities depend on implemented control and operations; the wallet label does not decide them. The network cannot reverse lost keys or reconstruct local history it never received.
This is why wallet backup and recovery are protocol-adjacent duties. A wallet must preserve enough scan, key, package, and recovery context to continue recognizing owned objects. The base protocol is not a universal recovery custodian.
Receiver Acceptance
Receiving is not passive. Receiver cards and payment requests give the sender bounded material for one workflow. The receiver wallet must then verify the incoming object, classify the object family, quarantine unknown policies, and decide whether local acceptance is enough or whether the user should wait for settlement.
That is especially important for vouchers and rights. Final cash, conditional value, and authority should not all appear as the same balance. A receiver who imports a voucher has a conditional claim. A receiver who imports a right has authority. A receiver who imports native cash has final value after settlement. Wallet UX should keep those categories distinct.
Offline Use
Offline or delayed use works because wallet-local possession can be meaningful before final publication. Two parties may exchange packages, receipts, or receiver material while disconnected. The receiver can perform local checks and accept bounded risk. Later publication and checkpoint validation decide whether the object is settled.
This creates an arbitration window. During that window, a local object may be useful but not final. Linked Liability, refunds, fraud proofs, and dispute flows exist because delayed reconciliation can expose conflicts that were not visible at handoff time.
Selective Disclosure
Because the wallet owns private meaning, it is also the natural place to build scoped disclosures. A wallet can reveal a selected transaction, period, asset family, invoice link, audit view, or dispute proof without revealing the entire inventory. That is the difference between disclosure and a public account graph.
The wallet must also protect users from over-disclosure. A broad support export, repeated receiver surface, verbose logs, or careless audit package can undo protocol privacy even when checkpoint evidence remains narrow.
What The Network Can And Cannot Restore
The network can provide public roots, deltas, checkpoint evidence, publication artifacts, and verification signals. It can show that a transition was valid or invalid under public rules. It cannot recover local secrets, recreate memos never stored publicly, identify every object a wallet could have recognized, or prove external service promises by itself. This technical limit does not imply that a reference or custom wallet, counterparty, or service has no records; see the Compliance Framework.
That boundary is not a weakness. It is what keeps the protocol from becoming a public account archive.
Backup And Recovery Discipline
Wallet backup is not only a seed phrase topic. A practical Z00Z wallet may need derivation material, scan progress, receiver-card history, imported packages, disclosure artifacts, local labels, and recovery metadata. Some of those records are sensitive. Some are necessary to reconstruct ownership. Some should never be exported broadly.
A good wallet should therefore separate recovery material by sensitivity and purpose. It should help the user preserve what is needed for future recognition without turning backups into plaintext economic histories. It should also communicate when recovery is partial: a restored wallet may find settlement objects, but it may not recover every memo, invoice, local label, support context, or scoped disclosure package unless those records were backed up.
Service Boundary
Wallet-local possession is not the same as hosted custody. The integral Z00Z wallet role helps the user control local objects, and a reference or custom implementation may realize it. The user controls keys, local settings, records, history, backups, receipts, disclosures, and the user’s own conduct. Reference-wallet, custom-wallet, hosted-custody, onboarding, recovery, signing, and other service operators retain duties arising from the functions, interfaces, data, profiles, claims, and services they distribute, operate, or control. Self-custody does not shift those operator duties to the user. The Compliance Framework owns the canonical rule.
This distinction affects docs language. Use “Z00Z wallet role” for the required
architectural component, and identify z00z_wallets as the reference wallet or
name a custom implementation when implementation identity matters. State local
control separately from operator responsibility. Say
“independent service provider” only when the facts support separation. Do not
imply that the base protocol opens customer accounts merely because a wallet
makes private objects usable.
Practical UX Requirements
The wallet should make object state visible without leaking more than necessary. It should show whether an item is detected, imported, locally accepted, pending publication, settled, disclosed, archived, quarantined, or rejected. It should distinguish final cash from vouchers and rights. It should warn about receiver reuse, broad audit exports, exact-value exits, and unsupported policies.
Those are not optional UX niceties. They are how the user sees the difference between local possession and final settlement.
Developer Anti-Patterns
Avoid rebuilding a public account model in wallet code. Do not use one stable receiver surface for every workflow, do not export complete local history as a support shortcut, do not merge unrelated objects only because it simplifies UI, and do not show vouchers or rights as ordinary balance. Each shortcut makes implementation easier by weakening the very boundary the protocol is trying to preserve.
Developers should also avoid hiding state transitions behind generic labels such as “pending” without explanation. A package can be pending local acceptance, pending publication, pending checkpoint verification, pending redemption, or pending refund. These are different states with different risks.
Claim Boundaries
Wallet-local possession should be reviewed as both a privacy feature and a support boundary. It gives users useful local control before public settlement exposes unnecessary detail, but it also means the wallet carries responsibilities that the network cannot replace. If a wallet loses secrets, labels, scan state, receiver history, or disclosure artifacts, the checkpoint record may not be enough to recreate the user’s full local context.
Support, recovery, and developer docs must preserve the same boundary. Support should ask for public-safe evidence, not secrets. Recovery guidance should avoid implying a hidden service switch. Developer examples should not serialize private wallet state as ordinary debug output. Product language should not call a reference wallet a managed account service. Local possession can keep private meaning out of the public ledger when the wallet protects the right material.
Wallet-local state is an authority surface, not an incidental cache. It includes the material that defines receipt, policy interpretation, private history, and the user’s ability to prepare a later settlement transition. Losing it can remove access to a right; oversharing it can expose information that public settlement never revealed. Wallet backup, device security, recovery procedure, and support handling therefore remain part of the security boundary rather than ordinary convenience features. The boundary remains personal and non-delegable by default.
Read Next
- Receiver Flow for local acceptance and quarantine.
- Settlement Model for finality after local possession.
- Selective Disclosure for wallet-built evidence packages.
Evidence and Further Reading
- Main Whitepaper sections 3 and 5 define canonical state objects, wallet-local coins, no-address ownership, offline representation, and wallet responsibilities.
- Smart Cash sections 4-8 define client-side state-machine objects, bounded object-local rules, and supported smart-cash families.
- Privacy Threat Model And Metrics section 7 defines wallet UX requirements, safe defaults, and privacy QA hooks for wallet behavior.