Network Overview

The Z00Z network is easiest to understand as a role map. A wallet prepares private local output. Publication services relay it. Data availability keeps public bytes retrievable. Validators replay the public artifact. Checkpoints bind accepted evidence to settlement-facing state. Watchers observe failures and public signals. Explorers display maturity labels. OnionNet, where used, is an ingress privacy layer, not a settlement layer.

Each role carries a different evidence claim. Deployment commands belong to the core repository, not this documentation site, and no helper role becomes “the network authority.” Ordering, publication, DA, validation, and checkpoints remain separate in the Main Whitepaper for the same reason.

Publication To Checkpoint Flow

The flow is not a custody path. The wallet does not hand ownership to an aggregator. A DA adapter does not own rights. A validator does not learn every private fact. A watcher does not finalize disputes. An explorer does not reveal wallet state. The flow is an evidence path.

The Memorable Rule

Use this rule when reading any network page: visibility is not finality, and operation is not authority.

Publication gives visibility to a package or artifact. Availability makes data retrievable. Validation checks public evidence. Observation reports what was seen. Finality requires the settlement-facing checkpoint and the protocol rules behind it. If a public page says “accepted,” it should specify accepted by which layer.

Roles

Aggregators prepare publication work. They may order batches, coordinate admission, normalize inputs, and produce artifacts for later stages. They are not exchanges, custodians, or settlement judges. Their role is useful precisely because it keeps batching and service work below the canonical boundary.

Validators replay public artifacts. They check what they are allowed to check: encoding, commitments, proof references, replay scope, DA retrieval, and checkpoint-facing consistency. They cannot validate private wallet meaning that was never disclosed. Their rejection decisions should be bounded and explainable.

Watchers observe. They detect missing data, conflicting signals, stale anchors, unexpected maturity labels, and privacy-risky status output. Watchers help the ecosystem see problems earlier, but the act of watching is not authority.

DA infrastructure preserves bytes or references. Its job is availability, not ownership. If data is unavailable, validation and public status should expose that gap rather than smoothing over it.

OnionNet protects route and ingress privacy when the design’s contracts are met. It does not redefine ordering, DA, checkpoints, validators, or ownership. Transport privacy is one boundary inside a larger privacy model.

What Each Actor Sees

The network is privacy-sensitive because each actor sees a different slice:

• Wallets see private meaning and user intent.
• Publication services see submitted packages and operational metadata.
• DA systems see blobs, references, or commitments.
• Validators see public evidence and replay inputs.
• Watchers see public artifacts, maturity changes, and failure signals.
• Explorers see curated public display data.
• OnionNet relays should see only hop-local transport information and not canonical payload meaning when the target design is implemented correctly.

The Privacy Threat Model warns that services, telemetry, support, and public status can leak more than users expect. Network docs should therefore describe not only what a role does, but also what it should not see.

Checkpoint Authority

The checkpoint boundary is where the public pipeline becomes settlement-facing. That does not mean every checkpoint reference is self-explanatory. A checkpoint needs links to the batch, root, publication evidence, challenge state, and maturity. It should be possible for an independent verifier to ask which data was checked and what state was accepted.

Checkpoint language must stay precise. “Anchored” can mean a public reference exists. “Checkpointed” means the protocol has a settlement-facing artifact. “Settled” should be used only when the maturity and dispute rules support that claim.

Public Observation

Public observation is useful for operators and users. It can show liveness, data availability, checkpoint progress, watcher alerts, and visible failure classes. It can also mislead if it displays raw support evidence, wallet inferences, user-specific timing, or overconfident finality labels. The status surface should be privacy-safe and source-linked.

Current Repository Boundary

The core z00z repository now contains real crate-level contracts for aggregation, validation, watcher observations, local DA, checkpoint lifecycle, and an aggregator-mode rollup-node process. That is implementation evidence, not evidence that a public multi-operator network, external DA service, OnionNet lane, or production explorer is deployed.

Use implementation evidence for those concrete source and test surfaces, and use deployment evidence only when a running environment, operator policy, and reproducible public artifacts support the claim.

Maturity Vocabulary

Network readers need a shared vocabulary for maturity. Use target architecture when a role is described by the whitepaper corpus but not implemented in the core repository. Use docs evidence when the claim is about content files, frontmatter, diagrams, or navigation. Use implementation evidence only when source code and tests exist for the runtime behavior. Use public evidence when a future explorer or watcher can link to an artifact that others can inspect. These labels keep the docs readable without letting friendly prose become a deployment claim.

The same rule applies to status words. Submitted means a package reached an intake boundary. Published means a publication record exists. Available means data can be retrieved. Validated means a bounded public replay passed. Checkpointed means a settlement-facing artifact exists. Settled should be reserved for the maturity point defined by protocol rules. If a page uses one of those words differently, it should explain why.

Operator Questions

Before operating or implementing a role, ask four questions. What data does the role see? What evidence does it produce? What authority does it explicitly not have? What privacy risk does it add? Aggregators see publication inputs and produce batches; they do not custody user value. Validators see public replay data and produce verdicts; they do not know hidden wallet context. Watchers see public signals and produce alerts; they do not finalize disputes. Explorers display evidence; they do not define truth.

These questions also help readers move through the section. Start with the publication pipeline if the question is “what happens first?” Read aggregators and validators if the question is “who prepares and checks public artifacts?” Read watchers and status if the question is “who reports what happened?” Read OnionNet if the question is “how can ingress reduce unintended route-intent metadata exposure under its stated threat model?” Read DA and checkpoint anchors if the question is “how can others retrieve and verify the evidence?”

Review Checklist

Use this checklist when editing network docs:

• Do not describe helper services as settlement authorities.
• Do not describe transport privacy as complete privacy.
• Do not describe DA as ownership or validity.
• Do not describe watcher alerts as final judgments.
• Do not expose private wallet meaning in public status examples.
• Do link every role page to its whitepaper source.
• Do keep Network frontmatter-only under the active repository rule.

Implementation Readiness

The network family now has implementation evidence for several roles, but it becomes production-ready only when each operated role also has a supported configuration surface, deployment tests, operator evidence, privacy policy, and public failure handling. Until then, docs should separate crate contracts from deployment runbooks. That tells implementers which seams already exist and which operational claims still need proof.

Implementation readiness also requires cross-page consistency. If the publication pipeline calls DA a support layer, the DA page should not call it a settlement layer. If the watcher page says alerts are observations, the status page should not display them as judgments. If OnionNet is transport ingress, operator pages should not use it as a catch-all privacy guarantee. That consistency is the network family’s release gate. It should be checked before every network page is marked complete.

if a role sounds powerful, look for the evidence source and the non-claim beside it. The network family is correct only when both are visible.

Read Next

• Publication Pipeline for the detailed actor order.
• Aggregators and Validators for operator role boundaries.
• OnionNet for transport privacy and non-claims.

Evidence and Further Reading

• Current runtime evidence: z00z-labs/z00z, especially crates/z00z_runtime/aggregators/, crates/z00z_runtime/validators/, crates/z00z_runtime/watchers/, and crates/z00z_rollup_node/.
• Main Whitepaper sections 4 and 8 for rollup, publication, DA, checkpoint, and soft-confirmation roles.
• OnionNet section 3 for the boundary between ingress privacy and settlement logic.
• Privacy Threat Model And Metrics section 8 for service, disclosure, and observation privacy boundaries.