Checkpoints are the narrow public evidence layer where Z00Z settlement becomes authoritative. A package may exist, a batch may be ordered, and a DA provider may store bytes before finality. The checkpoint boundary asks whether the previous root, next root, consumed paths, created leaves, proof payload, and canonical link all agree.

That makes checkpoints the center of public verification, not the whole user story. They prove settlement validity. They do not reveal every private meaning or guarantee every external service promise.

Evidence Path

The evidence path is staged. DA and watcher evidence help find and evaluate bytes. The checkpoint relation decides settlement.

What Checkpoints Decide

Checkpoints decide root continuity, replay resistance, proof binding, and typed state change. They answer whether a public transition can be accepted under Z00Z’s rules. A valid checkpoint can show that a committed object was consumed, that new leaves were created, that a claim replay key was used, or that a package and artifact agree.

This is enough to support non-custodial settlement claims. The protocol can prove state transition validity without holding user keys, operating a hosted balance, or exposing a public account graph.

What Checkpoints Do Not Decide

Checkpoints do not decide whether a foreign reserve exists, whether a bridge will release collateral, whether an issuer will redeem, whether a merchant will honor a voucher, whether a user paid taxes, or whether a support desk retained records. Those duties belong to services and actors outside the checkpoint theorem.

They also do not reveal private object meaning by default. A checkpoint may expose commitments, roots, proof bytes, deltas, timing, or publication metadata. It should not reveal receiver secrets, wallet-local inventory, plaintext amounts, or full private histories.

DA Relationship

Data availability helps the network publish and recover bytes. It does not replace validation. A DA provider can say bytes were stored or resolved. It cannot by itself say the transition is valid Z00Z settlement. Validators still need to check the recovered bytes against checkpoint artifacts, roots, and proofs.

This is why Z00Z can use DA without outsourcing settlement authority. DA is a publication layer. Checkpoints are the settlement boundary.

Watcher Observation

Watchers make the system more observable. They can detect missing blobs, stalled publication, divergent provider behavior, delayed verdicts, or suspicious replay surfaces. They can export evidence records for debugging, audits, or incident response.

Watcher output is still evidence around settlement, not settlement by itself. A watcher alert should trigger investigation or rejection paths where appropriate. It should not become a separate finality oracle.

Replay And Privacy

Replay resistance and privacy are linked. The protocol must reject repeated use without publishing a reusable public account. It does this through consumed paths, roots, flow-specific nullifiers, claim replay records, and checkpoint continuity. That lets Z00Z prove a right was not reused in the same settlement domain without turning every private object into a public owner row.

The same public evidence can support later dispute or liability handling, but only under narrow rules. Conflict-triggered reveal should stay scoped to the affected domain.

Checkpoint Review Checklist

When a docs page claims something about settlement, verify that it identifies:

If one of these elements is missing, the text may still be useful as an overview, but it should not present itself as a complete settlement explanation.

Anchors And Timestamps

Future anchors, timestamp services, or external meta-anchors can strengthen evidence that a checkpoint artifact existed at a particular time or was published through an additional channel. They are useful for auditability and dispute handling. They are not a replacement for checkpoint verification. An anchor can prove that some artifact existed; it does not prove by itself that the artifact was a valid Z00Z state transition.

That distinction keeps the architecture modular. Z00Z can add stronger publication and timestamp evidence without letting an external anchor redefine settlement truth.

Reader Warnings

Avoid three shortcuts. First, do not call a soft confirmation final settlement. Second, do not call DA publication validity. Third, do not call watcher observation custody or guarantee. Each shortcut collapses a support layer into the checkpoint layer and makes the protocol sound less precise than it is.

The stronger claim is narrower: checkpoints are enough public evidence for non-custodial settlement when the typed transition checks out.

Operational Use

Operators should use checkpoint evidence as the common reference when debugging publication failures, validator rejection, watcher alerts, or wallet reconciliation problems. A failed DA fetch, a missing blob, a rejected proof, and a mismatched root are different incidents. Treating them all as “the transaction failed” hides the layer where the failure occurred.

Good incident notes should therefore name the artifact that failed: package, publication request, DA reference, resolved batch, checkpoint artifact, checkpoint link, watcher evidence, or external-service record. That naming keeps recovery practical and prevents service failures from being misreported as protocol failures.

Privacy Use

Checkpoint visibility should also be interpreted carefully. A checkpoint can prove that committed objects changed state. It does not by itself reveal why the user acted, which local invoice existed, which memo was attached, which support context applied, or which external business process surrounded the object. If those facts are needed, they must come from scoped disclosure or service-held records.

Closeout Review Notes

The final consistency sweep should treat checkpoint language as a high-risk vocabulary surface. “Published,” “observed,” “available,” “accepted,” and “settled” are not synonyms. A watcher may observe a package before the checkpoint proves it. A DA layer may hold bytes before the protocol accepts the transition. A wallet may locally accept an object before final replay-safe settlement. An external service may release a benefit after its own records say the event is complete. Those are related states, but each one has a different authority owner.

This page should therefore be used when reviewing network, status, audit, incident, and support pages. If a page tells a user that something is final, it should point to checkpoint evidence or use narrower wording. If it only has publication, provider, or service evidence, it should say that. The distinction is the difference between useful operational reporting and misleading finality.

The same rule applies to diagrams. A checkpoint node should not be drawn as if it owns DA, wallet recovery, external redemption, or support routing. Edges should show evidence flow, not imaginary command authority. That keeps visual summaries aligned with the written settlement boundary.

Read Next

• Settlement Model for root continuity and replay semantics.
• Protocol Architecture for the layer map around checkpoints.
• Object Lifecycle for how publication leads to settlement or challenge.

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 4 and 8 define rollup architecture, ordering, publication, verification, batching, and checkpoint performance boundaries.
• Linked Liability Whitepaper sections 5-7 define conflict detection, fraud-proof extraction, selective reveal, and proof requirements around checkpoint-visible evidence.
• Privacy Threat Model And Metrics sections 4 and 8 define layered privacy pressure and network/helper boundaries around publication and observation.