Validators check public artifacts. They replay what can be replayed, reject what is malformed or inconsistent, and feed checkpoint-facing correctness signals into the broader network. They are not omniscient. They do not learn private wallet meaning that was never disclosed. They do not become custodians by checking a package. They do not replace checkpoint authority.

The validator role is one of the most important places to keep public evidence and private meaning separate. A validator can say “this artifact does not replay under the public rules I can check.” It cannot say “every private business fact behind this wallet action is true” unless those facts were committed, disclosed, and made part of the validation rule.

Validator Verdict Scope

The dotted line is the safety boundary. Validators should not pretend to know private wallet state outside the disclosure and commitment model.

What Validators Check

Validation checks should be explicit. Future implementation may include:

• Supported protocol and schema versions.
• Network, epoch, and object-domain identifiers.
• Data availability retrieval and content references.
• Canonical encoding and commitment structure.
• Public proof references and root relationships.
• Nullifier or replay-scope rules.
• Conflict indicators and linked-liability triggers.
• Checkpoint-facing maturity and challenge windows.

Each check should produce a predictable result. A malformed artifact should not be treated the same as missing DA. A replay attempt should not be treated the same as an unsupported version. A privacy redaction problem should not be hidden behind a generic validation failure.

What Validators Cannot Know

Validators cannot know private wallet notes, private policy interpretations, user intent, support history, hidden receiver context, undisclosed recovery state, or off-chain business meaning unless the protocol commits or discloses that information. This is not a weakness. It is part of Z00Z’s privacy and wallet-local possession model.

Validation docs should avoid phrases such as “the validator confirms ownership” unless the committed artifact actually proves the relevant ownership fact. Often the safer phrase is “the validator checks the public evidence needed for the checkpoint-facing transition.”

DA and Checkpoints

Validation depends on data availability. If the bytes needed for replay cannot be retrieved, a validator should report an availability failure rather than guessing. A DA receipt or reference is not enough by itself. The validator must know what data it checked and which root or artifact the check supports.

Checkpoint interaction should be similarly bounded. Validator verdicts can feed checkpoint-facing artifacts, but the checkpoint boundary is where settlement maturity is expressed. A validator’s local pass should not be displayed as final settlement unless the checkpoint and dispute rules make that true.

Linked Liability

Linked liability changes the meaning of conflicts. A conflict may not be only a simple rejection; it may start a fraud proof, lock registry action, bond question, quarantine case, or appeal path. Validators should preserve evidence needed for those paths without over-collecting private data.

The Linked Liability paper’s sections on conflict detection, fraud proof extraction, lock/slash/quarantine/case handling, and scoped exculpability should shape validator records. A validator should identify the root, batch, artifact, and conflict class. It should not turn a conflict into public blame without the scoped evidence and procedure required by the liability model.

Non-Custodial Limits

Validators do not take custody. They check artifacts. They should not require wallet private keys, recovery material, plaintext policy notes, or service support exports. If a validation path requires private user data, the flow should use selective disclosure and should state exactly what fact is being proved.

The Privacy Threat Model’s public/private split matters here. Validators may receive public artifact data and disclosed evidence. They should not become a shadow analytics system that reconstructs wallet behavior from timing and metadata.

Reject Decisions

A reject decision should be explainable and safe. It should name the class of failure without exposing secrets. Examples include invalid encoding, unsupported version, wrong domain, missing DA, replay scope failure, proof mismatch, checkpoint mismatch, conflict candidate, and privacy policy violation. Rejection messages should avoid raw private payloads, local filesystem paths, internal stack traces, or user-specific behavioral details.

Current Repository Boundary

This repository does not implement validators. It can document validator responsibilities and verify that the docs do not overclaim. Future validator implementation must add deterministic tests for replay, DA failure, conflict, privacy redaction, and checkpoint maturity before these docs can become an operator runbook.

Validator Evidence Checklist

Validator evidence should include the artifact checked, DA reference, schema version, domain, replay context, proof or commitment reference, decision class, and checkpoint-facing output. If the validator rejects an artifact, the reject class should be specific enough for a caller or operator to act. If the validator reports a conflict, the evidence should preserve the path needed for linked-liability review.

Evidence should also include non-observation. If DA data was unavailable, the validator should record that it could not replay the artifact rather than guessing. If a private fact was undisclosed, the validator should not infer it. If the checkpoint state was challenged, the validator should not display a settled label.

Validator Test Matrix

Future validator tests should cover good public replay, malformed encoding, wrong network, unsupported version, missing DA, wrong commitment, replayed artifact, conflicting public evidence, challenged checkpoint, privacy over-disclosure, and redacted error output. Each test should use deterministic fixtures and should assert the decision class, not only that the command exits.

This test matrix belongs in protocol implementation, not in Markdown examples. The docs can define the expected categories now, but passing docs verification does not prove validator correctness.

Operator Review

Operators should review validator health by decision class. A spike in unsupported versions means something different from a DA outage or conflict candidate. Aggregate counts are usually safer than per-user traces. If a validator dashboard exposes raw artifacts, it should be restricted and audited because raw artifacts may still reveal sensitive patterns.

Implementation Readiness

Validator implementation should expose stable decision enums before public docs turn into runbooks. The enum should separate malformed input, unsupported version, wrong domain, missing DA, proof mismatch, replay failure, conflict candidate, checkpoint challenge, and internal fault. A generic failed status is not enough for operators, wallets, or watchers.

The implementation should also prove determinism. Two validators with the same public inputs and rules should produce the same decision class. If they do not, the divergence should be traceable to version, DA source, evidence set, or configuration. Determinism is what makes validator evidence useful downstream.

Public Communication

Validator decisions often reach users through explorers or support. Public language should be narrower than internal diagnostic language. “Rejected by public replay” is safer than “fraud” unless the linked-liability path has made that finding. “DA unavailable” is safer than “invalid.” Clear wording reduces panic and avoids assigning blame before the evidence path is complete.

Release Gate

Validator docs become operational only when implementation tests prove each decision class. The release gate should include replay fixtures, DA outage fixtures, conflict fixtures, challenged checkpoint fixtures, privacy-redaction fixtures, and deterministic cross-node comparison. Without those tests, a validator page should not include commands, service-level objectives, or public operator promises.

After release, validator docs should still separate implementation status from network status. A validator binary can be healthy while DA is unavailable or a checkpoint is challenged. The public label must follow evidence, not process health.

Reader safety note: a validator verdict is strongest when it names the exact artifact and rule it checked. If the verdict does not name its scope, treat it as an operational signal rather than a settlement conclusion.

Read Next

• Data Availability for retrieval support.
• Checkpoint Anchors for settlement-facing references.
• Watchers for observation and alert handoff.

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 for validation, publication, DA, and checkpoint boundaries.
• Linked Liability Whitepaper sections 5-7 for conflict detection, fraud proof extraction, lock registries, bonds, quarantine, and scoped exculpability.
• Privacy Threat Model And Metrics section 4 for privacy threat framing around observable and hidden state.