A legal boundary must survive every later public document, not only its first description. This companion is not a second summary of Legal Architecture; it explains how to keep that boundary from drifting in docs, wallet notices, partner pages, governance materials, grant programs, and external responses.
The problem it solves is documentary coherence. A protocol can be architecturally narrow and still create legal confusion if the public corpus speaks inconsistently. If one page says a project-linked entity does not operate a bridge but another says “our bridge,” the stronger statement is undermined. If one page says disclosure is always elective but another describes a mandatory service workflow, the compliance claim becomes unclear. If a roadmap labels a target feature as if it already ships, the maturity boundary collapses.
Claim Review Workflow
Every public claim should pass through four questions before it is published.
| Review question | Pass condition | Escalate when |
|---|---|---|
| Who is responsible for this claim? | For ordinary self-custodial use, the sentence says the user controls the user’s keys and wallet-local records and is responsible for duties applicable to the user’s own conduct; it identifies every separate operator only where one actually exists. | It uses controller as a generic synonym for local possession, assigns responsibility to wallet software, or replaces an actual operator with a nominal label. |
| Is the claim live or target? | Current behavior, target architecture, research direction, and open question are separated. | It turns a whitepaper direction into a shipped product promise. |
| What evidence supports it? | The claim links to a concrete whitepaper section, code primitive, plan artifact, or policy document. | The claim relies on brand tone or assumptions instead of local evidence. |
| What could a hostile reader infer? | The sentence still reads correctly when quoted without surrounding context. | It could imply custody, exchange operation, reserve sponsorship, price outcome, or automatic compliance. |
This workflow is deliberately stricter than ordinary editorial review. It treats public wording as a control surface because the legal architecture paper treats documentation and marketing drift as real failure modes.
Evidence Package Discipline
The legal corpus repeatedly separates public settlement evidence from long-term service records. That separation only works if actors can keep durable, verifiable evidence where they actually need it. The companion checklist therefore expects three artifact families:
| Artifact | Purpose | Owner |
|---|---|---|
| Evidence package | Binds a transaction, work claim, grant event, or compliance-relevant action to accepted protocol state and selected supporting facts. | The self-custodial user for records the user holds; an enterprise or separate service for its own records. |
| Disclosure package | Reveals scoped facts to a specific recipient without turning ordinary privacy into full transparency. | The user who holds the local history and is authorized or required to disclose it; a separate recipient handles its copy under rules applicable to it. |
| Corporate archive format | Organizes long-lived receipts, encrypted records, approval data, accounting links, and retention metadata. | Enterprise, regulated service, auditor, or recordkeeping-heavy operator. |
A protocol publisher or standards steward, if one exists, may define formats and verification expectations. It should not become the global archive operator. That distinction is central to archive neutrality: published standards can make evidence verifiable without any unidentified Z00Z entity storing everyone’s business records.
Project-Linked Operator Checklist
Before a project-linked page, wallet feature, grant, interface, or partnership is described publicly, verify these conditions.
| Boundary | Required evidence |
|---|---|
| Custody posture | Record whether any project-linked surface holds or can recover user keys, user funds, reserves, or balances; do not infer the answer from the wallet label. |
| No exchange operation | It does not route swaps, operate a market, provide a conversion desk, or act as a market maker. |
| No bridge custody | It does not control bridge admin keys, release external collateral, or warehouse cross-chain assets. |
| No issuer sponsorship | It does not guarantee reserves, redemption, stable value, or asset legality for independent issuers. |
| No discretionary treasury desk | Funding follows published categories, caps, evidence requirements, challenge windows, and governance rules. |
| No hidden recovery switch | Official material does not imply universal deanonymization, account reconstruction, or secret compliance backdoors; required controls use only authority and data actually possessed. |
Failing one item does not always mean the feature is impossible. It means the feature no longer fits the narrow steward posture and must be redesigned or escalated to counsel with that fact visible.
Document Package
The legal architecture paper expects more than one page of disclaimers. It expects a coherent document package owned by the actors that actually exist. That package should include the main whitepaper, legal architecture paper, protocol use-and-risk notice, disclosures, governance and treasury policies where relevant, issuer and integrator disclaimers, and actor-specific documents. An actual website, wallet, program, or service operator must add the terms, privacy notice, wallet notice, grants policy, communication policy, and response process required for its own surface. A document title does not create an entity, contract, controller, support desk, or response authority.
The key rule is coherence across documents:
| If one document says | No other document may imply |
|---|---|
| The protocol is not an exchange. | The steward operates an official DEX, routing desk, or market. |
The wallet role is integral to Z00Z, z00z_wallets is a reference implementation, and custom implementations may conform; responsibilities follow actual functions and control. |
A software component is the responsible person, a user-selected profile certifies universal compliance, or self-custody transfers operator duties to the user. |
| Third-party assets remain issuer responsibility. | Z00Z approves, guarantees, recommends, or redeems those assets. |
| Disclosure is scoped and purpose-bound. | Every disclosure is optional, or there is a universal backdoor or audit mode. |
| Treasury is rule-bound. | Founders, insiders, agents, or models can redirect funds at will. |
Document coherence is not cosmetic. It is part of the proof that the project is trying to constrain itself.
Standing Reports
Some claims lose value if they are never refreshed. The companion page treats these reports as legal-hardening artifacts rather than launch marketing:
| Standing report | What it should show |
|---|---|
| Control, Affiliation, and Operational-Role Report | Who can upgrade what, who holds emergency powers, what powers expired, which wallet implementations and affiliated services exist, and whether any actor can redirect treasury or operations unilaterally. |
| Treasury limits report | How caps, categories, challenge windows, prohibited uses, and payout rules operated in practice. |
| Affiliated-service register | Whether any wallet, bridge, archive, market-facing service, or support channel is affiliated with the steward or founders. |
| Claims review log | Which official materials were reviewed against the claims matrix and what corrections were made. |
| Legal-order and incident notes | How requests were handled by layer and by actual possession of records or authority. |
The goal is not to publish sensitive private data. The goal is to keep non-control and layered responsibility evidenced over time.
Evidence Of Functional Separation
Evidence of functional separation shows that a boundary is not just a diagram. It can include separate keys, legal mandates, service terms, treasury authorization, published timelocks, challenge paths, independent audit contracts, verified operating-role statements, and disclosure of affiliated surfaces.
The best evidence is repeatable. It should show which reference-wallet, custom wallet, and other functions each identified project-linked actor actually distributes, operates, or controls, which functions are factually independent, and which controls follow each role. It should also show that AI reviewers, grant evaluators, or model registries cannot silently become treasury controllers.
Legal Hardening Roadmap
Near-term hardening should focus on public claims, entity boundaries, wallet language, founder disclosures, treasury limits, and issuer disclaimers. Mid-term hardening should add evidence standards, archive formats, wallet notices, corporate overlays, and standing reports. Long-term hardening should address mature multi-economy neutrality, richer governance evidence, model registry controls, and privacy-preserving audit workflows.
This order matters. Advanced operator-specific control layers do not fix basic documentary contradictions. A claims matrix and red-line checklist are more urgent than adding new speculative public promises.
Counsel Decision Points
Escalate to counsel before publishing or launching anything that touches:
| Decision point | Why it needs escalation |
|---|---|
| Foundation or steward wrapper form | Entity type is not a magic shield; real functions matter. |
| Stable asset policy | Allowing compatibility is different from sponsoring issuance, reserves, or redemption. |
| Anonymous rewards or useful-work programs | Evidence-bound rewards can drift into payroll, patronage, or hidden operator control. |
| User-configured jurisdiction policy profiles | Where a wallet supplies such a profile, the user selects, modifies, verifies, and maintains country or regional settings above base consensus, keeps records required for the user’s own conduct, and makes disclosures required from the user. A profile is not legal certification. |
| Geoblocking or restricted-jurisdiction controls | Useful as interface mitigations, not complete legal shields. |
| Reputation or scoring layers | Durable reputation can recreate a hidden account system if not tightly scoped. |
Read Next
- Public Claim Boundaries for the writer-facing claim matrix.
- Compliance Framework for the wallet-role responsibility map, user-configured jurisdiction policy profiles, records, and actual-function operator duties.
- Website Use And Risk Notice for the website notice boundary and requirements for actual service terms.
- Website Data-Boundary Notice for the difference between site privacy and protocol privacy.
Evidence and Further Reading
- Legal Architecture sections 17-20 define public-claims discipline, regulator response, hardening order, open questions, and counsel decision points.
- Legal Architecture appendices A-C define safe claims, claims requiring caveats, banned claims, red-line feature gates, document sets, standing reports, and documentary coherence rules.
- DAO appendix E supports model-governance and future-parameter caution, including the need to keep AI evaluation and value movement separated.
- Legal Architecture section 8 supports evidence packages, disclosure packages, corporate archives, and archive neutrality.