Terms Of Use

Last updated: 2026-07-27

This notice describes the use and responsibility boundary for the Z00Z base protocol, Z00Z specifications, and the Z00Z reference self-custodial software. It is not a contract for a website, hosted account, custodial product, exchange, bridge, or independently operated Z00Z-compatible service.

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, service provider, operator, steward, DAO participant, or contracting party. Legal roles attach to the natural or legal person, public authority, association, or other body that actually performs or controls the relevant function.

1. Scope and hierarchy

The Z00Z Protocol is software and cannot itself be a contracting party. Applicable source-code licences govern the rights to copy, use, modify, and distribute each file or package. This notice does not add a field-of-use restriction to software distributed under an open-source licence and does not override a licence, third-party notice, or mandatory law.

The legal hierarchy is:

1. mandatory law controls where it cannot be varied;
2. the applicable software licence controls copying, modification, and distribution of licensed code;
3. an agreement identifying an actual operator and covered surface governs only that operator and surface if valid assent and other requirements are satisfied;
4. this notice operates only as the protocol and reference-software use and risk notice described below; and
5. technical specifications govern protocol semantics, while whitepapers, roadmaps, examples, and implementation-status notes do not create or amend contractual obligations.

Because this notice does not identify a centralized Z00Z service provider, it does not create a customer account, custody, agency, fiduciary, recovery, or support relationship. A person that separately distributes or operates a product and seeks contractual terms must identify itself and establish any assent required for those terms.

An independently operated wallet, node, aggregator, Reticulum interface, OnionNet role, issuer, bridge, merchant flow, archive, or other service has its own operator, terms, controls, and responsibilities. Compatibility with Z00Z does not make that operator an agent, partner, branch, or representative of the protocol, its authors, or another participant.

Any person that satisfies the published technical and governance admission rules may operate an aggregator where the applicable protocol profile permits it. Eligibility under protocol or DAO rules does not create agency, partnership, endorsement, custody, or a project-operated service relationship.

2. What the Z00Z Protocol does

The Z00Z Protocol is a privacy-preserving settlement protocol. It defines cryptographic objects, transaction formats, proof rules, current-state transitions, replay boundaries, checkpoints, and finality conditions. A conforming verifier determines whether a submitted transition satisfies those rules.

That cryptographic verification is not legal notarization and does not prove:

• the real-world identity, capacity, consent, or authority of a key holder;
• legal title to an asset or off-chain property;
• the legality, tax treatment, sanctions status, or regulatory classification of a transaction;
• the existence, solvency, reserves, or redemption ability of an issuer, bridge, custodian, or counterparty; or
• that a participant has satisfied duties applicable to that participant.

The base protocol is not a bank, custodian, broker, exchange, market maker, payment processor, asset issuer, redemption desk, fiduciary, legal adviser, or tax adviser. It does not open named customer accounts or undertake to execute, reverse, freeze, recover, or monitor transactions for a user.

Those statements describe the base software boundary. They are not categorical legal conclusions about a person that operates a Z00Z function.

3. No universal operator or key

The Z00Z Protocol defines common rules but does not give its authors or maintainers a universal wallet key, node key, administrator key, recovery key, or disclosure key. Creating, publishing, or maintaining the software does not provide access to user wallets or independently operated nodes.

This does not mean that no person controls any infrastructure. A node, aggregator, carrier interface, wallet build, or other deployment remains under the authority actually retained by the person or mechanism that deploys, configures, or holds its relevant credentials. Any governance, upgrade, emergency, admission, fee, or treasury power belongs to the person or mechanism that can actually exercise it. Decentralization or DAO control must not be claimed until the live deployment and its powers prove that claim.

4. Self-custody and user responsibility

A person using a self-custodial Z00Z wallet remains responsible for:

• controlling and protecting the user’s seed, private keys, device, wallet password, and recovery material;
• verifying recipients, object type, asset identifier, amount, fees, network, protocol profile, and transaction state before acting;
• protecting the local wallet, append-only transaction-history sidecar, exports, backups, and any evidence package the user creates;
• retaining records required for the user’s tax, accounting, contractual, reporting, dispute, or other legal obligations;
• determining whether the user’s transaction and use of an asset or service is lawful in the relevant jurisdiction; and
• recognizing the risk of loss from lost or compromised credentials, mistaken instructions, unsafe devices, or inadequate backups; legal responsibility for any loss remains subject to mandatory law and any valid agreement that applies to the relevant actors.

Protocol acceptance proves only that the required cryptographic authority and validity predicates were satisfied. It does not prove that a signature was produced with the key holder’s real-world consent. A compromised key may still produce a cryptographically valid instruction.

