Privacy metrics are useful only when they stay narrower than the privacy claim itself. If a project publishes one dramatic score and calls it “privacy,” readers start assuming that the score covers everything: public observability, wallet leakage, transport metadata, disclosure overlays, operator retention, and user behavior. It never does. Z00Z needs privacy metrics that clarify tradeoffs, not a cosmetic leaderboard.
What Privacy Metrics Should Actually Measure
A good privacy metric in Z00Z should answer one bounded question at a time:
| Metric family | Real question |
|---|---|
| Public observability | How much can a public settlement observer infer from the visible artifacts alone? |
| Request and receiver hygiene | How often are reusable identifiers, cards, or request patterns widening correlation risk? |
| Operator exposure | Which surfaces can aggregators, archives, or watchers observe even when settlement remains valid? |
| Disclosure pressure | How often do workflows require extra evidence outside the narrow base settlement core? |
| Service reliance | How much privacy depends on external bridges, issuers, or interface behavior rather than native protocol rules? |
Each family measures a different failure mode. Mixing them into one scalar score hides the very distinctions that the threat model is trying to preserve.
Useful Metric Principles
The corpus suggests five practical rules.
First, prefer bounded metrics over totalizing scores. Second, measure what the chosen observer can actually see. Third, keep collection proportional to the question so the metric does not become its own privacy leak. Fourth, separate live measurements from design targets. Fifth, publish caveats alongside the metric rather than in a footnote nobody will read.
Those rules matter because a privacy metric can itself become a surveillance surface if it starts gathering unnecessary detail.
Examples Of Good Metric Families
The following kinds of metrics can be useful when scoped correctly:
| Metric example | Why it can help | Important caveat |
|---|---|---|
| Receiver or request reuse frequency | Identifies correlation pressure caused by repeated public-facing artifacts | Reuse alone does not prove compromise; context matters |
| Share of flows that require external-service disclosure | Shows how often privacy depends on an overlay rather than the base protocol | External-service use is not automatically bad, but it widens trust assumptions |
| Publication-delay and retry patterns | Helps study operator-side timing surfaces | Timing measurement must not be oversold as ownership disclosure proof |
| Audit-package frequency by workflow type | Reveals where selective disclosure is operationally necessary | A higher count does not automatically mean weaker core privacy; it may reflect regulated overlays |
| Wallet-side warning acceptance or unsafe-sharing incidents | Helps improve user safety messaging | User telemetry must be minimized and handled carefully to avoid creating new leaks |
These families are useful because they teach something concrete without claiming to settle the whole privacy question.
What Not To Measure Carelessly
Some ideas are attractive precisely because they are dangerous:
- a global privacy score for the whole ecosystem;
- user-ranking systems that recreate hidden persistent identity;
- raw collection of wallet-local secrets, request payloads, or disclosure bundles for analytics;
- metrics that imply a third-party issuer or bridge is as safe as the base protocol merely because it is popular;
- dashboards that turn optional disclosure into a silent default.
The legal and terminology papers both push against these shortcuts. Privacy should not collapse into a scorekeeping system that quietly recreates the account model through telemetry.
Live Versus Target Metrics
This repository currently proves the language of privacy metrics better than it proves a global live measurement program. That is acceptable as long as the docs stay honest about it. The safe present-tense claim is that Z00Z needs privacy metrics that remain observer-specific, evidence-backed, and minimization-aware. The stronger target claim is that future operators, wallets, researchers, or enterprise overlays may publish scoped metrics once they can do so without widening disclosure or silently centralizing data.
In other words, the maturity boundary is not “no metrics.” It is “no fake certainty.”
How Metrics Relate To Incidents
Privacy metrics should also help incident response. If a support scam wave starts requesting seed phrases, if a disclosure overlay begins collecting too much detail, or if an operator lane starts widening timing exposure beyond expectations, that should show up as a measurable change in one bounded metric family. A good metric therefore acts as an early warning, not as a marketing badge.
When a metric becomes a public claim, it should be reviewed with the same skepticism as any other security claim: who measured it, what observer model it assumes, and what it still does not prove.
Privacy Measurement Map
Metrics should classify claims, not decorate them. If a claim is measured only for one workload, call it bounded. If it depends on future telemetry, call it target architecture. If it depends on user behavior, say which behavior. If it depends on a service, name the service boundary. A privacy metric that cannot change public wording is probably not the right metric.
Telemetry Constraints
Privacy telemetry must not become a second surveillance layer. Aggregate counters, local tests, simulations, and adversarial reviews can be useful, but they need explicit minimization. A wallet should not collect detailed user behavior merely to prove that it is private. A network should not retain rich route histories casually. A support process should not ask for more evidence than needed. The privacy threat model is explicit that measurement and telemetry must remain scoped to the claim being tested.
Acceptance Criteria For Privacy Claims
A privacy claim should pass four tests before it appears in strong wording. The adversary is named. The visible artifact is named. The workload or behavior is described. The residual leak is stated. If any of those is missing, the claim should be softened. For example, “OnionNet improves transport privacy under the route assumptions described in the OnionNet paper” is safer than “network activity is anonymous.” “Selective disclosure narrows what a reviewer receives” is safer than “audits reveal nothing.”
Metrics should also include negative examples. A star pattern, collector pattern, repeated counterparty, thin route, or oversized disclosure may all be valid evidence that privacy quality is lower than expected. Good measurement is allowed to make the project less comfortable.
Review Notes
Privacy metrics should never be used as public decoration. If a metric is collected, explain how it changes decisions. If it does not change wallet warnings, route choices, disclosure policy, incident severity, or public claim wording, it may be unnecessary or even harmful. The project should prefer fewer metrics with clear decisions over broad telemetry that creates new privacy risk.
Reviewers should also reject single-score privacy. A page can summarize, but it should not collapse linkability, timing, disclosure, wallet behavior, and transport metadata into one number. The more sensitive the claim, the more the metric needs context.
Final Boundary
A metric that cannot be explained to a user, wallet developer, or incident reviewer is not ready for strong public wording. Keep measurement language tied to decisions and evidence.
Read Next
Read Privacy Budget for behavior-level leakage, Threat Model for adversaries, and OnionNet for route and low-load privacy boundaries.
Evidence and Further Reading
- Privacy Threat Model And Metrics sections 5 and 10 and sections 3, 4, 6, 7, and 9 are the main source anchors for observer classes, metadata surfaces, anti-patterns, wallet QA, disclosure, telemetry, and acceptance criteria.
- OnionNet Whitepaper sections 7 through 9 anchor replay, backpressure, low-load privacy, carrier discipline, threat-model, and trade-off language.
- Main Whitepaper sections 5, 6, 8, 9, 12, Appendix C, and Appendix D explain wallet-local meaning, public settlement evidence, operator timing surfaces, and the narrower current maturity of richer disclosure overlays.
- Legal Architecture Whitepaper section 7 and sections 9, 14, 17, and Appendix A warn against public wording that turns optional overlays or interface mitigations into overbroad claims.
- Corpus Terminology And Abbreviations Reference sections for privacy threat model, optional disclosure, and audit vocabulary keep metric names precise.