This page separates two layers that are easy to confuse. The Z00Z protocol corpus discusses wallet-local possession, limited public observability, confidential settlement objects, optional scoped disclosure, and privacy threat models. A website or attached service has a different data surface: server logs, contact forms, security reports, analytics, support messages, third-party embeds, and service-provider records. Those surfaces must be described honestly and separately.
The safest privacy policy is evidence-based. It should only promise what the actual deployment can prove. If analytics are enabled, say so. If a contact form sends data to a third party, say so. If the site is static and collects only ordinary server logs, say so. Do not borrow protocol privacy language to hide ordinary website data handling.
Data Surface Map
| Surface | Typical holder | Why it exists | Wrong overclaim to avoid |
|---|---|---|---|
| Website request logs | Host, CDN, monitoring, or security provider | Reliability, abuse prevention, and troubleshooting | “Protocol privacy means the site sees nothing.” |
| Analytics events | Analytics vendor or site operator | Usage measurement and performance review | “Privacy-preserving settlement means no web telemetry exists.” |
| Contact or support messages | Project operator or service provider receiving the message | Replying or coordinating support | “Ordinary support is anonymous by default.” |
| Security reports | Project security reviewers and, when necessary, affected third parties | Triage and coordinated disclosure | “Security reporting never creates a data trail.” |
| Wallet-local material | User wallet or the wallet/service the user chose | Signing, backup, recovery, and disclosure | “The docs site automatically receives wallet history.” |
| Optional disclosure packages | The actor who created the package for a specific purpose | Audit, compliance, or dispute resolution | “Optional disclosure creates a universal backdoor.” |
Use this table as a separation rule. If a privacy sentence fits none of these surfaces, it is probably mixing layers.
Website Data
Website data may include technical request information such as IP address, user agent, referrer, timestamp, route requested, error traces, caching behavior, and security-event logs. This data may be processed by hosting providers, monitoring providers, CDN providers, analytics providers, or security tooling depending on the deployment.
The privacy policy should describe this data at the level the site can actually verify. It should not promise “no logs” unless the deployment has been reviewed to confirm that hosting, CDN, proxy, and monitoring layers do not retain them. It should not imply that protocol cryptography hides a user’s ordinary HTTP request to the documentation site.
Analytics And Logs
Analytics and logs should be narrow, documented, and optional where the implementation allows. Their purposes may include site reliability, abuse prevention, performance measurement, content-quality review, and security investigation. They should not become a hidden user-profile layer or a behavioral ledger that contradicts the privacy-first narrative.
If analytics are used, the page should identify the tool category, the purpose, the retention posture where known, and whether the provider is a third party. If no analytics are used, the page should still be careful about infrastructure logs because hosting platforms and security layers may retain data independently.
Contact Data And Support Messages
When a user sends a message, opens a support request, joins a program, submits a security report, or contacts the project through any form or email address, the user creates a direct data relationship. That data may include name, email address, handle, company, message content, attachments, issue metadata, and any personal or technical details the user includes.
Users should avoid sending secrets, private keys, recovery material, seed phrases, unnecessary personal data, unrelated third-party data, or exploit details beyond what is required for safe reporting. If a support or contact channel is operated by an independent service provider, that provider’s own privacy and retention rules may also apply.
Security Reports
Security reports require a narrower privacy rule because they often include sensitive technical detail. A report may include reproduction steps, affected versions, logs, code references, screenshots, or proof-of-concept data. The project should use those reports for triage, remediation, coordinated disclosure, and security evidence, not for unrelated profiling.
Reporters should submit the minimum data needed to validate the issue. The project should avoid asking for private keys, live funds, production user data, or broad exploit artifacts when a safer proof is enough. If an issue affects a third-party wallet, bridge, issuer, hosting provider, or integration, the responsible service may need to receive relevant details under its own process.
Protocol Privacy Is Not Site Privacy
Z00Z protocol privacy concerns what ordinary settlement observers can infer from public leaves, commitments, proofs, roots, checkpoints, wallet-local material, ingress and egress patterns, and optional disclosure workflows. It does not mean a documentation site visitor is invisible to the website host. It does not mean support channels are anonymous. It does not mean third-party providers cannot see requests sent to their infrastructure.
The protocol can minimize public observability while the site still handles ordinary web data. Keeping those statements separate protects users from false expectations and protects the project from overclaiming. Strong protocol language should remain scoped to the protocol.
Wallet Data And Optional Disclosure
Wallet data is not automatically website data. A self-custodial wallet may keep keys, receipts, notes, recovery data, labels, scan results, and disclosure material locally. A wallet provider, hosted service, corporate wallet, regulated service, bridge, issuer, or support tool may collect additional data under its own terms. The website should not imply it has access to wallet-local history unless a specific service actually transmits that data.
Optional disclosure is also scoped. A user, enterprise, auditor, or regulated service may create evidence packages, disclosure packages, or archive records for a specific purpose. That does not create a universal backdoor and does not mean every ordinary private transfer is public. The privacy policy should explain who possesses the relevant records and why.
Third-Party Services
Third-party services may include hosting providers, CDNs, analytics tools, form processors, email systems, search tools, media embeds, community platforms, wallet providers, bridges, issuers, auditors, and security tooling. Each may collect or process data independently.
The website should not describe third-party services as if their privacy posture is controlled by the Z00Z protocol. If a page links to or embeds a provider, readers should expect that provider’s terms and privacy policy to matter. If an integration is optional, the page should say so. If a third-party service is required for a specific feature, the page should identify that dependency rather than hiding it behind generic privacy branding.
User Controls And Practical Guidance
Readers who want to reduce website-level exposure can use ordinary web privacy practices: review browser settings, block unnecessary third-party scripts, avoid sending personal data through forms, read linked provider policies, and download documents for offline reading where appropriate. These steps are separate from protocol-level privacy practices such as avoiding exact-value ingress and egress, minimizing wallet metadata, using scoped disclosure carefully, and avoiding repeated receiver or route patterns.
The policy should not pretend one layer solves the other. Website privacy, wallet privacy, transport privacy, service privacy, and settlement privacy are related but distinct.
Retention And Correction Posture
Retention should follow the data owner and purpose. Ordinary website logs may be retained by hosting, CDN, monitoring, or security providers under their own settings. Contact messages may be retained long enough to answer the request, preserve business records, or handle security reports. Corporate archives, disclosure packages, and regulated-service records belong to the actor that chose that workflow and should not be described as protocol-hosted records.
If a user wants correction or deletion of site-level contact data, the request should go to the site or service channel that actually received the data. If the relevant record sits with a third-party service, wallet provider, bridge, issuer, employer, auditor, or regulated operator, that actor is the correct target. The protocol itself cannot edit a third-party mailbox, support ticket, corporate archive, or issuer ledger.
Read Next
- Legal Architecture for the responsibility boundary between protocol, steward, wallets, services, and users.
- Disclosures for privacy-risk and third-party-service disclosures.
- Public Claim Boundaries for privacy wording that should and should not appear in public materials.
Evidence and Further Reading
- Privacy Threat Model And Metrics sections 3, 7, 9, and 10 support the layered privacy model, selective disclosure discipline, wallet/operator pressure, and communication limits.
- Privacy Threat Model And Metrics section 6 supports the anti-pattern warnings against absolutist privacy claims, visible special privacy lanes, concentration patterns, and operational leakage.
- Legal Architecture Whitepaper sections 7, 9, and 14 support optional compliance overlays, wallet/interface boundaries, corporate-auditable modes, and regulated-service responsibilities.
- Legal Architecture Whitepaper sections 17-18 support safe privacy language, technical non-possession, and the rule that no one should imply a hidden universal recovery switch.