The publication pipeline is the network reading path that connects wallet-local output to public evidence without pretending that visibility is settlement truth. It is where private wallet work becomes a public artifact, where data availability support makes verification possible, where validators replay what can be checked, where checkpoint anchors bind references to settlement-facing artifacts, where watchers observe failures, and where status surfaces explain maturity to users.
This repository does not ship a production node, DA adapter, validator network, watcher fleet, or explorer backend. It ships the documentation surface that keeps those future roles legible. Every runtime term in this page is therefore target architecture unless a later implementation adds source files and tests. The authority model still matters now because examples, status labels, and operator docs can drift long before code exists.
Context Diagram
The diagram is intentionally split by authority. Publication services transport work. DA keeps data available. Validators replay public material. Checkpoints are the settlement-facing boundary. Watchers and explorers observe. None of the helper roles should be documented as custody, ownership, or finality authority.
Sequence From Wallet To Status
The sequence does not say that every stage must be a separate company, process, or machine. It says every stage has a different truth claim. A service can implement more than one role, but documentation and tests should still keep the claims separate.
Authority Levels
The Main Whitepaper separates publication artifacts from checkpoint authority. That distinction should shape every network page:
- Wallet output is private intent plus local possession context.
- A publication request is transport into the public pipeline.
- A DA reference says bytes should be retrievable, not that they are valid.
- A validator verdict says a replayed public artifact passed or failed a bounded check.
- A checkpoint artifact is the settlement-facing evidence boundary.
- A watcher alert says something was observed, not that it is final.
- A status or explorer view is a display surface, not the source of truth.
These levels prevent misleading status language. “Published” should not mean “settled.” “Available” should not mean “owned.” “Watched” should not mean “accepted.” “Anchored” should not mean “valid under every business rule.”
Stage At A Glance
| Stage | Main public artifact | Safe claim | Wrong shortcut to avoid |
|---|---|---|---|
| Publication | Receipt, queue status, or publication reference | A package entered the pipeline | “The transfer is settled.” |
| Data Availability | Retrievable bytes, commitments, or references | Verifiers can fetch the material they need | “The payload is valid.” |
| Validation | Bounded verdict or rejection evidence | Public artifacts replayed under defined checks | “All private business meaning was validated.” |
| Checkpoint | Root, anchor, batch reference, or challenge state | Settlement-facing evidence was recorded | “Every downstream obligation is final.” |
| Watcher output | Alert, observation package, or freshness signal | Something notable was observed | “The watcher decided the dispute.” |
| Status / Explorer | User-facing label plus source links | Readers can inspect maturity and artifact lineage | “The UI is the source of truth.” |
The table is a fast way to keep operator language honest. If a runtime term cannot be mapped to one of these artifact and claim pairs, the page should narrow the claim before it sounds more authoritative than the evidence behind it.
Publication
Publication is the first public step. A wallet or runtime component produces a package or work item, then a publication service relays it toward the network. The service may authenticate callers, rate-limit, queue, retry, normalize payload shape, or return a receipt. It should not decide ownership or finality.
The publication service must also keep privacy boundaries visible. It should not log raw wallet-local meaning, private policy text, recovery material, or route intent unless the user has explicitly disclosed that data and the service contract permits it. If OnionNet or another ingress layer is used, publication docs should distinguish transport privacy from settlement privacy.
Data Availability
DA supports verification by making bytes, commitments, or references retrievable. It is not settlement authority. If a batch is visible but the data needed to check it cannot be retrieved, the network should expose that as an availability failure rather than allowing a status page to imply finality.
Cross-chain and external adapters make this more important. External systems can provide references, locks, proofs, timestamps, or receipts, but those artifacts enter Z00Z through defined evidence boundaries. The DA layer should help verifiers fetch the right material; it should not decide whether a right, voucher, claim, or useful-work reward is valid.
Validation
Validators replay public artifacts under bounded rules. They can reject malformed payloads, unsupported versions, missing data, replay attempts, conflicting public evidence, or checkpoint-facing inconsistencies. They cannot see private wallet meaning that was never disclosed, and they should not claim to validate business context outside the committed evidence.
Linked liability changes validation language because conflicts can lead to fraud proof extraction, lock registry actions, bonds, quarantine, and appeal paths. Validator docs should identify whether a verdict is a normal rejection, conflict signal, challenge input, or settlement-facing condition.
Watchers and Status
Watchers observe. They are valuable because they can notice missing DA, checkpoint challenges, suspicious operator behavior, stale anchors, replay-like patterns, or privacy-risky public signals. They do not become settlement authority by noticing something. Their output should be evidence-linked and privacy-safe.
Status surfaces and explorers translate public evidence into user-facing labels. They should show maturity and source: submitted, queued, published, available, validated, checkpointed, challenged, rejected, or settled. They should avoid displaying private wallet state, inferred ownership, or support evidence that belongs behind selective disclosure.
Failure Branches
Each pipeline stage should have a failure mode. Publication can fail because a package is malformed or rate-limited. DA can fail because bytes are missing. Validation can fail because the artifact does not replay. Checkpointing can fail because evidence is challenged. Watchers can disagree or go stale. Status can lag reality. A safe network page explains those failures instead of hiding them behind “network error.”
Evidence Records
Each stage should leave evidence that the next stage can inspect. Publication should leave a receipt or rejection class. DA should leave a retrievable reference or availability failure. Validators should leave a bounded verdict and source identifiers. Checkpoints should leave artifact identifiers, root or batch references, maturity state, and challenge context. Watchers should leave redacted observation packages. Explorers should preserve source links for every displayed status.
Evidence records should also name their limits. A publication receipt does not say the package is valid. A DA record does not say the right transferred. A validator pass does not reveal undisclosed private meaning. A watcher alert does not resolve a dispute. A status card does not become finality because it is easier for users to read.
Privacy Review
The pipeline touches private intent at the start and public display at the end. That makes privacy review mandatory. Check whether publication logs include wallet identifiers, whether DA retrieval creates lookup fingerprints, whether validators retain more metadata than they need, whether watchers export over-detailed evidence, and whether status pages expose user-specific timing or inferred ownership.
If a privacy-sensitive detail is needed, the docs should explain the disclosure path. The preferred answer is scoped evidence, not broad wallet export. The pipeline should make public what is needed for verification and keep private what belongs to the wallet or support boundary.
Implementation Readiness
A real publication pipeline needs schemas and tests for each handoff. Wallet output needs package shape tests. Publication needs receipt and retry tests. DA needs retrieval and mismatch tests. Validation needs replay and reject tests. Checkpointing needs maturity and challenge tests. Watchers need redaction and alert tests. Status needs label-mapping tests. Without those tests, the page remains an architecture guide rather than an operator runbook.
Read Next
- Network Overview for the shorter role story.
- Data Availability for availability boundaries.
- Status And Explorer for maturity labels.
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 publication, batch, DA, validation, checkpoint, and soft-confirmation vocabulary.
- Cross-Chain Integration Whitepaper section 7 for external evidence and lifecycle boundaries.
- Linked Liability Whitepaper sections 5-7 for conflict, challenge, fraud-proof, and liability paths.
- Privacy Threat Model And Metrics section 8 for privacy-safe service and disclosure boundaries.