Privacy Notice

Last updated: 2026-07-27

In this notice, Z00Z Protocol means only the published software, cryptographic rules, and data formats. The word Z00Z does not, by itself, identify a company, controller, processor, service provider, node operator, aggregator, steward, DAO participant, or contracting party. Each such role must be attributed to the natural or legal person, public authority, association, or other body that actually performs or controls it.

The responsibility rules in this notice follow actual function, authority, and data possession. They do not change depending on whether a wallet, profile, archive, disclosure, pruning, transport, or other capability is current, experimental, planned, or independently implemented. Release-specific technical status is stated separately and does not reallocate legal duties.

1. Z00Z privacy model

The Z00Z Protocol is designed to minimize public observability while preserving cryptographic settlement validity. The base protocol is published software, data formats, and validation rules. It does not open customer accounts, assign real-world identities, hold user assets, or maintain a central customer database.

The protocol code is not a natural or legal person, public authority, agency, or other body. It cannot itself contract, possess personal data, determine the purposes and means of processing, answer a legal demand, or act as a data controller or processor. That statement does not classify any author, publisher, wallet distributor, website operator, node operator, aggregator, recipient, or other participant. Each participant’s role and duties follow the facts and applicable law, including any joint-control or operator duties that cannot be disclaimed by label or contract.

Publishing or contributing to Z00Z does not give an author, maintainer, or steward:

• a user’s seed, private keys, wallet password, or decrypted wallet;
• a universal administrator, recovery, freeze, or disclosure key;
• control of an independently operated Z00Z node or aggregator; or
• the ability to reconstruct every user’s private history.

Each person or body that operates a node, aggregator, Reticulum interface, OnionNet role, or compatible application is responsible for the infrastructure and records it actually controls. Permissionless eligibility under published protocol or DAO rules does not make an aggregator or node an agent of the protocol, its authors, a publisher, or another participant.

2. Data kept by the self-custodial wallet

In the reference-wallet model, the user controls the keys and wallet-local material used to recognize, possess, transfer, and disclose the user’s protocol objects, including assets, vouchers, and rights. That technical control does not by itself establish legal title, identity, capacity, consent, or regulatory classification. The base protocol does not require a real-world identity profile or an out-of-band account to validate an ordinary transaction.

Possession or control of wallet-local records is a factual statement, not a universal declaration that every user is a data controller. Any controller, processor, household-use, business-record, tax, reporting, or other legal classification depends on the user’s actual processing and applicable law.

The current reference wallet uses these local persistence planes:

• Seed, master key, spending material, owned objects, profile, and scan state: the user’s encrypted .wlt wallet container.
• Transaction events accepted by the current reference wallet: the user’s local append-only JSONL history sidecar, subject to the size boundary below.
• Portable recovery material: a user-created export or backup selected and protected by the user.

The transaction-history JSONL sidecar is local, but the current reference implementation does not automatically place it inside the .wlt encryption boundary. A user who needs confidentiality for that file must protect the device, filesystem, exports, and backups accordingly.

The current reference-wallet JSONL store accepts at most 10 MiB of encoded history and rejects a load or write above that boundary. It is not an unlimited archive or a legal-record retention service. A user who must retain a longer or independent record must preserve suitable exports, backups, or other records before that limit prevents additional history from being accepted. A custom wallet or operator must disclose its own actual storage, limit, encryption, export, and deletion behavior.

The base protocol does not store the user’s .wlt wallet or JSONL history sidecar. A seed, private key, wallet password, decrypted wallet database, wallet profile, and complete wallet-local history are not fields of the base public settlement state. This does not mean that settlement occurs with no protocol data; Section 3 identifies the narrower validity and replay state that network participants may need.

Wallet-local data is not transmitted merely because the wallet is opened. A transaction sends only the bounded package and evidence required by the selected protocol flow. A wallet must never place a seed, private key, wallet password, decrypted wallet database, unrelated history, or unrestricted backup inside a transaction package, Reticulum payload, OnionNet envelope, log, or telemetry record.

The user decides which wallet-local records to retain and is responsible for preserving records required for the user’s taxes, accounting, contracts, disputes, reporting, or other obligations. Losing local history or recovery material may make full history or spent objects impossible to reconstruct from protocol state.

3. Data kept for settlement validity

The Z00Z Protocol does not define a universal named account ledger or require a complete per-wallet transaction history on the base public layer. The applicable protocol profile instead requires network participants to maintain the minimum state needed to decide whether later state transitions are valid. Depending on that profile, the required state can include:

• current HJMT roots, active object commitments, and authenticated paths;
• current-unspent recovery material, such as a per-output public key, short scan tag, and encrypted recovery capsule;
• checkpoint roots, epoch anchors, finality certificates, and compact history commitments;
• claim-domain nullifier status and other replay-protection records; and
• spent-state or consumed-leaf evidence required to reject double spending.

This state is not a readable customer statement, but it is not “no data.” External information, endpoint compromise, repeated identifiers, timing, or a voluntary disclosure may allow someone to associate a protocol object with a person.

Nullifier language must remain flow-specific. Claim flows use claim-domain nullifiers to prevent repeated redemption. The current wallet-side claim store uses process memory unless an operator binds its supported row files; the current simulator binds those files and tests replay rejection across a restart. Where a claim is admitted to the canonical settlement path, the storage layer also records typed ClaimNullifier state. Regular spend proofs carry deterministic nullifier fields and reject duplicates, while checkpointed membership and deletion of the consumed asset leaf remain the authoritative consumed-state model. An operator of a production claim path must preserve the replay state required by the applicable protocol profile. Z00Z materials must not imply that every object family uses one universal nullifier store.

Current settlement state and the compact anchors needed to validate later transitions are not deleted merely because temporary challenge material expires.

4. Temporary challenge data and the target window

The current Z00Z protocol profile defines a target challenge-data window of 1,555,200 finalized blocks. This is nominally 90 days at a five-second finalized-block cadence, but it is a block-height rule, not a guarantee of exactly 90 calendar days. The window begins at the protocol-defined data-availability-publication-ready event (da_publication_ready).

During that window, eligible transaction packages, checkpoint bodies, non-derivable witnesses, deltas, and exact proof material may be retained so watchers and validators can test cryptographic validity, replay safety, and double-spend conflicts. This is a protocol challenge window. It is not a customer chargeback period, a legal limitation period, or a promise that a settled transaction can be reversed on request.

After the window, an eligible challenge object may be pruned only when every condition in the applicable versioned profile permits deletion, including required finality and epoch proof, no hold or open dispute, retained anchors and snapshot, archive quorum, and retention-ledger evidence. Pruning temporary material does not delete:

• current unspent settlement state;
• state roots or compact permanent anchors;
• finality certificates;
• required replay or spent-state records; or
• wallet-local history retained by a user.

Expiry therefore creates, at most, deletion eligibility for the expressly temporary object. It is not a representation that a transaction, every copy of its package, all personal data, or all information associated with a wallet is deleted after 90 days.

As of this draft, the repository contract sets pruning stage declared_only and activation scope local_test_only; it does not represent a production physical-pruning path. The 90-day plateau is therefore a target protocol contract, not a current production deletion warranty. No user should rely on automatic day-91 erasure until a specific release proves and publishes that behavior.

No protocol rule can recall copies already retained by a counterparty, an independent node, an archive, a carrier operator, a user-selected backup system, or the user.

5. Reticulum and OnionNet transport boundary

The target Z00Z transport model is:

1. the wallet creates a bounded, recipient-encrypted Z00Z inner envelope;
2. OnionNet applies the Z00Z privacy-ingress and replay discipline;
3. Reticulum or a carrier permitted by the active protocol profile transports opaque outer packets; and
4. the OnionNet exit removes only the transport wrapper before the narrow runtime ingress decryptor receives the inner envelope.

Reticulum is a carrier, not the Z00Z wallet, settlement engine, identity system, transaction archive, or finality authority. A Reticulum identity must remain separate from the wallet seed and wallet ownership identity.

Reticulum encryption and the absence of a source address inside a Reticulum packet do not eliminate all metadata. A directly connected interface, IP peer, radio neighbor, bridge, or local carrier process may observe ingress, timing, volume, destination or link identifiers, announces, and availability events. Traffic correlation remains possible. Reticulum alone is not a full mixnet or a guarantee against a global observer.

OnionNet is intended to reduce those risks through client-owned routes, multiple roles, fixed packet classes, replay binding, privacy floors, and bounded telemetry. It does not promise perfect anonymity.

At the date of this draft, the repository reserves the OnionNet crate and module boundary but labels it a placeholder; it does not yet ship a production Reticulum integration or a live OnionNet overlay. Reticulum and OnionNet privacy statements are therefore target-architecture requirements unless a specific release supplies implementation, test, deployment, and audit evidence.

