Cryptography in Z00Z is a boundary discipline. It is not only a library choice. The protocol’s privacy, replay safety, confidential amount handling, receiver flows, and migration posture depend on where secrets live, which transcript a proof binds to, which fields become public, and which assumptions are still legacy.
This website repository can host the docs, diagrams, and evidence links for that discipline. It cannot by itself prove every cryptographic implementation surface. Use local files for website claims and the whitepaper corpus for protocol cryptography claims.
What The Facade Protects
The crypto facade should protect four different properties at once:
| Property | Developer meaning |
|---|---|
| Confidential object state | Public settlement should not expose plaintext balances or wallet-local ownership meaning |
| Replay-safe authorization | A package or claim should not be reusable in the wrong domain, generation, or context |
| Verifier-minimal public evidence | Checkpoints should see the evidence required for settlement, not a full wallet history |
| Migration clarity | Legacy and post-quantum migration lanes must be versioned, not guessed |
If a design protects only one of those properties, it is not enough to describe the Z00Z cryptographic boundary. A range proof alone does not define wallet privacy. A signature alone does not define settlement validity. A KEM alone does not solve post-quantum migration.
Boundary Map
The facade is strongest when each arrow is explicit. A receiver artifact should not accidentally become a public account. A proof statement should not omit suite identity or domain context. A disclosure package should not export unrelated wallet history.
Domain Separation
Domain separation is the difference between “these bytes happened to hash” and “these bytes mean exactly this statement in exactly this protocol context.” Z00Z needs domain separation around receiver material, transaction digests, claim statements, nullifiers, checkpoint artifacts, disclosure packages, and migration suites.
For builders, the rule is straightforward:
| Surface | Domain question |
|---|---|
| Receiver material | Is this receive path scoped to the intended suite and request? |
| Package digest | Which package fields and version are bound? |
| Claim nullifier | Is replay protection claim-domain specific rather than universal folklore? |
| Checkpoint artifact | Which roots, deltas, and proof bytes are sealed? |
| Disclosure package | Which audience and purpose may read this evidence? |
| Migration lane | Which legacy, hybrid, or post-quantum suite verified the operation? |
Never describe a cryptographic helper as generic if its safety depends on domain context. The API may expose utilities, but the documentation should keep protocol meaning attached to the transcript.
Commitments, Proofs, And Sensitive Data
Z00Z uses commitments and proofs to keep public settlement narrow. A commitment can bind value without revealing it. A range proof can show amount validity without publishing the amount. An encrypted payload can carry wallet-recoverable material without turning public state into wallet history. Those properties matter only when sensitive data stays in the right place.
Sensitive wallet-side material includes receiver secrets, decrypted payloads, local labels, scan results, openings, backup material, and private decision history. These do not belong in public docs examples as casual sample data, production logs, or support exports. If an example needs a value, use clearly fake placeholders and do not imply that a wallet should reveal secrets for debugging.
At the same time, do not overstate what proofs solve. A commitment and proof layer can validate a bounded statement. It does not automatically verify an entire hidden business workflow, foreign reserve honesty, or every off-chain condition a service claims occurred. Those wider truths require bounded attestations, registry evidence, disclosure packages, or future proof systems.
Disclosure Keys And Audit Boundaries
Privacy in the corpus includes optional disclosure, not universal opacity. A wallet or enterprise flow may need to produce a bounded evidence package for a counterparty, operator, auditor, or regulated process. The crypto facade should make that scope visible.
Good disclosure design answers:
- Who is the intended reviewer?
- Which object, request, policy, or transaction is in scope?
- Which evidence is public settlement evidence versus wallet-local material?
- Which secrets remain redacted?
- Which liability or audit path authorized the reveal?
The unsafe shortcut is “export everything.” That can create a richer ownership ledger than the public protocol. Another unsafe shortcut is “disclosure impossible.” The legal and privacy corpus both support a narrower story: disclosure is optional, scoped, and purpose-bound when a workflow legitimately needs it.
Test-Only And Local Boundaries
Developer examples should label test-only material clearly. A fixture, mock key, sample request, or fake package is not a recommended production pattern. Test-only boundaries are especially important in cryptography docs because readers may copy examples into real integrations.
Use this rule:
| Example type | Required label |
|---|---|
| Fake key or seed | Test fixture only; not wallet backup guidance |
| Mock package | Shape example only; not settlement evidence |
| Placeholder proof | Documentation placeholder; not a verifier output |
| Local command | Must exist in package.json or scripts |
| Future migration suite | Target architecture unless implementation evidence exists |
This repository’s npm run verify proves the website builds. It does not prove cryptographic soundness. Cryptographic implementation work needs dedicated tests, vectors, reviews, and proof-specific evidence in the implementation repository that owns that surface.
Post-Quantum Posture
The post-quantum claim must stay precise. Z00Z has a PQ-friendly settlement and storage boundary because roots, replay artifacts, canonical encodings, and checkpoint evidence can be versioned and firewalled. Z00Z is not end-to-end post-quantum secure today. Current receiver, authorization, commitment, and range-proof assumptions include legacy elliptic-curve risk that a future migration must address.
The migration paper splits the problem into tracks:
| Track | Migration posture |
|---|---|
| Settlement and storage | Comparatively friendly because root and replay evidence can be versioned |
| Receiver and payload confidentiality | Needs hybrid or post-quantum receive material for new outputs |
| Authorization | Needs suite-bound signatures or authorization proofs and cutoff rules |
| Confidential amount validity | Hard frontier; not solved by replacing signatures or KEM alone |
| Historical ciphertexts | Residual harvest-now-decrypt-later risk where legacy assumptions were used |
The safest developer wording is: explicit suite identity, no hidden downgrade path, one-way rewrap, staged legacy cutoff, and separate research for confidential amount proofs. Do not say “already PQ secure,” “signature swap solves it,” or “one backend switch upgrades everything.”
Implementation Review Questions
When reviewing cryptography-facing docs or code plans, ask:
- Does every public proof or signature claim state its domain and transcript boundary?
- Does the page distinguish wallet-local secrets from public settlement evidence?
- Does the claim say what a proof validates and what it does not validate?
- Does any sample material look like a real key, seed, or production backup?
- Does the post-quantum sentence preserve the non-claim that current transaction cryptography is not end-to-end PQ secure?
- Does disclosure stay scoped rather than turning into full wallet export?
These questions are more useful than listing every primitive. They catch category errors before a reader builds the wrong integration.
Read Next
Read Core Protocol API for the object and checkpoint API map, Wallet SDK for wallet-local possession, and Post-Quantum Migration for the migration lane.
Evidence and Further Reading
- Privacy Threat Model And Metrics sections 3 through 10 define the privacy dimensions, adversary classes, layered threat model, metrics, anti-patterns, wallet requirements, disclosure model, and telemetry boundaries.
- Post-Quantum Migration Whitepaper sections 4 through 13 define the current cryptographic boundary, threat model, suite identity, migration path, integrity firewall, amount frontier, wallet operations, communication guidance, and evidence gates.
- Main Whitepaper appendix B defines the cryptographic facade, commitments, range proofs, signatures, domain separation, KDF lanes, replay-boundary derivations, canonical encoding, and the boundary of the appendix.
src/lib/content/markdown.tsandscripts/verify.share local website anchors only; they verify docs rendering and build workflow, not cryptographic soundness.