Privacy in Z00Z should be read as a layered budget, not as a magic label. The protocol narrows the public settlement surface and keeps ownership meaning wallet-local where the design supports it. That does not mean every action a user, wallet, operator, bridge, service, or reviewer takes is private by default. Privacy can be spent by repetition, timing, metadata, concentration, disclosure, and support behavior even when the underlying settlement object is designed correctly.
The budget metaphor is useful because it forces precise questions. Which layer is consuming privacy? Is the loss caused by the public artifact, the network route, the wallet UI, an external issuer, a support conversation, or voluntary disclosure? Is the loss reversible, bounded, or permanent? Does the page describe a protocol property or an operational habit? If those questions are not visible, the privacy claim is probably too broad.
Leakage Map
The wallet layer can spend privacy through unsafe backups, repeated device fingerprints, careless screen sharing, broad logs, or UX that encourages users to merge contexts. The network layer can spend privacy through timing, route reuse, low-load conditions, or ingress and egress patterns that reveal more than the settlement artifact itself. The public artifact layer can spend privacy when repeated publication shapes, checkpoint timing, or object families become easy to distinguish. The service layer can spend privacy through issuer records, bridge edges, support tickets, analytics, or operational logs. The disclosure layer can spend privacy instantly when a user or organization reveals screenshots, receipts, private exports, or audit packages too widely.
Budget Consumers
| Consumer | How privacy is spent | Safer posture |
|---|---|---|
| User behavior | Reusing counterparties, posting receipts, sharing screenshots, or mixing contexts | Teach users what not to reveal and keep support no-secret by default |
| Wallet UI | Displaying confusing states, hiding risk, merging histories, or encouraging unsafe backup flows | Use explicit warnings, quarantine unsupported objects, and separate contexts |
| Network timing | Publishing at predictable times, using thin routes, or operating under low-load conditions | Treat transport privacy as measurable and bounded |
| Public artifacts | Creating distinctive package, batch, or checkpoint patterns | Keep claims tied to what the public layer actually reveals |
| External services | Issuers, lockers, bridges, and support tools retaining edge records | Name the service boundary instead of calling it protocol privacy |
| Disclosure choices | Audit, legal, support, or community reporting revealing more than needed | Reveal the minimum evidence for the specific purpose |
Practical Examples
An offline cash handoff can preserve local possession before publication, but if the receiver immediately posts a screenshot of the payment request in a public chat, the disclosure layer spends the budget. A private external-asset right can move internally without every reassignment appearing on the source chain, but deposit and redemption edges may still be visible to the outside issuer or locker. A corporate settlement flow can use selective disclosure, but an overly broad audit export can recreate the graph that settlement privacy avoided. An OnionNet route can reduce transport exposure, but route reuse and low-load timing still need measurement rather than slogans.
Those examples are not failures of the protocol thesis. They are the reason privacy pages need budget language. The right claim is not “Z00Z protects every behavior.” The right claim is that the corpus defines narrower settlement, transport, wallet, service, and disclosure boundaries that can preserve privacy when each layer is operated carefully.
Budget Rules For Writers
Use layer-specific language. Say “public settlement evidence is narrow” when discussing checkpoints. Say “transport metadata remains a separate risk” when discussing network routes. Say “support cannot safely handle secrets” when discussing help channels. Say “selective disclosure should be purpose-bound” when discussing audit or legal evidence. Avoid collapsed language such as “private by default” unless the sentence immediately identifies the layer and the caveat.
Use measurement language when the claim depends on behavior. Linkability, distinguishability, timing correlation, route exposure, low-load privacy, wallet behavior, and disclosure scope are not all measured the same way. Some can be checked with local tests. Some require simulation. Some require operational telemetry that must not become a new surveillance surface. If no measurement exists, write “must be measured” rather than “is solved.”
What This Page Does Not Promise
This page does not promise universal anonymity, endpoint safety, perfect transport cover, safe public disclosure, issuer silence, or guaranteed recovery from user mistakes. It also does not create a new consensus rule. It is a reader-facing guide for preserving the privacy value that the protocol architecture tries to create. The privacy threat model remains the primary authority for formal adversaries, metrics, anti-patterns, and acceptance criteria.
Budget Review Checklist
Before publishing a privacy claim, answer these checks. Which observer is being discussed: public chain observer, network observer, wallet operator, issuer, support channel, auditor, or counterparty? Which artifact is visible: checkpoint root, package timing, route metadata, support evidence, audit export, or external custody record? Which behavior could repeat and become linkable? Which disclosure is voluntary but risky? Which measurement would prove the claim under realistic low-load and repeated-use conditions?
If those checks cannot be answered, the safest wording is not a broad privacy promise. Use “the corpus intends to reduce…” or “this layer must be measured…” until evidence exists. This protects the user because it prevents a page from converting one private surface into a whole-system assurance. It also protects the project because later incidents can be evaluated against stated boundaries rather than against slogans.
Common Budget Mistakes
The easiest mistake is context merging. A user treats one wallet, one counterparty, one issuer, and one public support identity as interchangeable. Each merge makes future correlation easier. Another mistake is “helpful disclosure,” where a user sends an oversized screenshot, logs, wallet export, or receipt bundle because they want fast support. A third mistake is low-load overconfidence: a route or batch that looks private in a busy system may be distinguishable in a quiet one. The final mistake is legal over-sharing, where an organization reveals a full settlement history when a scoped evidence package would have answered the question.
The practical rule is conservative: spend privacy only for a purpose, reveal only the evidence needed for that purpose, and treat every repeated public pattern as a possible future correlation handle.
Safe Support Examples
Support is one of the fastest ways to spend privacy accidentally. A safe report says: “the docs route /docs/security/privacy-budget renders incorrectly after this commit and npm run verify fails in search coverage.” An unsafe report includes a wallet screenshot, a private receipt, a seed phrase, or a full support chat transcript. A safe privacy incident report redacts identifiers and explains the class of leak. An unsafe report publishes the exact exploit steps or private artifacts before triage.
Use that same discipline for legal and audit contexts. If a reviewer needs proof that a payment happened, give the scoped proof needed for that reviewer, not an entire wallet history. If a community needs aggregate evidence, do not publish recipient identities unless the legal and operational boundary specifically requires it. Privacy budget is often lost through oversized evidence, not broken cryptography.
Read Next
Read Threat Model for adversaries, Privacy Metrics for measurement language, Responsible Disclosure before sending sensitive reports, and Wallet Recovery Safety before sharing any wallet-related evidence.
Evidence and Further Reading
- Privacy Threat Model And Metrics sections 3 through 10 define privacy scope, layered threats, metrics, anti-patterns, wallet requirements, OnionNet boundaries, disclosure, telemetry, and acceptance criteria.
- OnionNet Whitepaper sections 5 through 9 define route construction, transport roles, replay and low-load privacy, threat model, and trade-offs.
- Legal Architecture Whitepaper sections 7 and 9 define selective-disclosure and service-responsibility boundaries that prevent privacy language from becoming an unsupported legal or operator promise.