Z00Z objects move through more than one authority layer. A private object can be created or recognized in a wallet, exchanged locally, prepared as a package, published through a batch path, validated against checkpoint roots, challenged under a liability path, disclosed to a specific reviewer, archived by the actor that needs records, or redeemed through an external issuer or service. Treating all those events as one generic “transaction” hides the most important part of the protocol.

The safe mental model is a lifecycle. The wallet owns local recognition and possession. The publication path owns handoff into public evidence. The checkpoint boundary owns canonical settlement. Watchers and validators own observability and verification signals. Issuers, bridges, auditors, and enterprises own service-layer promises and long-lived records.

Lifecycle Containers

The diagram is intentionally layered. It shows that a wallet-held object can be economically meaningful before final settlement, but canonical acceptance still belongs to the checkpoint layer. It also shows that external redemption or service records are outside the protocol core.

State Flow

This lifecycle is broad enough to cover assets, vouchers, rights, payment requests, claims, offline receipts, and external-asset rights without pretending they are all the same object. It also preserves the maturity boundary: some states are live core surfaces, while others are target overlays or service responsibilities.

Creation And Eligibility

Creation begins with a source of authority. For a native asset, the source is the protocol’s asset and settlement grammar. For a claim, the source is a pre-authorized claim context. For a voucher, the source is reserved or consumed value plus a voucher policy. For an external-asset right, the source may be a deposit, burn, attestation, custody slot, issuer decision, or service event outside Z00Z.

The important rule is that source meaning must not become vague. An externally backed right, an issuer-native unit, a synthetic unit, and native Z00Z cash can all move through private settlement mechanics, but they do not carry the same external promise. That source identity must remain available to the wallet and evidence path through asset-family metadata, policy identity, claim context, or service records.

Wallet-Local Holding

Holding is wallet-local before it is public narrative. The wallet recognizes objects through local keys, receiver material, scan state, package imports, and recovery context. It may show a user spendable inventory, conditional voucher inventory, authority rights, pending claims, or imported requests. Those views are useful, but they are not a public account table.

Wallet-local holding creates responsibilities. The wallet must protect secrets, avoid unsafe receiver reuse, separate final value from conditional value, quarantine unknown policies, and preserve enough local records to reconcile later. If the wallet loses the local material, the network cannot magically reconstruct every private meaning from public checkpoints.

Movement And Publication

Movement happens through packages. Ordinary movement uses a transfer candidate such as TxPackage; claim movement uses claim-domain package context; receiver-native workflows use request material that constrains how a recipient accepts or interprets the object. A package can be valid enough for wallet handling before it is final enough for settlement.

Publication then turns package material into public evidence. Aggregators order work, build publication artifacts, send bytes to a DA path, and expose soft confirmations or provider records. These signals matter for operations and recovery, but they do not replace checkpoint authority. A published object becomes authoritative only after checkpoint validation binds roots, deltas, proofs, and replay conditions.

Challenge And Liability

Conflict is a lifecycle branch, not a normal disclosure mode. Linked Liability describes how delayed or offline rights can remain private in the honest case while becoming attributable after provable conflict. The conflict branch should reveal only the domain, proof, and recovery path needed for the disputed right family.

That is why the lifecycle includes challenge, lock, and resolution states. A conflict may produce a fraud proof, activate a liability domain, freeze selected future rights, route compensation, or reject the proof if it is incomplete. It should not reveal unrelated assets or turn every wallet object into an account-level punishment surface.

Disclosure, Archive, And Redemption

Disclosure is scoped. A user, enterprise, auditor, issuer, bridge, or regulated service may need an evidence package, disclosure package, audit receipt, or corporate archive. Those artifacts should show the selected facts and bind them to settlement evidence without creating a universal protocol backdoor.

Archive and redemption are also layer-specific. A corporate archive is retained by the company or service that needs records. A bridge or issuer owns external redemption. A merchant owns acceptance and refund policy. The protocol can prove internal settlement state. It cannot by itself prove every foreign reserve, support promise, tax record, or customer relationship.

Closeout Review Notes

Use lifecycle language when a page is tempted to say that an object simply “exists” or “moves.” A private object has stages: creation, local recognition, package construction, publication, checkpoint validation, optional disclosure, archive, redemption, challenge, or retirement. Skipping the stage often creates the wrong claim. For example, a locally recognized voucher is not the same as a settled asset. A disclosed audit package is not the same as public ownership history. A challenged offline right is not ordinary use.

The lifecycle view also keeps future integrations honest. A bridge can introduce deposit and redemption stages. A merchant can introduce refund stages. A machine-agent flow can introduce authorization and liability stages. Those stages may be valid product behavior, but they should not be described as if the base protocol owned every business rule. The page is complete only when lifecycle state and responsibility owner move together.

A closeout sweep should prefer lifecycle verbs over vague status labels. “Imported,” “published,” “settled,” “disclosed,” and “redeemed” teach more than a generic “done” state, and they reduce support confusion when users compare wallet state, public artifacts, and service records.

Read Next

• Settlement Model for the canonical checkpoint boundary.
• Assets, Vouchers, And Rights for object categories.
• Receiver Flow for local acceptance and refund boundaries.
• Selective Disclosure for scoped evidence and non-knowledge boundaries.

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-8 define canonical state objects, checkpoints, rollup publication, wallet-local possession, privacy, external assets, and scaling boundaries.
• Assets, Rights, And Vouchers Whitepaper sections 3-9 define the asset, voucher, right triad and lifecycle boundaries for conditional value and authority.
• Linked Liability Whitepaper sections 3-6 define liability domains, hidden liability commitments, fraud proofs, locks, bonds, and penalties.
• Cross-Chain Integration Whitepaper sections 3-7 define integration objects, locker lifecycle, external custody, data availability, and service composition.