Watchers observe the network. They notice publication failures, missing data, stale checkpoint anchors, inconsistent public artifacts, privacy-risky status output, and conditions that should be escalated to users or operators. They are not settlement authorities. A watcher alert can be important evidence, but it does not finalize ownership, slash an operator, or decide a dispute by itself.

This distinction protects both users and operators. Without watchers, failures can remain invisible until too late. With overclaimed watchers, the ecosystem can start treating observation as judgment. Z00Z needs the first without slipping into the second.

Watcher Alert Path

The alert path moves evidence. It does not move settlement authority.

What Watchers Observe

Watchers should focus on public or consented evidence. Useful observations include missing DA data, delayed publication, repeated malformed artifacts, checkpoint maturity changes, validator disagreement, stale anchors, suspicious operator behavior, privacy-risky explorer output, unsupported status labels, and linked-liability conflict signals.

Observation should be scoped. A watcher that needs private wallet notes or raw support exports to operate is probably designed incorrectly. If a watcher needs selective disclosure evidence for a dispute, the disclosure package should name the specific fact being proved and should avoid exposing unrelated wallet context.

Alerts

Alerts should be actionable and bounded. A useful alert says what was observed, which source produced it, what evidence is attached, what maturity state is affected, and which next process should handle it. It should not say “fraud” or “settled” unless the downstream process and evidence support that claim.

Examples of bounded alert classes:

• DA missing or unreachable.
• Publication delayed beyond policy window.
• Validator reject rate spike.
• Checkpoint anchor stale or inconsistent.
• Explorer maturity label stronger than evidence.
• Potential replay or conflict candidate.
• Privacy budget or telemetry boundary exceeded.

These classes let operators respond without turning watchers into judges.

Exported Evidence

Watcher evidence should be reproducible where possible. It can include public artifact identifiers, DA references, checkpoint IDs, timestamps, status label history, validator verdict references, and redacted logs. It should avoid raw private payloads, wallet identifiers, user-specific timing traces, and support attachments unless those are deliberately disclosed.

The Privacy Threat Model’s validation guidance should be treated as a watcher design input. Monitoring can leak. A public watcher dashboard that shows fine grained user behavior can defeat wallet privacy even when the underlying settlement data is cryptographically protected.

Public Status Handoff

Watchers often feed explorers or status pages. That handoff needs a privacy and authority filter. The status page may show that a checkpoint is delayed, that a DA source is degraded, or that a validation dispute exists. It should not show private ownership inferences, support evidence, wallet-local labels, or claims that a watcher cannot prove.

If the watcher is unsure, the status surface should say “observed,” “reported,” “under review,” or “challenge pending” rather than “invalid” or “settled.” Maturity language should reflect the source.

Linked Liability

Linked liability gives watchers a useful role in conflict detection. A watcher may notice public conflicts that later feed fraud proof extraction, locks, bonds, quarantine, case handling, or scoped exculpability. The watcher should export enough evidence for that path without making public accusations beyond what the evidence supports.

This is especially important for appeals. If a watcher record is used in a challenge, it must preserve source, time, artifact, and scope. If the watcher record includes private or sensitive material, the disclosure boundary must be clear.

Privacy-Safe Metrics

Safe watcher metrics include aggregate DA health, checkpoint lag, count of public rejects by class, stale anchor count, and operator liveness. Risky metrics include per-wallet timing, route intent, raw receiver material, private policy text, recovery behavior, and support ticket contents. A watcher should prefer aggregate and redacted outputs by default.

Low-level telemetry should have retention limits. The longer it is kept, the more likely it becomes a behavioral dataset. Privacy-safe monitoring is not just about what is displayed; it is also about what is stored.

Current Repository Boundary

This repository does not run watcher services. It documents the role and verifies that network docs stay within source-backed claims. Future watcher implementations need tests for alert classification, redaction, evidence exports, status handoff, and stale data behavior.

Watcher Test Matrix

Future watcher tests should cover missing DA, stale anchor, delayed publication, validator disagreement, checkpoint challenge, status label drift, privacy over-disclosure, duplicate alert suppression, alert recovery, and evidence export redaction. The test should assert the alert class and the evidence fields, not just that an alert was emitted. A noisy watcher can be as damaging as a silent one if operators start ignoring it.

Staleness tests are especially important. A watcher that misses a recovery event can keep displaying an incident after it is resolved. A watcher that misses a challenge can let a status page look final too early. Each alert needs source, time, current maturity effect, and refresh policy.

Operator Handoff

Watcher alerts should route to owners. DA issues route to publication or infrastructure operators. Validator disagreement routes to protocol review. Explorer label drift routes to status maintainers. Privacy over-disclosure routes to security and support owners. Linked-liability conflicts route to the defined challenge or case process. A watcher that only emits a generic red badge creates confusion.

The handoff should also record what operators must not do. They should not delete evidence to clear a public alert. They should not silence a privacy alert by lowering display detail while keeping dangerous logs. They should not resolve a challenge locally when a protocol process is required.

User-Facing Wording

Public watcher wording should be cautious. Use “observed,” “reported,” “delayed,” “unavailable,” “challenged,” or “under review.” Avoid “fraud,” “invalid,” “settled,” or “safe” unless the downstream evidence supports those words. Watcher language often becomes public incident language, so precision matters.

Implementation Readiness

Watcher implementation should define event sources, polling or subscription model, deduplication, state storage, redaction, alert routing, and retention. It should test stale data, missed recovery, duplicate events, conflicting sources, and privacy redaction. It should also make silence observable: if a watcher stops seeing a source, that is a health state, not proof that nothing happened.

Watchers should expose confidence and source. An alert from one watcher may be advisory. A confirmed public artifact with reproducible evidence may be stronger. A cross-source disagreement should remain visible until resolved. This prevents a single observer from becoming a hidden authority.

Watcher Privacy Budget

Every watcher should have a privacy budget: which fields it collects, why it collects them, how long they are retained, and where they are displayed. Operator convenience is not enough reason to store per-user traces. When in doubt, prefer aggregate counters, redacted evidence, and delayed public display.

Release Gate

Watcher docs become operational only when the implementation proves alert classification, source staleness, deduplication, redaction, retention, and status handoff. It should also prove that a watcher outage is visible. A silent watcher failure is dangerous because users and operators may assume no alert means no problem.

Watcher release should also include human review paths. Some alerts need operator repair, some need protocol challenge, some need privacy response, and some need support triage. Routing must be tested, not left to dashboard interpretation.

Reader safety note: no alert is also a claim. If watcher health is unknown, the absence of alerts should not be interpreted as normal network behavior. Watcher silence needs its own status. That status should include last-seen source time, expected refresh cadence, and the maturity labels that may be affected by missing observations. This makes watcher failure visible instead of silently optimistic.

Read Next

• Status And Explorer for public display rules.
• Validators for replay and reject decisions.
• Checkpoint Anchors for anchor evidence and maturity.

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.

• Privacy Threat Model And Metrics sections 5, 8, and 10 for observability, disclosure, telemetry, and validation guidance.
• Main Whitepaper section 8 for publication and public artifact flow.
• Linked Liability Whitepaper section 5 for conflict detection and evidence paths.