Z00Z architecture starts at its wallet role and moves outward. A wallet holds
local meaning, receiver material, object inventory, recovery state, and package
preparation. Publication carries candidate transitions into batches and DA
references; checkpoints decide authority; watchers and validators provide public
evidence. z00z_wallets is the open-source
reference/demo implementation, while conforming custom wallets may implement
the network-facing contract differently. Users control keys, local choices, and
their own conduct. Operators remain responsible for the functions, interfaces,
data, claims, and services they distribute, operate, or control; neither the
wallet boundary nor self-custody transfers those duties to the user. The
Compliance Framework owns the canonical allocation.
This is not a public account-chain shape. Z00Z tries to make the public surface narrow enough to preserve privacy while still strong enough to verify replay-safe settlement. The architecture is therefore a boundary map: each layer owns a specific question, and no layer should silently absorb another layer’s responsibility.
System Context
The context map deliberately keeps services outside the settlement core. A bridge, issuer, or corporate archive can be useful without becoming the protocol’s source of truth.
Authority Flow
The flow should be read left to right. Local meaning can exist before publication. Publication can happen before finality. DA can help recover bytes without deciding validity. Checkpoints decide canonical settlement. External services can add context but cannot rewrite the protocol theorem.
Layer Ownership
| Layer | Owns | Does not own |
|---|---|---|
| Z00Z wallet role | Receiver material, local object recognition, package construction, user disclosures, backups, recovery state, and configurable jurisdiction policy tools. The open-source reference crate and compatible custom wallets may realize this role with different internals. | Final settlement truth, external issuer promises, legal certification, or reallocation of duties arising from an actor’s actual functions. |
| Publication | Intake, ordering, batching, DA handoff, soft confirmations, and operational status. | Validity by itself. |
| DA | Recoverable batch bytes, blob references, namespace or provider metadata, and availability outcomes. | Privacy semantics, receiver identity, or canonical settlement. |
| Checkpoint | Root continuity, replay resistance, typed deltas, proof payloads, and canonical links. | Hosted custody, redemption, KYC, reserves, or corporate recordkeeping. |
| Watcher and validator | Resolution, verdicts, alerts, and evidence exports. | Wallet ownership, service support, or legal guarantees. |
| Independent service | Custody, redemption, issuer policy, merchant acceptance, audit files, or regulated records for the functions it separately controls. | Protocol settlement validity or duties belonging to an actual project-linked operator. |
This table is the architecture in operational form. Any future page that changes one of these ownership lines risks creating concept drift.
The Wallet SDK interoperability section owns the implementation rule. Compatibility follows canonical package formats, cryptographic domains and versions, and settlement validators—not the reference crate’s internal module layout.
Cryptographic Settlement-Notary Analogy, Not Public Account Book
The main whitepaper describes Z00Z as a settlement notary in a strictly technical sense. Public state records committed leaves, roots, deltas, proof material, and checkpoint links. It does not maintain a reusable public ownership row for every user. Wallets derive local meaning from keys, receiver material, scan state, imported packages, and recovery context.
This analogy does not make the Protocol or a verifier a notary public, legal certifier, contracting party, custodian, or service operator. Cryptographic acceptance proves only the defined predicates; it does not establish real-world identity, consent, authority, title, legality, compliance, reserves, or enforceability of an external promise.
That distinction is why the architecture can support private cash, rights, vouchers, and external-asset claims without forcing all private meaning into a public graph. The public layer answers whether a typed transition was valid. It does not become the user’s economic biography.
Privacy Boundary
Privacy is not a decoration on top of the architecture. It is a consequence of keeping public evidence narrow, wallet meaning local, and service records separated. A public observer may see commitments, proof bytes, roots, timing, or publication signals. They should not learn the full sender, receiver, amount, memo, policy, or wallet-local history from the base settlement layer.
The same boundary creates limits. Ingress events, external custody, issuer logs, receiver reuse, exact timing, support records, and disclosure packages can reduce privacy outside the core. Architecture docs should state those limits instead of using absolute privacy language.
Target Extensions
Several extensions fit the architecture but should stay labeled by maturity: richer disclosure packages, corporate archives, advanced DA topologies, external lockers, machine and agent rights, linked-liability enforcement, recursive proof aggregation, and post-quantum migration lanes. They are coherent because they preserve the same layer split. They should not be written as fully live merely because the corpus describes them.
Builder Review Questions
Use these questions before adding a protocol feature, documentation entry, or integration claim:
| Question | Safe answer |
|---|---|
| Does the feature preserve wallet-local meaning? | Private interpretation stays in the wallet unless a scoped disclosure exports it. |
| Does publication remain separate from validity? | DA or batch publication helps recovery, but checkpoint rules still decide settlement. |
| Does the service layer own its own promises? | Issuers, bridges, merchants, auditors, and regulated services keep their own duties. |
| Does the claim distinguish live and target behavior? | Current source-backed behavior is not mixed with roadmap or research language. |
| Does privacy survive operational defaults? | Receiver reuse, logs, support exports, and exact timing are treated as privacy risks. |
If one answer is unclear, the feature probably belongs in a target section or a service-specific page rather than in the core protocol claim.
Common Misreads
The architecture is not “everything important is off-chain.” Checkpoints remain public authority. It is not “DA is the chain.” DA carries recoverable bytes, while conforming verifiers apply the Z00Z Protocol rules to their meaning. It is not “wallet state is final.” Wallet state is local possession until checkpoint settlement. It is not “external assets become native guarantees.” External assets keep external issuer and custody assumptions.
These corrections matter because the rest of the docs reuse the same words. A weak architecture page would let later pages overclaim privacy, cross-chain rights, smart cash, or service responsibility.
Claim Boundaries
The layer map is the first consistency check for the protocol family. Any claim about a wallet, operator, bridge, issuer, disclosure flow, or archive must fit these layers. Avoid two opposite mistakes: shrinking the protocol into a mere documentation exercise, as if checkpoints and canonical objects were not real authority surfaces; and expanding it into a universal service platform, as if every wallet, issuer, bridge, and support workflow were native protocol behavior.
The safer review posture is layer-by-layer. Public settlement can be strong without becoming an account ledger. Wallet-local possession can be useful without becoming finality. External lockers can carry private internal rights without losing external custody risk. Disclosure can be purposeful without becoming a general backdoor. When these distinctions stay visible, future docs can add richer features without rewriting the core thesis.
Treat any claim that erases one of those layers as a defect. The protocol is easier to explain when each layer keeps its own authority and failure mode.
A checkpoint proves a canonical state transition, not custody, availability, recovery, or external redemption. A wallet proves local possession only through its own material. Any claim crossing those boundaries needs separate evidence and a named responsible actor.
Read Next
- Settlement Model for checkpoint authority.
- Wallet-Local Possession for local ownership interpretation.
- Checkpoints for public evidence.
- Selective Disclosure for multi-view privacy.
Evidence and Further Reading
- Main Whitepaper sections 3-8 define canonical objects, rollup publication, wallet-local possession, privacy, external assets, and scalability.
- Privacy Threat Model And Metrics sections 3-4 define adversary classes and layered privacy pressure across ingress, internal movement, egress, transport, and wallet behavior.
- Linked Liability sections 2-3 define delayed-connectivity rights and base-layer-confidential responsibility boundaries that must attach to objects without becoming public accounts.