Z00Z privacy is strongest when ordinary settlement observers cannot reconstruct wallet-local meaning from public state. That does not mean no one can ever receive evidence. It means disclosure should be intentional, scoped, possessed by the actor who needs it, and separate from the rule that makes a checkpoint valid.

Selective disclosure answers a narrow question: how can a user, enterprise, auditor, issuer, service provider, or regulator-facing workflow see a specific slice of evidence without turning ordinary private settlement into a public account graph? The answer is multi-view architecture. One settlement core can support a public settlement view, a wallet-local secrecy view, an operator evidence view, an auditor view, a corporate archive, and a conflict-triggered liability view, as long as those views remain bounded.

Disclosure Path

The path shows three separate facts. First, ordinary settlement evidence is public but narrow. Second, disclosure can widen visibility for a chosen audience without changing settlement validity. Third, the core does not secretly possess every wallet-local fact merely because some overlays can disclose selected facts.

Ordinary Privacy

Ordinary privacy means ownership meaning stays wallet-local by default. Public observers may see commitments, proof bytes, checkpoint roots, deltas, timing, publication records, and other public artifacts. They should not see a permanent public account row, plaintext amount, wallet-local inventory, receiver secret, memo, or full private object history.

This privacy is not absolute. Ingress, egress, exact timing, service logs, support exports, receiver reuse, issuer records, bridge events, and corporate archives can all narrow privacy. The disclosure model must admit those limits instead of hiding them behind slogans.

Scoped Disclosure Objects

Disclosure should be artifact-based rather than slogan-based. A useful disclosure package identifies which facts are revealed, to whom, for what purpose, and how those facts bind back to settlement evidence.

These artifacts make disclosure practical without making it default.

Regulated Wallet Modes

Regulated or corporate wallets may add stronger recordkeeping, policy checks, geoblocking, issuer controls, AML screening, audit receipts, or jurisdiction-specific prompts. Those features belong above the core. They may be useful and even necessary for some actors, but they should not be described as if the base protocol itself became a regulated-service engine.

The same protocol can support a privacy-maximal wallet, a regulated-jurisdiction wallet, and a corporate auditor wallet if each wallet is honest about its role. The difference is not settlement validity. The difference is what records, disclosures, defaults, and service obligations the chosen wallet or service adds.

Legal Request Boundary

A legal request should be answered by layer and by possession. The core can explain protocol rules, checkpoint artifacts, public evidence, and why it does not keep certain records. A wallet provider may possess support data or optional records. A corporate user may possess invoices and archive records. A regulated service may possess customer files. Those are not interchangeable.

This is why official material must not imply a hidden recovery switch or universal history reconstruction. Where records exist, identify who has them. Where they do not exist at the core, do not pretend the protocol can recreate them.

Conflict-Triggered Reveal

Selective disclosure is not the same as Linked Liability, but they share the same discipline: reveal only what the workflow requires. In a fraud case, the system may need to reveal a liability domain, fraud proof, bond reference, penalty policy, and affected right family. It should not reveal unrelated wallet history or unrelated assets.

That distinction protects exculpability. Honest users should not be framed by incomplete conflict artifacts, and dishonest users should not force everyone else into public-account surveillance merely because a liability path exists.

Builder Checklist

Builders should classify every disclosure feature before implementing or documenting it. The first question is who asks for the evidence: the user, a counterparty, an enterprise auditor, a regulated service, an issuer, a bridge, a court, or a support team. The second question is who actually possesses the evidence. The third question is whether the same result can be delivered with a narrower object, shorter time window, or smaller audience.

Good disclosure design has four properties:

• it names the recipient and purpose;
• it binds disclosed facts back to checkpoint or package evidence;
• it avoids unrelated wallet history by default;
• it lets the user or service understand what cannot be reconstructed by the core.

If a feature cannot answer those questions, it should be described as target architecture rather than as a live disclosure guarantee.

Live Versus Target Posture

The current corpus supports privacy-first settlement, wallet-local meaning, redacted or unavailable wallet fields, publication evidence, and audit-wrapper concepts. It also supports the target direction of richer view keys, audit keys, disclosure packages, corporate archives, and regulated wallet profiles. It does not justify saying that every ordinary transfer already has a production auditor-key flow or a universal corporate export mode.

That maturity distinction should appear in product copy. “Selective disclosure is a design direction with current building blocks” is safer than “every transfer is already enterprise-auditable.” The first statement reflects the corpus. The second collapses future overlays into present-tense protocol behavior.

Closeout Review Notes

Selective disclosure should be reviewed with the same strictness as privacy claims. Too little disclosure can make a workflow unusable for auditors, issuers, regulated services, or dispute handlers. Too much disclosure recreates the public account graph that the protocol is designed to avoid. The safe middle is purpose-bound evidence: recipient, purpose, time window, object family, settlement anchor, and residual facts that remain outside the package.

This page should also constrain support and legal copy. A support page should not ask for a full wallet history when one redacted route, command, or public error is enough. A legal page should not imply that the protocol can reconstruct records it never held. A product page should not advertise universal auditability unless the exact disclosure surface exists. Disclosure is useful because it is scoped; when it becomes universal, it stops being selective.

A final review should ask whether each disclosure sentence names an audience. If the audience is missing, the page is probably describing disclosure too broadly for a privacy-preserving system.

Read Next

• Privacy Threat Model for adversaries and privacy anti-patterns.
• Legal Architecture for the legal non-knowledge boundary.
• Object Lifecycle for disclosure as one lifecycle branch.

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.

• Privacy Threat Model And Metrics sections 7-10 define wallet guidance, safe defaults, disclosure and regulated-flow boundaries, and communication guidance.
• Legal Architecture Whitepaper sections 7-9 and 14 define visibility modes, scoped disclosure primitives, wallet/interface boundaries, and corporate-auditable overlays.
• Main Whitepaper section 6 defines current privacy lanes, target selective disclosure, and one settlement core with different visibility policies.