Z00Z settlement is checkpoint-bound. A wallet can hold an object locally, a sender can prepare a package, an aggregator can publish a batch, and a DA provider can store bytes before the protocol treats the transition as authoritative. Finality appears only when canonical objects, replay references, roots, proof payloads, and checkpoint links agree.

This staged model is why Z00Z can be private without being vague. Public settlement evidence is narrow, but it is still strict. The chain does not need a global public account table. It needs typed leaves, paths, packages, roots, deltas, and proofs that let validators reject inconsistent transitions.

Canonical Settlement Objects

These objects are the settlement vocabulary. Wallet balances, UI history, issuer support tickets, and corporate accounting views are derived or service-layer views around them.

Root Continuity

The root path is the settlement theorem in reader form. The protocol starts from a previous root, consumes specific paths, creates specific leaves, checks proof material, derives a new root, and binds that result to a checkpoint artifact. If any relation breaks, finality does not exist.

What Becomes Canonical

Canonical settlement is not the same as every fact a user or service knows. What becomes canonical is the public state transition: which committed objects were consumed, which new objects were created, which roots changed, which replay surfaces were exercised, and which proof-bearing package supported the transition.

What does not become canonical is equally important. The chain does not become a hosted wallet, issuer ledger, customer record, bridge reserve proof, tax archive, or complete private history. Those facts may exist in wallets or services, but they are not part of the base settlement theorem unless a specific disclosure or service workflow adds them outside the core.

Replay Safety

Replay safety belongs to storage, roots, package discipline, and flow-specific anti-replay records. A live right is not merely a number in a balance row. It is a committed object whose canonical path either remains present or is consumed through a valid transition. Claim flows may add claim nullifiers or claim replay rows. Ordinary spend flows may include nullifier-like proof fields. Those mechanisms help prevent repeated use, but they do not replace the broader root-coupled object model.

This is why the docs avoid saying “one nullifier list explains everything.” Z00Z uses typed replay boundaries: object presence, consumed paths, claim replay records, package integrity, and checkpoint linkage all contribute.

What Evidence Proves

Settlement evidence proves a transition was accepted under Z00Z’s rules. It can show package integrity, proof payload binding, root continuity, created and consumed object sets, checkpoint identity, and publication-recovery references. It cannot prove that an external issuer has reserves, that a bridge will redeem, that a merchant will provide service, or that a corporate archive retained every required record.

That distinction protects both protocol accuracy and legal posture. Z00Z can settle private rights without becoming every external service that may use those rights.

Why This Scales

The model scales by narrowing public memory. Instead of asking every public observer to replay a global account history, Z00Z uses typed packages, roots, deltas, proofs, and checkpoint artifacts. Validators can reason about the transition without learning wallet-local meaning. DA and watcher layers can support publication and recovery without becoming settlement authority.

Numeric throughput claims still require benchmark evidence. The safe present claim is structural: the architecture is designed for batching, checkpointed publication, replay-bounded verification, and smaller public settlement state than a public account graph.

Failure And Rejection Cases

Settlement should fail closed. A malformed package, mismatched proof payload, duplicate claim replay key, missing consumed path, wrong prior root, detached checkpoint artifact, noncanonical encoding, or unresolved publication input should stop finality rather than produce an ambiguous state. This is why the public evidence path has several typed objects instead of one flexible blob.

Fail-closed behavior also protects privacy. If invalid inputs were “fixed up” by services or inferred from wallet history, those services would become hidden authorities. The protocol’s job is narrower: accept the typed transition that proves itself, or reject it.

Evidence Versus Records

Settlement evidence is not the same as records retention. Public roots and checkpoint artifacts can prove that a transition was accepted. A wallet receipt can help a user understand local ownership. A corporate archive can retain invoice and audit material. An issuer can keep redemption records. A support team can keep incident notes. These are separate records with separate owners.

That distinction lets Z00Z be both privacy-preserving and accountable. The protocol can keep public validation anchors without turning itself into everyone’s accounting archive. Actors that need longer records must retain them through their own wallet, service, or enterprise processes.

Reader Tests

After reading this page, a reader should be able to answer five questions:

1. What object became canonical?
2. Which prior root and next root are linked?
3. Which replay surface prevented reuse?
4. Which evidence proves settlement?
5. Which claims remain outside the protocol theorem?

If a docs page cannot answer those questions for its protocol claim, it is probably speaking too broadly.

The same test applies to integrations. If a bridge, issuer, wallet, or service says a Z00Z object is settled, the claim should identify whether it means internal Z00Z settlement, external release finality, local acceptance, or a support workflow state. Those states are related, but they are not interchangeable.

Closeout Review Notes

Settlement wording is the place where docs can accidentally become custodial. If a page suggests that the project “confirms,” “reverses,” “recovers,” or “guarantees” value without naming the checkpoint rule or external service owner, it is probably overstating the base protocol. The better formula is narrower: the protocol validates typed transitions against canonical roots and replay constraints; wallets, services, and issuers then use that evidence for their own workflows.

This distinction is especially important in incident and support language. A user may experience a failed restore, a delayed publication, a rejected package, an issuer refusal, or a missing archive record. Only some of those are settlement failures. The closeout gate should therefore reject vague statements that say “the transaction failed” without identifying the failed layer. Precision makes troubleshooting faster and prevents public support from promising powers the settlement layer does not have.

When in doubt, the settlement page should force a question: which verifier, root, replay key, artifact, or external actor made the decision? If none is named, the claim is unfinished.

Read Next

• Checkpoints for the public evidence stack.
• Object Lifecycle for how objects reach settlement.
• Protocol Architecture for the layer map around settlement.

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-4 and 8 define canonical objects, checkpoint validation, rollup publication, batching, and stateless verification.
• Linked Liability Whitepaper sections 5-7 define conflict detection, fraud proof extraction, liability activation, economic enforcement, and selective reveal limits.
• Assets, Rights, And Vouchers Whitepaper section 9 defines settlement and accounting implications for asset, voucher, and right objects.