Legal Architecture

Public language must match the system shape. The Z00Z Protocol is published software, cryptographic rules, and data formats—not a company or unidentified operator. Z00Z includes the wallet role as a core architectural component while keeping private user data and jurisdiction-specific policy outside base consensus. z00z_wallets is an open-source reference/demo implementation; conforming custom implementations are permitted. In self-custodial use, the user controls keys, profile settings, local transaction history, backups, receipts, and disclosures and is the responsible actor for the user’s own conduct and obligations. Wallet software is not a legal person and cannot absorb that responsibility. Project-linked and independent operators retain duties arising from what they actually distribute, operate, or control; self-custody does not shift those duties to the user. The Compliance Framework is the canonical source for that responsibility model.

The canonical actor names and legal hierarchy are defined in the Compliance Framework. The word Z00Z alone must not be used to invent a contracting party, controller, service provider, support channel, or holder of user keys.

That distinction matters because a self-custodial user is not a hosted-wallet customer merely because the user runs Z00Z-compatible software. The user controls keys, profile settings, local history, backups, receipts, and disclosures and must meet duties attached to the user’s own conduct. Each project-linked or independent operator is assessed for duties attached to its actual functions, control, data, relationships, and claims.

Core Thesis

The legal corpus describes technical capability and data possession only at the layer where the statement is true. The strong claim is not “Z00Z refuses to know.” The strong claim is that the base protocol is not designed to maintain a universal named account, identity, custody, redemption, or service-record graph. Every actor must be assessed according to its information, authority, activity, relationships, and jurisdiction.

The base protocol may define canonical objects, validity checks, replay boundaries, proof verification, settlement checkpoints, and evidence formats. If a project-linked operator also provides a market, hosted account, identity, bridge, oracle, redemption, issuance, or similar function, that function must be identified, reviewed, and controlled as part of that operator’s real operating model.

Responsibility Boundary Map

The diagram describes the architectural wallet role, not one mandatory program structure and not a device for allocating duties to software. A compatible wallet may fork or extend z00z_wallets or independently implement the canonical transaction/package and validation contract. Public statements must separate user control and conduct from duties arising from what a project-linked or independent operator actually distributes, operates, or controls. Describe a service as independent only when the facts support that separation.

Technical Capability And Data-Possession Boundary

The technical capability and data-possession boundary is narrow and factual. Project-linked materials may say the base Protocol does not require a permanent named account graph only while the protocol design supports that statement. An identified actor may say it does not keep customer files or cannot reconstruct hidden user history only for the surface and period its actual data flows, affiliations, archives, recovery paths, and operations support.

The correct public wording is concrete. The base protocol validates commitments, proofs, nullifier or replay boundaries, checkpoint roots, and settlement state. It does not require a universal mapping between those objects and real-world identity. A wallet or other surface operated by an identified project-linked person or body may nevertheless process information required for its real function. These facts inform, but do not decide, legal classification.

Neutrality And Issuer Separation

Protocol legitimacy is not asset legitimacy. A valid Z00Z state transition means the protocol rules were satisfied. It does not prove that a third-party issuer has reserves, that a bridge is safe, that a marketplace is fair, or that a redemption promise will be honored. That separation must appear in docs, wallet labels, public pages, and partner material.

Safe asset language is descriptive rather than approving. A page may say an asset has one operator, short history, limited liquidity, a known issuer, a published reserve policy, or no archive standard. It should not say the asset is approved, official, guaranteed, recommended, or endorsed by the protocol merely because it can move through Z00Z-compatible tools.

Project-Linked Operator Limits

Project-linked operators may maintain repositories, develop or distribute a reference wallet, coordinate audits, publish notices, support research, hold trademarks, define evidence formats, explain risk, and fund bounded work. Before adding custody, hosted recovery, market making, exchange routing, fiat access, stable-value sponsorship, issuer approval, bridge control, or payroll-like functions, the project-linked operator proposing or providing that function must identify itself, document the operating model, and implement the legal, compliance, data, consumer, and governance controls applicable to it.

This is also why control, affiliation, and operational-role evidence cannot remain a slogan. The corpus calls for durable evidence: keys, mandates, visible governance scope, treasury limits, standing reports, affiliations, and documentary coherence. Wallet copy and operator disclosures must describe the same facts.

Functions Requiring Separate Approval

The following functions require a documented, counsel-reviewed operating model before a project-linked surface launches or markets them:

The phrase “official” is a factual and legal signal, not a banned concept. An identified publisher or operator should use it only when that actor actually accepts and discloses the resulting relationship, control, support posture, and responsibilities.

User-Configured Jurisdiction Policy Profiles

The legal corpus does not push jurisdictional policy into base consensus. A reference or conforming custom wallet may let the user select, modify, or create country, regional, business-use, disclosure, retention, and risk profiles above the core. Where such a profile exists, a user controls local selection and own conduct. An actor that supplies or maintains a profile remains responsible for its claims, updates, security, disclosures, and controls applicable to the functions it operates.

Scoped disclosure, viewing keys, evidence packages, corporate archive formats, audit receipts, and regulated-service records should remain purpose-bound. A control is not optional merely because it is implemented outside the base protocol. A profile cannot certify compliance, waive a prohibition, or transfer either actor’s obligations to wallet software or to the other actor. See the Compliance Framework for the canonical rule.

Safe Public Language

The safest short formula is:

Z00Z combines confidential settlement with an integral wallet role designed for user-controlled possession and limited base-layer public observability. z00z_wallets is an open-source reference/demo implementation, and conforming custom wallets may implement the same network-facing contract differently. The user controls local records and, where a wallet supplies a jurisdiction profile, its local selection; the user remains responsible for duties applicable to the user’s own conduct. Wallet software is not a legal person. Project-linked and independent operators retain duties arising from what they actually distribute, operate, or control; self-custody does not transfer those duties to the user.

Read Z00Z in that formula as the Protocol and architecture, not as an unidentified legal entity. Profile wording applies only where a profile is actually supplied. The responsibility allocation remains the same whether the capability is live, experimental, planned, or independently implemented.

This formulation preserves the claim boundary. It does not promise universal anonymity, automatic compliance, post-hoc recoverability, asset approval, price outcomes, or official service operation. When public copy needs more precision, use Public Claim Boundaries before publishing.

Read Next

• Legal Architecture Companion for evidence packages, claim review, standing reports, and counsel decision points.
• Compliance Framework for the canonical wallet-role, configurable jurisdiction profiles, recordkeeping, AML/CFT/CPF, sanctions, Travel Rule, and actual-function responsibility model.
• Public Claim Boundaries for writer-facing safe and unsafe wording.
• Disclosures for maturity, token, privacy, issuer, governance, and third-party risk disclosures.

Evidence and Further Reading

• Legal Architecture sections 3-4 define the core thesis, protocol minimalism covenant, technical-impossibility boundary, and three-layer responsibility firewall.
• Legal Architecture sections 7-12 define actor-specific compliance controls, wallet boundaries, issuer separation, native-asset boundaries, and external-integration red lines.
• Legal Architecture sections 16-18 define the legal threat model, public-claims discipline, regulator response, technical non-possession, and layered responsibility map.
• Legal Architecture appendices A-B provide the claims matrix and launch-blocking red-line checklist used here.
• Main Whitepaper section 10 supports the protocol-versus-service separation and steward-not-operator framing.