Wallet-Local Possession

Wallet-local possession is the category difference behind Z00Z. A user does not own by pointing to a reusable public address row. A user owns because their wallet can recognize, decrypt, verify, store, and later spend a confidential object that still exists under canonical settlement state. Public checkpoints remain authoritative for finality, but the wallet remains the place where private meaning is discovered.

This design changes custody, payments, rights, recovery, and privacy. It makes the wallet more important than a public account browser, and it makes wallet safety part of protocol comprehension.

Wallet Object Map

flowchart TD Secrets["Wallet secrets\nscan and spend material"] --> Detect["Detect owned objects"] Receiver["Receiver cards\npayment requests"] --> Detect Packages["Imported packages\nTxPackage or ClaimTxPackage"] --> Verify["Local verification"] Detect --> Inventory["Local inventory\nassets, vouchers, rights"] Verify --> Inventory Inventory --> Spend["Build outgoing package"] Inventory --> Disclosure["Build scoped disclosure"] Inventory --> Backup["Backup and recovery state"] Spend --> Public["Publication and checkpoint path"] style Secrets fill:#EDE7F6,stroke:#5E35B1,stroke-width:1px,color:#311B92 style Receiver fill:#E3F2FD,stroke:#1E88E5,stroke-width:1px,color:#0D47A1 style Packages fill:#ECEFF1,stroke:#546E7A,stroke-width:1px,color:#263238 style Detect fill:#F3E5F5,stroke:#8E24AA,stroke-width:1px,color:#4A148C style Verify fill:#FFF3E0,stroke:#FB8C00,stroke-width:1px,color:#E65100 style Inventory fill:#E8F5E9,stroke:#43A047,stroke-width:1px,color:#1B5E20 style Spend fill:#F3E5F5,stroke:#8E24AA,stroke-width:1px,color:#4A148C style Disclosure fill:#FFE0B2,stroke:#F57C00,stroke-width:1px,color:#263238 style Backup fill:#ECEFF1,stroke:#546E7A,stroke-width:1px,color:#263238 style Public fill:#E3F2FD,stroke:#1E88E5,stroke-width:1px,color:#0D47A1

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

Self-custody means the user or wallet controls keys and local meaning. It does not mean the network can reverse lost keys, reconstruct hidden history, or act as a hosted account provider. If a user loses wallet material, the public checkpoint record may still prove that objects existed or were consumed, but it may not contain enough information to rebuild every private inventory entry.

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.

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 optional disclosure package unless those records were backed up.

Service Boundary

Wallet-local possession is not the same as hosted custody. A reference wallet can help the user control local objects. A hosted wallet or regulated provider may add service duties, support records, onboarding, recovery promises, or compliance controls. Those duties belong to that service, not to the base protocol.

This distinction affects docs language. Say “reference wallet” when the project provides software. Say “service provider” when an actor holds records or adds compliance obligations. Do not imply that the protocol itself opens customer accounts just because wallets make 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.

Closeout Review Notes

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.

That is why this page should shape support, recovery, and developer docs. 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 if it were ordinary debug output. Product language should not call a reference wallet a managed account service. The strongest wallet claim is narrow and practical: local possession can keep private meaning out of the public ledger when the wallet protects the right material.

The closeout sweep should also reject any flow that treats “wallet-local” as “unimportant.” Local state is where the user’s private meaning lives, so losing or oversharing it can be as harmful as a protocol bug.

Evidence and Further Reading

Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.

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.

Z00ZBlockchain