Disclosure must be intentional, scoped, and separate from checkpoint validity. Ordinary settlement observers should not reconstruct wallet-local meaning from public state, but an authorized recipient or valid required workflow may receive bounded evidence.
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 an authorized or legally required audience without changing settlement validity. Third, the core does not secretly possess every wallet-local fact merely because an above-core control can disclose selected facts. The canonical rule is defined in the Compliance Framework.
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.
| Artifact | What it should carry | What it should avoid |
|---|---|---|
| View key or scoped viewing key | Authority to inspect a defined object, period, asset family, or workflow slice. | Unbounded access to all wallet history. |
| Audit key | Enterprise or auditor-specific evidence access. | Converting every user transfer into corporate transparency. |
| Evidence package | Receipt, checkpoint root, policy proof, invoice hash, selected disclosure, and verifier context. | Hosted steward custody of everyone else’s records. |
| Disclosure package | Narrow facts for one reviewer, counterparty, tax process, audit, or dispute. | General publication of unrelated private state. |
| Corporate archive | Long-lived records retained by the company or service that needs them. | Treating the protocol as the company’s archive operator. |
These artifacts make disclosure practical without making it default.
User-Configured Jurisdiction Policy Profiles
The Z00Z reference wallet or a conforming custom wallet may add recordkeeping, policy checks, geographic controls, issuer controls, screening inputs, audit receipts, or jurisdiction-specific prompts above base consensus. The user may select, modify, or create the profile for the country or region the user intends to follow. The user selects, verifies, updates, and applies the profile, keeps the resulting transaction history and supporting records, makes disclosures required from the user, and remains responsible for duties applicable to the user’s own conduct. Wallet software does not assume or certify that responsibility.
An implementation can support confidentiality-focused, country or regional, business-use, and corporate-audit profiles if each profile states its maturity, records, disclosures, and defaults. The difference is not settlement validity; it is an above-core policy. A profile cannot certify compliance, waive a mandatory duty, or transfer the user’s responsibility to software.
Legal Request Boundary
A legal request should be answered by layer, authority, and actual possession. The user controls wallet-local history and should preserve records required for the user’s own conduct. An identified publisher or maintainer may explain protocol rules, checkpoint artifacts, and public evidence but cannot reconstruct private history it does not possess. A corporate user or separate regulated service may possess different records. Those sources are not interchangeable, and a request cannot create data or authority that the recipient does not have.
This is why project-linked material must not imply a hidden recovery switch or universal history reconstruction. Where records exist, identify who has them. Where they do not exist, do not imply that the Protocol or a maintainer 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 user-configured jurisdiction policy profiles. It does not justify saying that every ordinary transfer already has a production auditor-key flow, a maintained rule catalogue for every country, 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.
Claim Boundaries
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.
Support and legal copy must preserve the same limit. Support should not ask for a full wallet history when one redacted route, command, or public error is enough. Legal copy should not imply that the protocol can reconstruct records it never held. Product copy 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.
Every disclosure statement names an audience. Without one, it describes disclosure too broadly for a privacy-preserving system. A disclosure package also defines its time window, object family, and permitted purpose. It cannot authorize unrelated observation, replace external recordkeeping duties, or create a standing right to inspect future wallet activity.
For user-directed disclosure, the user chooses the lawful scope, preserves the supporting transaction history, and remains responsible for records and disclosures required from the user by competent authorities in the user’s jurisdiction. A wallet implementation supplies a tool and does not assume or certify the user’s responsibility. Each project-linked or independent operator retains collection, retention, handling, disclosure, and other duties arising from the functions, information, and authority it actually possesses.
Read Next
- Privacy Threat Model for adversaries and privacy anti-patterns.
- Legal Architecture for the legal non-knowledge boundary.
- Wallet SDK for the reference/custom implementation boundary.
- Compliance Framework for the canonical disclosure and wallet-role responsibility rule.
- Object Lifecycle for disclosure as one lifecycle branch.
Evidence and Further Reading
- Privacy Threat Model And Metrics sections 7-10 define wallet guidance, safe defaults, disclosure and regulated-flow boundaries, and communication guidance.
- Legal Architecture 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.