Z00Z architecture starts at the wallet and moves outward. The wallet holds local meaning, receiver material, object inventory, recovery state, and package preparation. The publication path carries candidate transitions into batches and DA references. The checkpoint layer decides whether the transition becomes authoritative. Watchers and validators provide public evidence and rejection signals. External services, issuers, bridges, and compliance overlays sit around the core and own their own duties.
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 |
|---|---|---|
| Wallet | Receiver material, local object recognition, package construction, user disclosures, backups, and recovery state. | Final settlement truth or external issuer promises. |
| 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. |
| External service | Custody, redemption, issuer policy, merchant acceptance, audit files, or regulated records. | Z00Z internal settlement validity. |
This table is the architecture in operational form. Any future page that changes one of these ownership lines risks creating concept drift.
Settlement Notary, Not Public Account Book
The main whitepaper’s strongest phrase is that Z00Z behaves like a settlement notary. 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.
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, docs page, 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 Z00Z validates 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.
Closeout Review Notes
Use this page as the first consistency check for the protocol family. If a later page says that a wallet, operator, bridge, issuer, disclosure flow, or archive can do something, the statement should still fit this layer map. The page should reject two opposite mistakes. One mistake is shrinking the protocol into a mere documentation exercise, as if checkpoints and canonical objects were not real authority surfaces. The other is expanding the protocol 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.
During closeout, treat any sentence 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.
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
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 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 Whitepaper sections 2-3 define delayed-connectivity rights and hidden responsibility boundaries that must attach to objects without becoming public accounts.