Status pages and explorers make network evidence readable. They can show public health, checkpoints, anchors, DA availability, watcher alerts, validator reject classes, and maturity labels. They must not imply private wallet state, ownership meaning, custody, or finality beyond the evidence they display.

The status surface is a public claim surface. If it overstates maturity, users may act on false confidence. If it displays too much detail, it can leak privacy. If it hides source and uncertainty, operators lose the ability to debug incidents. The correct posture is evidence-linked, privacy-safe, and careful with authority language.

Explorer Data Boundary

The excluded inputs matter as much as the included inputs. Explorer design should prevent private meaning from leaking into public display.

What An Explorer Can Show

A privacy-safe explorer can show:

• Public checkpoint identifiers and maturity labels.
• DA availability status and source references.
• Publication batch references.
• Aggregate validator reject classes.
• Watcher alerts with redacted evidence.
• Anchor references and external-source status.
• Network health and incident notices.
• Documentation links explaining each label.

Each item should include source and maturity. A checkpoint view should identify whether it is candidate, challenged, checkpointed, or settled under the protocol rules. A DA view should identify whether data is retrievable. A watcher alert should identify observation status rather than final judgment.

What It Must Not Show

An explorer should not show private wallet labels, inferred ownership graphs, receiver material, recovery state, support ticket contents, user-specific timing, route intent, or undisclosed policy meaning. It should not display a commitment as a human identity. It should not imply that seeing a public artifact reveals the private object behind it.

Support evidence belongs behind scoped disclosure. If an incident requires private material, the public explorer should show that an issue is under review or that scoped evidence exists, not the evidence itself.

Maturity Labels

Maturity labels should be narrow:

• submitted: a caller sent a package or artifact.
• queued: a service has not yet published or processed it.
• published: a publication record exists.
• available: DA data is retrievable.
• validated: public replay passed a bounded check.
• rejected: public replay failed with a class.
• checkpointed: a checkpoint-facing artifact exists.
• challenged: a dispute or evidence challenge is open.
• settled: maturity and dispute rules support finality.

These labels should not be collapsed into “success.” Users need to know which layer produced the status.

Authority Non-Claims

The explorer is not a validator, not a wallet, not a court, not a custody system, and not a settlement engine. It can display what those systems publish. It can link to evidence. It can show uncertainty. It cannot invent authority.

Legal architecture matters because public status is public representation. If the site says “valid,” “owned,” “private,” “final,” or “compliant,” those words must match the evidence and legal posture. When in doubt, use narrower labels.

Alerts and Incidents

Status pages should distinguish degraded infrastructure from failed protocol claims. DA outage, stale anchor, validator disagreement, watcher lag, and explorer cache delay are different incidents. A good explorer shows incident type, affected scope, current maturity impact, last update time, and next evidence source.

Incident history should avoid turning telemetry into user surveillance. Keep aggregate, redacted, and retention-bounded data wherever possible.

Current Repository Boundary

This repository does not ship a production explorer backend. It has docs pages and site rendering. Future status/explorer implementation should add schemas, source ingestion tests, privacy redaction tests, maturity-label tests, cache staleness tests, and incident workflow tests before these docs become an operator runbook.

Display Review Checklist

Every public status field should answer: what is the source, when was it last updated, what maturity label applies, what privacy class applies, and what should the user not infer? If a field cannot answer those questions, it should be hidden, renamed, or marked experimental. Friendly dashboards are dangerous when they hide uncertainty.

Status cards should prefer layered language. “DA degraded” is clearer than “network failing.” “Checkpoint challenged” is clearer than “invalid.” “Watcher observed stale anchor” is clearer than “fraud.” The label should lead users to the right evidence path and operator owner.

Privacy-Safe UX

A privacy-safe explorer should avoid search patterns that invite deanonymizing use. It should not let users type private wallet labels into a public search box and then log them. It should not autocomplete receiver material. It should not expose per-user polling. It should not show exact timing for events where a coarser display would preserve utility. If account-specific views are ever added, they should live behind wallet consent and should not become public index pages.

The Privacy Threat Model treats telemetry and support paths as sensitive. Explorer analytics should therefore be minimal, aggregated, and retention bounded. Error reports should avoid raw query strings or private artifact interpretations.

Status Test Matrix

Future status tests should cover maturity label mapping, stale cache, missing DA, watcher alert handoff, challenged checkpoint, invalid anchor, privacy redaction, support evidence exclusion, and public claim wording. Tests should assert that stronger labels do not appear before evidence supports them. A green UI state should be earned by data, not by design preference.

Implementation Readiness

An explorer is implementation-ready when ingestion, indexing, display labels, privacy redaction, cache invalidation, and incident updates are all tested. Every label should have a source and every source should have a fallback. Missing DA should downgrade display. Stale watcher data should show staleness. Challenged checkpoints should not appear settled. Invalid anchors should not be hidden behind a generic “syncing” label.

Explorer code should also separate public and wallet-consented views. Public views can show public artifacts. Wallet-consented views may show private interpretation, but only in a local or authenticated context that does not feed public search and analytics. This separation keeps the explorer useful without turning it into a privacy leak.

Support and Education

Status pages are education surfaces. Users often learn the network model by reading labels after something goes wrong. Each label should link to a short explanation and deeper docs. “Available” should link to DA. “Challenged” should link to watcher or linked-liability material. “Checkpointed” should link to checkpoint anchors. This keeps support tickets grounded in the same vocabulary as operator docs.

Operational Caution

Do not let design polish hide uncertainty. Skeleton loaders, green badges, or smooth animations can make stale data feel authoritative. The UI should make staleness, challenge state, and degraded dependencies visible. Honest status is more valuable than a calm dashboard that lies by omission.

Release Gate

Status and explorer docs become operational only when ingestion, cache, redaction, maturity mapping, watcher handoff, DA downgrade, challenged checkpoint display, and support-evidence exclusion are tested. The release gate should prove that public views never show private wallet interpretation without wallet consent. It should also prove that stale data is labeled instead of silently rendered as current.

The gate should include copy review. Public labels are part of the product contract, and a single overstrong word can turn an observation into an implied guarantee. Copy tests should fail on unsupported finality, privacy, or custody claims.

Reader safety note: a public explorer should help users slow down and inspect evidence, not rush them into treating a visible artifact as private meaning, ownership, or finality. Good status design is therefore educational: every strong-looking label should teach which network role produced it and which role has not yet spoken. That teaching function is part of safe public infrastructure. It reduces support burden and prevents accidental financial or privacy overclaims. Evidence wording matters.

Read Next

• Watchers for observation and alert evidence.
• Checkpoint Anchors for anchor references.
• Data Infrastructure for indexes and archives.

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 and 8-10 for metadata, disclosure, telemetry, and privacy validation guidance.
• Main Whitepaper section 8 for publication and public artifact flow.
• Legal Architecture Whitepaper section 17 for public-facing status and claim-boundary concerns.