Protocol acceptance, a wallet display, or an optional wallet disclosure feature is not legal advice, legal certification, or a guarantee that the rules applicable to a user are complete or current.

Self-custody does not transfer to the user a duty arising from a product, interface, data flow, or service actually distributed, operated, or controlled by another person. Each actual operator remains responsible for that operator’s own functions.

5. Wallet history and protocol state

The base protocol is not designed to keep a complete named transaction history for each user. The reference wallet records accepted transaction events locally in an append-only JSONL sidecar, while wallet secrets and owned-state material are kept in the encrypted .wlt container. The JSONL history is not automatically inside the .wlt encryption boundary. The current reference-wallet store accepts at most 10 MiB of encoded JSONL history and rejects a load or write above that boundary; it is not an unlimited archive or legal-record retention service. The user must preserve suitable exports, backups, or other records before that limit prevents additional history from being accepted where longer retention is required from the user.

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. The narrower settlement, replay, and consumed-state records described below remain outside that statement.

The applicable protocol profile requires network participants to maintain the state needed for future validity. This can include current HJMT roots and object commitments, current-unspent recovery capsules, checkpoint and epoch anchors, finality certificates, claim-nullifier status, and other replay or consumed-state evidence.

Nullifier semantics are flow-specific. Claim flows use claim-domain nullifiers. The current wallet-side claim store uses process memory unless an operator binds its supported row files; the current simulator binds those files, while canonical settlement records typed ClaimNullifier state for an admitted claim. Regular spend proofs carry deterministic nullifier fields and reject duplicates, but 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. No term in this notice should be read as saying that every Z00Z object uses one universal nullifier store.

The user must not rely on public settlement state to recreate the wallet’s local transaction-history sidecar, profile, recovery bundle, or private ownership context.

6. Target challenge window

The current target protocol profile defines a challenge-data period of 1,555,200 finalized blocks, nominally 90 days at five seconds per finalized block. The period begins at the protocol-defined data-availability-publication-ready event (da_publication_ready), not when a user first prepares a transaction.

During the window, eligible packages, checkpoint bodies, witnesses, deltas, and proof material may remain available for cryptographic challenges, replay checks, and double-spend conflict analysis. This mechanism is not a consumer chargeback, arbitration process, legal limitation period, or promise of reversal.

After expiry and satisfaction of every condition in the applicable versioned profile—including required finality and epoch proof, no hold or open dispute, retained anchors and snapshot, archive quorum, and retention-ledger evidence— eligible temporary challenge objects may be pruned. Current settlement state, required replay or spent-state records, state roots, compact anchors, finality certificates, wallet-local history, and independently retained copies remain outside that deletion-eligibility statement.

The repository contract currently sets pruning stage declared_only and activation scope local_test_only; it does not represent a production physical-pruning path. Automatic deletion after the target window is not a current production warranty. Independent participants may also keep their own copies. The user remains responsible for records required from that user regardless of protocol pruning.

7. Transaction and finality risks

Z00Z software may distinguish transaction stages such as prepared, submitted, published, checkpointed, and settled. A local display, package, receipt, relay acknowledgement, or data-availability event is not final settlement unless the applicable finality rules are satisfied.

Use of Z00Z involves risks including:

• software defects, cryptographic failures, incompatible upgrades, and unsafe configuration;
• delayed, rejected, censored, replayed, conflicting, or unavailable transactions;
• chain reorganization, checkpoint, proof, data-availability, or operator failure;
• loss of route diversity or privacy under sparse traffic;
• device, key, backup, counterparty, issuer, bridge, and carrier compromise; and
• loss of access to local history or objects that the public state cannot reconstruct.

No transaction state, receipt, audit, or proof eliminates all technical, economic, legal, or counterparty risk.

8. Reticulum and OnionNet

The target Z00Z transport architecture places a recipient-encrypted inner envelope inside OnionNet privacy framing and uses Reticulum or a carrier permitted by the active protocol profile to move opaque outer packets. Reticulum is transport only. It does not determine wallet ownership, transaction validity, settlement, finality, or compliance.

Reticulum packet encryption and omission of source addresses do not prevent a direct peer, radio neighbor, bridge, carrier process, or global observer from using ingress, timing, volume, destination, link, announce, or availability metadata. A Reticulum identity must not be derived from a wallet seed or reused as a wallet ownership identity.

OnionNet is intended to add client-owned routes, replay binding, role separation, packet classes, and privacy-floor behavior. It does not guarantee perfect anonymity.

