Z00Z privacy is not the claim that nothing is visible. It is the claim that public settlement should expose the narrow evidence needed for replay-safe validity while wallet-local ownership meaning, private rights, and ordinary transfer context avoid becoming a reusable public account graph. That is a strong privacy claim, but it is not an absolute anonymity claim.
This page keeps the model layered. It explains the major privacy surfaces, what different adversaries can see, where leakage can reappear, and which claims official documentation should avoid. Deeper operational topics belong in the security family: wallet QA, telemetry, incident response, transport hardening, and misuse handling should be read there after this architecture overview.
The Privacy Layers
The strongest internal privacy lane starts after ingress and before egress. A right may enter Z00Z from an issuer, bridge, merchant, treasury program, or local wallet event. It may then move through wallet-local possession, private package exchange, and checkpointed settlement. It may later exit into a redemption, bridge, merchant, corporate audit, or disclosure workflow. Each boundary has different visibility.
| Layer | What can be protected | What can still leak |
|---|---|---|
| Ingress | Internal transfer can begin after a public or service-side event | Source identity, exact deposits, issuer logs, narrow entry timing |
| Internal movement | Holder graph, amount meaning, rights meaning, and ordinary ownership context | Reused receive surfaces, thin timing windows, poor wallet behavior |
| Egress | Internal history need not become public by default | Redemption, bridge exit, merchant, auditor, or corporate sink context |
| Transport | Origin and route exposure can be reduced | Global observation, sparse load, helper metadata, route contraction |
| Wallet UX | Local meaning and secrets can remain local | Logs, exports, memos, receive reuse, broad audit packages |
| Disclosure | Purpose-bound evidence can be shared narrowly | Overbroad disclosure can recreate the graph outside settlement |
Adversaries And Visibility
Different adversaries see different surfaces. A passive settlement observer can see committed leaves, proof bytes, roots, deltas, and checkpoint timing. That observer should not learn wallet-local ownership meaning or decrypted amount contents. A bridge, issuer, or redemption counterparty may learn deposits, reserve routes, redemptions, or compliance records. A service operator may learn retries, batching behavior, publication timing, and provider signals. A compromised wallet can destroy privacy even if the settlement layer is correct.
That is why Z00Z documentation should avoid single-word claims like “anonymous” or “untraceable.” A careful claim says which surface is protected from which observer and which edges remain externally visible.
Leakage Boundaries
The largest leakage risks are usually workflow risks rather than pure cryptographic failures.
Repeated receiver or request material can give counterparties a stable local linkage surface. Exact-value ingress followed by immediate exact-value exit can narrow the plausible history even when the internal transfer was confidential. A collector pattern, where many private objects collapse into one obvious public sink, can undo the practical value of internal privacy. A star pattern, where one public source fans out into many private-looking objects, can still reveal that the objects share a visible source. Verbose logs, wallet exports, broad audit packages, and service retries may leak more than settlement does.
The architecture should therefore treat privacy as a system property. Commitments, encrypted packs, and checkpoints matter. So do wallet defaults, routing, disclosure UX, batching, support logs, and safe warnings.
Selective Disclosure, Audit, And Reveal
The corpus uses three related terms that should not be flattened.
| Term | Meaning | Typical trigger |
|---|---|---|
| Selective disclosure | A holder shares chosen facts with a chosen audience for a chosen purpose | Payment proof, tax record, corporate reporting, dispute evidence |
| Selective audit | An enterprise or operator prepares scoped evidence for a review workflow | Corporate, regulated, or program-specific accounting |
| Selective reveal | A liability-specific privacy narrowing after provable misuse | Fraud proof, conflict handling, linked-liability activation |
All three are compatible with privacy by design. None of them should become default public transparency. Disclosure widens visibility for a particular purpose. It does not rewrite the settlement theorem or turn every private transfer into public history.
Transport Is Helpful But Not Magic
OnionNet and future helper routing can materially improve origin privacy and route ownership. The intended direction is public membership, deterministic epoch views, client-owned route construction, bounded topology disclosure, and double-envelope confidentiality that keeps canonical payload meaning away from the exit where possible.
The non-claim is equally important. OnionNet does not promise universal anonymity against a fully global observer with unlimited timing visibility. It does not fix bad wallet export behavior. It does not erase bridge or redemption edges. It does not make a narrow service workflow unlinkable by itself. Transport privacy is one layer in the model, not a replacement for the model.
Metrics And Security Routing
This page should introduce privacy metrics without turning them into guarantees. Stage labels such as s_before, s_inside, and s_after can help wallets and simulators describe where privacy is strong or weak. Remix depth and diversity can help explain why a longer private interval may help. Concentration metrics can detect star and collector patterns. Exculpability checks can ask whether a fraud proof can frame an honest wallet or over-reveal unrelated history.
Operational detail belongs in the security pages:
- wallet anti-pattern tests and QA hooks belong with wallet and security guidance;
- transport and OnionNet failures belong with network and incident documentation;
- telemetry retention and export boundaries belong with privacy operations;
- liability-triggered reveal belongs with linked-liability and support procedures.
This routing keeps the protocol page readable while making clear that privacy is not finished by one diagram.
Safe Privacy Claims
Z00Z can safely say that it minimizes public observability compared with public account systems, keeps ordinary ownership meaning wallet-local, supports scoped disclosure, and avoids making every private transfer a public account mutation. It can also say that transport and wallet discipline can improve privacy quality where the implementation follows the model.
Z00Z should not say that nothing is visible, that no one can investigate anything, that external issuers or bridges lose their own records, that OnionNet defeats all observers, or that every workflow has identical privacy. Those claims are both technically weak and legally dangerous.
The safest habit is to name the observer, the protected surface, and the remaining edge in the same paragraph. A precise privacy claim is slower to write, but it survives review better than an absolute claim.
Current Versus Target Status
The internal privacy thesis is already central to the Z00Z architecture. The broader measurement system, OnionNet transport hardening, wallet QA hooks, selective audit packages, and mature disclosure workflows remain target or mixed-maturity surfaces. Public docs should therefore separate live core posture from future hardening work and should route operational guarantees to the pages that actually test them.
Read Next
- Selective Disclosure explains the positive disclosure model.
- Linked Liability explains conflict-triggered reveal.
- Post-Quantum Migration explains the legacy cryptography privacy boundary.
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 3 through 11 define the privacy dimensions, adversary classes, layered model, metrics, anti-patterns, wallet requirements, disclosure model, telemetry boundaries, and deployment limits.
- OnionNet Whitepaper sections 8 and 9 define transport threat surfaces, review priorities, crypto direction, failure posture, strengths, and tradeoffs.
- Legal Architecture Whitepaper sections 7 and 17 define selective disclosure, optional overlays, and safe public language for privacy claims.