Runtime services help wallets, nodes, integrators, and users interact with the Z00Z protocol. They should not become hidden settlement authorities. A service can transport packages, cache status, evaluate useful-work evidence, coordinate support, or prepare selective disclosure material, but it cannot override canonical roots, accepted checkpoints, or wallet-local possession rules.
This repository currently ships a website and documentation pipeline, not a
runtime service suite. The real code anchors are src/lib/content/,
src/app/api/dev/content-version/route.ts, config/, content/docs, and
scripts/verify.sh. The service map below is target architecture derived from
the whitepaper corpus. Treat it as a design boundary for future implementation,
not as a claim that these services are already live.
Service Responsibility Map
The shared rule is simple: services can assist, but protocol verification must remain independently checkable. A service response is evidence only when its format, source, scope, and verification path are defined.
Wallet Service
A wallet service may help with device sync, encrypted backup, notification delivery, account recovery, or publication coordination. It should not hold unbounded authority over user assets or rights. Wallet-local possession means the user’s wallet retains the private context needed to interpret commitments and authorize actions. A service that stores encrypted material should not be able to spend, reveal, rotate, or publish without explicit wallet-side consent.
Privacy-sensitive defaults matter. The Privacy Threat Model warns that wallet UX, telemetry, timing, and support flows can leak more than builders expect. Wallet services should minimize stable identifiers, use scoped correlation, avoid unnecessary plaintext metadata, and make recovery flows visible to the user. If a service cannot complete a task without learning sensitive context, the documentation should state that tradeoff honestly.
Publication Service
A publication service relays packages, batches, or data availability records. It may retry failed submissions, expose queue status, and return publication receipts. It must not present “accepted by the publication service” as final settlement. Publication is one stage in the Main Whitepaper’s pipeline, between wallet or package creation and later verification, root production, and checkpointing.
Builders should define publication inputs and outputs carefully. A request may
include a TxPackage, ClaimTxPackage, work item, proof reference, or DA
payload. A response may include a receipt, content reference, batch identifier,
or soft-confirmation signal. Each output needs maturity language. Users and
integrators must be able to distinguish submitted, queued, published,
available, checkpointed, disputed, and settled states.
Watcher and Status Services
Watchers observe protocol activity and report conditions that matter to users, operators, or governance. They may detect missing data, conflicting claims, checkpoint challenges, expired maturity windows, suspicious service behavior, or useful-work disputes. Watchers are valuable precisely because they are not the same as the service being watched.
Status services turn observations into readable state. They should be scoped: a public network status page needs different data than a wallet-specific view or operator dashboard. Avoid exposing private wallet interests in global status feeds. Avoid making status labels stronger than the evidence. “Seen by watcher” and “finalized by settlement” are different claims.
The current website has a development content-version route, but no protocol status service. Future docs should avoid routing users to local website APIs as if they were node or watcher endpoints.
Support and Disclosure Services
Support services handle user help, dispute evidence, recovery assistance, and operational investigation. They are high-risk privacy surfaces. A support flow can accidentally collect full wallet exports, private memos, recovery material, or cross-context identifiers. Good support design starts with the smallest evidence package that can answer the question.
Disclosure services prepare selective reveal material. They should help users prove a bounded fact without exposing the entire wallet or transaction history. The Privacy Threat Model’s sections on disclosure, telemetry, and tests imply a strong rule: every support or disclosure path should have a privacy test case. If an operator asks for “everything,” the system should push back with a specific reason and safer alternative.
Useful-Work Evaluator
The Proof-of-Useful-Work corpus describes useful work as a layered system with actors, work packages, proofs, evidence, fact consensus, value consensus, reward authorization, privacy, challenges, slashing, and appeals. A useful-work evaluator service may collect or score evidence, but it is not automatically the reward authority. Reward outcomes require the protocol and treasury policy boundaries described by the corpus.
Builders should separate three outputs: factual evidence about work performed, value assessment under a policy, and settlement or reward authorization. If a service combines them internally for convenience, its external API should still expose the distinction. Otherwise, a scoring bug can become a monetary or governance bug.
External Integrators
External integrators include exchanges, apps, data providers, bridge operators, identity systems, compliance tools, payment processors, or enterprise systems. They should interact through bounded adapters. An adapter can validate payload shape, translate status terms, enforce rate limits, and produce evidence, but it should not redefine protocol semantics for the whole network.
Every integrator should have a declared trust boundary. What can it observe? What can it mutate? What can it attest? What can it not know? What happens when it fails, lies, delays, or returns inconsistent evidence? Those questions should be answered before an integration is documented as safe.
Repository Implementation Notes
Today’s repository can prove service documentation, not service operation. The
content pipeline can load pages, render Markdown, sanitize HTML, and build the
Next.js site. scripts/verify.sh runs lint, search coverage, and build. The
development API route can return a content version in development. Those are
real surfaces and should be named accurately. Anything beyond them belongs in
target-architecture language until implementation code and tests exist.
Service Contracts
Future services should publish contracts that separate inputs, outputs, authority, privacy, and failure behavior. A wallet service contract should say what data it can store and what it cannot authorize. A publication service contract should say whether a receipt means queued, published, available, or settled. A watcher contract should say which events it observes and which signals are advisory. A support contract should define the smallest evidence package needed for each support class.
Contracts should include redaction and retention. Logs that are useful for debugging may be unsafe for long-term storage. Status data that is harmless in aggregate may identify a user when filtered by wallet or timing. Evidence that is appropriate for an appeal may be excessive for a support ticket. Service contracts should make those tradeoffs reviewable before implementation.
Testing Expectations
Each service type needs deterministic tests once it exists. Publication tests should cover retry and duplicate submission. Watcher tests should cover missing data, conflicting signals, and delayed checkpoints. Disclosure tests should cover over-reveal and under-reveal. Useful-work evaluator tests should cover evidence quality, disputed scoring, challenge windows, and appeal outcomes. Support tests should cover redaction and consent. Website tests do not replace these service tests; they only keep the documentation honest until the runtime code exists.
Maturity Labels
Runtime-service docs should use maturity labels consistently. “Current repo” means a website file, route, config, or command exists here. “Target service” means the whitepaper corpus defines the role but this repository does not yet ship it. “Simulation” means a future harness models the role without production authority. “Implementation” should be reserved for source code and tests that execute the service behavior. These labels keep service maps from reading like a production deployment checklist before the deployment exists. They also make release notes auditable.
Read Next
- Rollup Node for the target node pipeline.
- WASM Wallet for browser-wallet service constraints.
- Verification And Tests for service validation and privacy test expectations.
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 8 and 10 for publication flow and protocol/service separation.
- Privacy Threat Model And Metrics sections 8-10 for disclosure, telemetry, and privacy validation guidance.
- Proof-of-Useful-Work Whitepaper sections 4-8 for useful-work actors, evidence, rewards, privacy, and dispute handling.
src/app/api/dev/content-version/route.tsfor the current repo’s only development route handler in this scope.scripts/verify.shfor current local verification.