At the date of this notice, the repository’s OnionNet crate is a placeholder boundary and the repository does not ship a production Reticulum integration or live OnionNet overlay. Any representation that those paths are live requires release-specific implementation, deployment, test, and audit evidence.

9. Assets, vouchers, rights, and external promises

The Z00Z validation rules apply to protocol objects representing cash-like assets, vouchers, rights, claims, and other policy-bound objects. Acceptance by a conforming verifier proves only the defined protocol predicate. It does not make every object legal tender, money, property, a security, a deposit, an entitlement, or an enforceable off-chain claim.

An external issuer, bridge, locker, merchant, custodian, or counterparty is responsible for its own asset, reserves, custody, redemption, disclosures, services, and legal obligations. Z00Z compatibility is not approval, endorsement, verification of reserves, or a guarantee of performance.

A user should examine the object type and the actual issuer, custodian, redemption, bridge, or counterparty terms before relying on a voucher, right, wrapped asset, redemption promise, or off-chain representation. This risk notice does not replace any disclosure that the actual operator or issuer is legally required to provide.

10. Independent implementations and operators

A fork, custom wallet, node, aggregator, relay, archive, or other compatible implementation may change persistence, telemetry, transport, retention, privacy, fees, controls, or security behavior. The person distributing or operating that implementation must disclose and satisfy the obligations arising from its real behavior.

A person does not avoid responsibility by describing an operated service as “decentralized,” “non-custodial,” “protocol-only,” or “Z00Z-compatible.” Actual functions, authority, affiliations, data possession, and control prevail over labels.

11. Lawful use and regulatory boundary

Nothing in the Z00Z code, specifications, privacy features, or this notice authorizes unlawful conduct or removes an obligation that applies to a user or operator. Privacy must not be represented as permission for sanctions evasion, obstruction of lawful process, concealment of unlawful activity, or avoidance of controls applicable to an actual service operator.

Each user is responsible for obligations arising from the user’s conduct. Each operator is separately responsible for obligations arising from the functions and relationships that operator actually provides or controls. The protocol does not certify either person’s compliance.

These statements allocate no obligation contrary to mandatory law and do not add a prohibited-use condition to an open-source software licence.

12. Software licences and maturity

The licence identified by each source file, package, directory, or third-party notice controls. Different Z00Z packages and dependencies may use different licences. A distributor must preserve the notices required by each applicable licence.

Z00Z software, specifications, proof systems, wallets, transport designs, and protocol profiles may be experimental, incomplete, unaudited, or unsafe for a particular use. A test, proof, review, or audit applies only to its stated version, scope, assumptions, and date.

The warranty and liability provisions of the applicable software licence control for licensed software. Merely publishing, maintaining, or contributing to Z00Z does not undertake to recover keys, reconstruct history, reverse transactions, maintain a compatible network, preserve a market, redeem an asset, or keep any feature available.

13. Changes and documentary consistency

A release, publisher, distributor, or operator claiming conformity must identify the applicable versions of protocol profiles, wallet persistence, transport, retention, and governance processes. Users and operators should evaluate the exact release and deployment they use rather than relying on a roadmap or target whitepaper statement.

Material changes to this notice must be recorded in the public revision history. No Z00Z document may contradict the following boundaries:

• cryptographic validity is not legal validity;
• self-custody is not hosted custody;
• local wallet history is not a public per-user ledger;
• target Reticulum or OnionNet architecture is not a present-tense deployment guarantee;
• protocol compatibility is not endorsement of an asset or service; and
• responsibility follows actual functions and control.

Those boundaries apply whether a capability is current, experimental, planned, or supplied by an independent implementation. Release maturity must be stated separately and cannot be used to move a user’s duties to an operator, an operator’s duties to a user, or either person’s duties to protocol software.

Read Next

• Legal Architecture for the responsibility firewall these terms depend on.
• Compliance Framework for the wallet-role responsibility map, configurable policy profiles, prohibited use, and the actual-function test.
• Privacy Notice for website and service-layer data handling.
• Disclosures for risk categories that should be stated directly.

Evidence and Further Reading

• Legal Architecture sections 9, 12, and 16-18 support the wallet boundary, external integration red lines, legal threat model, public-claim discipline, and regulator-response posture.
• Main Whitepaper section 10 supports the protocol-versus-service split and the statement that wallets, bridges, issuers, and regulated services own their own higher-layer duties.
• Legal Architecture appendix A provides safe formulas and prohibited wording that terms pages should preserve.
• Legal Architecture appendix C supports documentary coherence across terms, wallet notices, governance policy, treasury policy, and public claims.