6. Who may independently hold or infer data

The Z00Z base protocol does not create a single holder of all transaction information. Different participants can independently receive different fragments:

• A user wallet may hold keys, owned objects, wallet profile, scan state, locally accepted transaction-history records, and user-created exports.
• A counterparty may receive information intentionally included in a transaction or exchanged out of band.
• A validator, watcher, or aggregator may receive the bounded package, proof, root, checkpoint, replay, and validity material required for its function.
• A data-availability or challenge-archive participant may hold eligible challenge objects for the bounded retention period or for any longer period it independently applies.
• A Reticulum, bridge, relay, or carrier operator may see opaque packets and the local transport metadata visible at that role.
• An issuer, bridge, merchant, or other application may hold information received through its separate business or technical relationship.

Neither the protocol nor a person lacking control of the recipient’s copy can revoke information already disclosed to that recipient or erase that copy.

7. Scoped disclosure and possession-bound requests

Disclosure in Z00Z is possession-bound: it can originate only from information actually held by the user or another participant. Scoped evidence packages are an optional wallet or application layer, not a base-protocol archive. Where a specific release implements them, the release must identify the disclosed fields and must not silently export the user’s complete history. A recipient controls its received copy under the rules applicable to that recipient.

There is no universal Z00Z disclosure backdoor. A demand directed to protocol software cannot create keys, records, or infrastructure control that no responding person possesses. A legally bound person must assess and answer a valid demand from the data and authority that person actually controls.

The base protocol has no protocol-wide account, support desk, privacy inbox, or data-request endpoint. A request concerning a copy held by a particular wallet distributor, node, aggregator, carrier, issuer, bridge, merchant, or other operated interface must be directed to that actual holder. Where law requires an operated interface to identify itself or provide a request channel, that operator must do so in its own notice. Neither this notice nor the protocol can supply an operator identity, email address, Reticulum destination, or request channel that the operator has not actually established.

Calling an activity “protocol participation” does not remove duties that arise from operating a wallet product, node, aggregator, archive, carrier, issuer, bridge, merchant flow, or other service. This notice allocates no duty away from the person whose real functions create it.

8. User security and privacy limits

Z00Z privacy depends on more than cryptography. A user must account for:

• loss, theft, malware, screenshots, clipboard exposure, and compromised endpoints;
• unencrypted local history, unsafe exports, weak backups, and reused credentials;
• receiver, request, amount, timing, and counterparty correlation;
• records independently kept by counterparties or infrastructure operators;
• privacy degradation when route diversity or traffic volume is low; and
• future cryptographic, implementation, governance, or configuration defects.

Privacy does not establish the legality of a transaction or remove obligations applicable to the user. Protocol acceptance and optional wallet disclosure features are not legal certification. A person that operates a separate service remains responsible for the obligations arising from that service.

9. Changes and conformity

Material changes to this notice must be recorded in the public revision history and associated with the relevant release or protocol-profile status. A release, distributor, or operator must not claim conformity if a change to protocol code, wallet persistence, transport, telemetry, retention, or operator control makes a corresponding statement in this notice materially inaccurate.

A distributor or operator must not claim conformity merely because its software is Z00Z-compatible. It must verify the behavior it actually distributes or operates.

Mandatory law controls where it cannot be varied. A notice issued by an identified operator governs only that operator and the surface it identifies. Technical specifications describe protocol semantics; whitepapers, roadmaps, and implementation-status notes do not create, transfer, or amend legal duties.

Read Next

• Legal Architecture for the responsibility boundary between protocol, steward, wallets, services, and users.
• Compliance Framework for the wallet-role, implementation, and scoped-disclosure responsibility model.
• Disclosures for privacy-risk and third-party-service disclosures.
• Public Claim Boundaries for privacy wording that should and should not appear in public materials.
• Wallet-Local Possession for why possession stays wallet-local before public settlement and how this affects custody, payments, rights, and privacy.
• OnionNet for the target privacy-ingress model: client-owned route construction, transport roles, replay discipline, low-load privacy, and the limits of transport-layer claims.

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 sections 7, 9, and 14 support actor-specific compliance controls, wallet/interface boundaries, corporate-auditable modes, and regulated-service responsibilities.
• Legal Architecture sections 17-18 support safe privacy language, technical non-possession, and the rule that no one should imply a hidden universal recovery switch.