This companion is not a second summary of Legal Architecture. The main page explains the boundary. This page explains how to keep that boundary from drifting when docs, wallet notices, partner pages, governance materials, grant programs, and external responses are written later.
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 the steward does not operate a bridge but another says “our bridge,” the stronger statement is undermined. If one page says disclosure is optional and scoped but another promises universal auditability, the privacy 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 |
|---|---|---|
| What layer owns this claim? | The sentence names protocol, steward, wallet, issuer, service, or user responsibility precisely. | It speaks as if the whole ecosystem is one operator. |
| 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. | User, enterprise, auditor, service, or program operator that needs durable proof. |
| Disclosure package | Reveals scoped facts to a specific recipient without turning ordinary privacy into full transparency. | Actor choosing or required to disclose. |
| Corporate archive format | Organizes long-lived receipts, encrypted records, approval data, accounting links, and retention metadata. | Enterprise, regulated service, auditor, or recordkeeping-heavy operator. |
The steward may define formats and verification expectations. It should not become the global archive operator. That distinction is central to archive neutrality: Z00Z can make evidence verifiable without storing everyone’s business records.
Steward Boundary Checklist
Before a steward-linked page, grant, interface, or partnership is described publicly, verify these conditions.
| Boundary | Required evidence |
|---|---|
| No custody | The steward-linked surface does not hold user keys, user funds, reserves, or recoverable balances. |
| 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. |
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. The minimum set should include the main whitepaper, legal architecture paper, terms, privacy policy, disclosures, wallet notices, governance policy, treasury policy, issuer and integrator disclaimers, grants or useful-work policy, founder-allocation disclosure when relevant, communication policy, and regulator-response memo.
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 is self-custodial reference software. | The project holds accounts, keys, or recoverable user balances. |
| Third-party assets remain issuer responsibility. | Z00Z approves, guarantees, recommends, or redeems those assets. |
| Disclosure is optional and scoped. | There is a universal backdoor or universal 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 |
|---|---|
| Proof-of-Non-Control report | Who can upgrade what, who holds emergency powers, what powers expired, which 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.
Separation Proof
A separation proof is the practical evidence that the firewall is not just a diagram. It can include separate keys, separate legal mandates, separate service terms, separate treasury authorization, published timelocks, challenge paths, independent audit contracts, explicit no-operation commitments, and disclosure of affiliated surfaces.
The best separation proof is boring and repeatable. It should show that the steward can maintain standards and documentation without becoming the wallet, bridge, issuer, exchange, market maker, or customer-support archive for every downstream service. 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 compliance overlays 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. |
| Regulated wallet profiles | Compliance defaults belong above the core but may create service-layer duties. |
| 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.
- Terms Of Use for website-scope terms language.
- Privacy Policy for the difference between site privacy and protocol privacy.
Evidence and Further Reading
- Legal Architecture Whitepaper sections 17-20 define public-claims discipline, regulator response, hardening order, open questions, and counsel decision points.
- Legal Architecture Whitepaper appendices A-C define safe claims, claims requiring caveats, banned claims, red-line feature gates, document sets, standing reports, and documentary coherence rules.
- DAO Whitepaper appendix E supports model-governance and future-parameter caution, including the need to keep AI evaluation and value movement separated.
- Legal Architecture Whitepaper section 8 supports evidence packages, disclosure packages, corporate archives, and archive neutrality.