The most important cryptographic statement in the current corpus is not a boast. It is a limit: Z00Z is not end-to-end post-quantum secure today. That sentence should remain visible because it protects the rest of the policy from drifting into wishful language.
The stronger defensible claim is more specific. The current design has a PQ-friendly settlement and storage boundary because public truth is already organized around checkpointed roots, typed replay artifacts, canonical encodings, and wallet-local possession rather than a reusable public account ledger. That helps migration. It does not finish it. Authorization, stealth reception, and confidential amount semantics still depend on narrower assumptions that must be named carefully.
Current Policy In Plain Language
Use this policy as the public rule set for crypto claims:
| Rule | Why it exists |
|---|---|
| Prefer exact surface names over slogans | “Stealth reception” and “wallet-local recovery” are clearer than “fully private cryptography” |
| Keep suite identity explicit | Reviewers should know which cryptographic lane a claim belongs to |
| Do not imply a hidden downgrade path | A stronger future lane should not quietly fall back to weaker authorization semantics |
| Separate confidentiality from value-validity | Protecting payload secrecy is not the same as proving confidential amount integrity |
| Do not claim universal PQ safety today | The corpus explicitly rejects that shortcut |
| Do not market optional overlays as if they were base-layer guarantees | Disclosure, audit, or enterprise views remain layered surfaces |
These rules are not only for protocol papers. They also apply to FAQ copy, support answers, wallet labels, roadmap summaries, and contributor docs.
What Can Be Said Safely Today
The present-tense lane can safely say that Z00Z uses a privacy-first object model in which wallet-local meaning and public settlement evidence are intentionally separated. It can safely say that the cryptographic boundary already includes concrete receiver, authorization, and proof surfaces rather than an undefined “encrypted balance” story. It can also safely say that future migration work should preserve the rights-first model instead of collapsing into transparent accounts.
What it should not say is equally important:
- not “fully post-quantum secure”;
- not “every future audit mode is already live”;
- not “all legacy risk disappears once one new signature family is added”;
- not “privacy survives endpoint compromise or reckless disclosure automatically”;
- not “transport privacy and settlement privacy are interchangeable.”
The Two Hard Frontiers
The corpus keeps returning to two hard cryptographic frontiers.
The first frontier is authorization migration. If legacy authorization remains valid forever, a future break can become a live theft problem instead of a historical confidentiality problem. That is why the post-quantum paper argues for an integrity firewall, one-way rewrap, explicit suite identity, and an eventual legacy cutoff.
The second frontier is confidential amount validity. A system can improve receiver confidentiality or signature resilience and still retain a harder open question around commitments and range-proof assumptions. This matters because “payload privacy” is not enough if value conservation can no longer be trusted. Any future widening of cryptographic claims must keep those two frontiers separate.
Rules For Contributors In This Repository
This repository is mostly a docs surface, so the most important crypto discipline here is wording discipline.
Contributors should:
- anchor cryptographic claims in
content/whitepapers/before expanding them into user-facing prose; - keep maturity notes visible when the design paper is ahead of repo-local implementation evidence;
- avoid turning future migration lanes into present-tense guarantees;
- use the repo verification path for docs changes so broken pages do not silently change the claim surface;
- prefer the conservative legal formulas from the corpus when a phrase sounds too strong.
The local instruction surfaces reinforce the same idea: precise claims beat dramatic claims.
What This Page Intentionally Leaves Open
This page does not choose a final end-state algorithm suite for every future lane, and it does not pretend that one naming decision closes the operational work. Wallet recovery ergonomics, downgrade resistance, disclosure compatibility, operator tooling, and confidential amount migration all need separate engineering and review. The point of the policy is not to fake closure. The point is to keep current public language from outrunning the evidence.
If a future page needs stronger wording, it should come with stronger proof.
Crypto Boundary Map
At the docs level, “approved” means claim-safe, not automatically production-certified. Use the cryptographic surfaces already described by the corpus and local instructions. Do not invent new primitives, new proof assumptions, new signature families, or new privacy guarantees in public copy. Do not treat test fixtures, mock proofs, examples, or local demos as production assurances. Do not ask users for secrets while debugging cryptographic behavior. The safest contribution is usually narrower wording, not more impressive wording.
External Standards Posture
NIST’s 2024 PQC FIPS announcement states that FIPS 203, FIPS 204, and FIPS 205 were approved for post-quantum cryptography. NIST’s PQC standardization page also records that those FIPS were published on August 13, 2024, and that HQC was selected for standardization on March 11, 2025. Those external facts support conservative migration language. They do not prove that Z00Z has completed its own migration. A docs page may cite NIST standards as the external standards context while still saying that local suite identity, transcript binding, one-way rewrap, compatibility, wallet UX, and confidential amount migration remain Z00Z-specific work.
Sensitive Data Handling
Cryptographic support requests should be designed around non-secret evidence. A reporter can share a public route, command output, package name, error class, or failing test. A reporter should not share private keys, seeds, raw wallet exports, decrypted backups, or full logs that include secret material. If a bug cannot be reproduced without secret data, first describe the secret class and the operation, then move to responsible disclosure.
Domain separation language should also be conservative. A page may say that domain separation is part of the intended safety posture where the corpus or implementation evidence supports it. It should not imply that a string label alone proves replay safety, downgrade resistance, or proof soundness. Cryptographic policy is a boundary for claims; it is not a substitute for implementation review.
Review Notes
A crypto-policy review should fail any wording that uses standards names as if they were local implementation evidence. It should also fail claims that combine separate properties into one slogan. Confidentiality, authorization, amount validity, transport privacy, wallet recovery, and post-quantum migration are different claims. They may depend on different primitives, tests, threat models, and rollout states.
The safest public posture is narrow and boring: name the current boundary, name the future migration lane, and name the non-claim. That wording is less dramatic, but it gives cryptographers and users something concrete to evaluate.
Final Boundary
If a crypto claim would make a careful reviewer ask “which suite, which transcript, which proof, and which implementation evidence,” the page should answer those questions before the evidence block. Otherwise, use weaker wording with explicit review caveats.
Read Next
Read Threat Model before reasoning about adversaries, Privacy Metrics before making measurement claims, and Wallet Recovery Safety before handling user secrets.
Evidence and Further Reading
- Post-Quantum Migration Whitepaper sections 3, 4, 7, 8, 9, 10, 11, 12, and 13 are the primary source anchors for the “not end-to-end PQ secure today” limit, explicit suite identity, one-way rewrap, legacy cutoff, operations, and the confidential amount frontier.
- Main Whitepaper sections 3, 5, 6, 9, 12, and Appendix B define the current wallet-local, stealth-reception, checkpoint-coupled settlement, and cryptographic-detail boundary that this policy describes in present tense.
- Privacy Threat Model And Metrics sections 6 and 7 and sections 3, 4, 8, 9, and 10 explain why public wording must distinguish payload confidentiality, public observability, operator exposure, wallet behavior, safe defaults, and disclosure scope.
- Legal Architecture Whitepaper sections 7, 9, 17, and Appendix A supply the safe and unsafe claim formulas that keep crypto language conservative across public materials.
.github/copilot-instructions.mdand.github/requirements/Z00Z_WEB_DESIGN_FOUNDATION.mdare the repo-local rule surfaces that require evidence-backed wording and explicit verification before publishing changes here.- NIST PQC FIPS announcement: https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved.
- NIST PQC standardization status: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization.