Z00Z is not end-to-end post-quantum secure today. That sentence is the anchor for this page. The safer claim is narrower: Z00Z has a comparatively migration-friendly settlement and storage boundary because public truth is organized around checkpointed roots, typed replay artifacts, canonical encodings, committed leaves, and wallet-local possession rather than around one reusable public account table.
That helps migration. It does not finish migration. Current transaction cryptography still includes elliptic-curve receiver, stealth, authorization, commitment, and range-proof assumptions. A serious migration has to treat those surfaces separately instead of pretending that one signature or KEM replacement solves the whole stack.
Current Boundary
The post-quantum problem has several layers.
| Component family | Current role | PQ posture | Migration response |
|---|---|---|---|
| Checkpoint roots and replay artifacts | Settlement continuity and public finality evidence | Comparatively stronger | Keep hash choices, domain labels, canonical encodings, and root binding explicit |
| Storage path commitments | State presence, absence, and root continuity | Comparatively stronger if conservative hashes remain | Version proof formats and preserve old history validity |
| Receiver and stealth key agreement | Payload confidentiality and wallet-local recovery | Weak under future ECC break | Add hybrid or PQ receive material for new outputs |
| Legacy signatures | Authorization and anti-forgery | Weak under future ECC break | Add migration-lane authorization and cutoff legacy-only movement |
| Pedersen commitments and range proofs | Confidential amount binding and validity | Hardest frontier | Treat as separate proof and commitment research track |
| Historical encrypted payloads | Already published confidentiality | Residual risk | Communicate honestly; protect new outputs and migrated rights |
The repository can expose PQ-aware checkpoint controls without making the whole transaction stack PQ-safe. Checkpoint policy hardening and suite metadata are useful, but they do not replace receiver confidentiality, signatures, confidential amount commitments, or range proofs.
Threat Model
The first threat is passive harvest-now-decrypt-later. An adversary can store public receiver artifacts, output points, encrypted payloads, proof bytes, and settlement evidence today. If practical quantum attacks later break the legacy elliptic-curve assumptions, historical payload confidentiality can age badly.
The second threat is active authorization failure. If legacy keys or legacy signatures remain valid forever, a future ECC break can become live value theft or unauthorized state movement, not just historical privacy loss.
The third threat is amount integrity failure. Replacing receiver encryption or signatures does not automatically replace confidential amount commitments and range proofs. If the amount-validity layer fails, conservation and confidential value correctness can fail even if authorization is stronger.
Migration Lane Diagram
Migration Principles
First, suite identity must be explicit. Receiver cards, payment requests, transaction packages, claim packages, output protection policies, checkpoint evidence, wallet exports, and recovery files should carry enough metadata for a verifier to know which assumptions protect the object.
Second, there must be no hidden downgrade path. Once a right has moved into a stronger suite, it should not quietly become a fresh legacy-only output again. Backward compatibility during migration is useful; permanent downgrade destroys the firewall.
Third, settlement history should remain verifiable. Old checkpoints should not be rewritten. Historical validity should remain anchored in the rules accepted at the time, while future movement uses new suite rules.
Fourth, privacy should not collapse into transparent accounts. Post-quantum pressure should not be solved by moving Z00Z toward public balances or permanent public holder graphs. If constrained lanes such as fixed denominations or asset-specific policies are needed, they should be explicit and local to those lanes.
Recommended Path
The first phase is a suite registry. It defines identifiers, supported primitive combinations, transcript labels, canonical encodings, rejection behavior for unknown suites, and deprecation semantics.
The second phase protects new receive and authorization flows. Current NIST standards make ML-KEM the standardized family to evaluate for KEM-based receive confidentiality, ML-DSA the standardized family to evaluate for high-volume digital signatures, and SLH-DSA the standardized hash-based signature family to evaluate for lower-frequency governance, recovery, or root-signing roles where size and cost are acceptable. These are building blocks for specific surfaces, not complete wallet, threshold, proof, or amount-validity solutions.
The third phase is one-way rewrap: consume a legacy output and create a stronger-suite output with explicit old-suite consumption, new-suite creation, replay protection, and wallet recovery material. The old output remains history. It should not remain live spendable value after rewrap.
The fourth phase is a legacy cutoff. After activation, legacy-only authorization is no longer sufficient for new valid settlement. The cutoff may be staged by asset family, value tier, output age, or wallet readiness, but the rule must be clear.
The fifth phase is the confidential amount frontier. Arbitrary confidential amounts are the hardest part of the migration. The project may need a new PQ-friendly commitment and proof stack, constrained high-assurance lanes, fixed-denomination options, or asset-specific policies before a universal answer is practical.
Integrity Firewall
The integrity firewall is the most urgent live-value concept. It prevents broken legacy authorization from moving future state after a cutoff. It does not retroactively encrypt old payloads, prove old commitments and range proofs are PQ-safe, repair every wallet backup, or make historical receiver artifacts private forever.
This fits Z00Z because value movement is already object-oriented and checkpoint-bound. A migration can consume one live right and create a stronger-suite right without rewriting a global account table. The same replay discipline that helps delayed settlement also helps suite generation and one-way rewrap.
Wallet, Recovery, And Operations
Migration is not only a verifier change. Wallets must understand suite generation, receiver material, recovery paths, warning states, and rewrap status. Recovery files must not silently restore a user into a deprecated lane. Remote scan, backup, corporate archive, and selective disclosure packages need enough suite metadata to explain what assumptions protected the object.
Operators need migration metrics: how many live outputs remain legacy-only, how many have been rewrapped, which suites are accepted, and which lanes are in warning, deprecated, cutoff, or retired state. Without those measurements, the migration becomes a slogan instead of a managed security program.
Communication Guidance
The safe present-tense formula is:
Z00Z has a PQ-friendly settlement and storage boundary, but its current transaction cryptography is not end-to-end post-quantum secure. The project should migrate through explicit suite versioning, hybrid or post-quantum new-output lanes, one-way rewrap, and a legacy cutoff, while treating confidential amount proofs as a dedicated research frontier.
Unsafe claims include “Z00Z is already post-quantum secure,” “a signature replacement solves migration,” “a KEM swap protects historical outputs,” “current Pedersen commitments and range proofs are PQ-safe,” or “one backend switch upgrades every property.”
Evidence Gates
Migration should advance only through evidence gates: suite ID test vectors, parser rejection behavior, receiver-material vectors, payload encryption and scan recovery tests, authorization vectors, rewrap tests, no-downgrade tests, cutoff activation rules, wallet UX warnings, amount-proof benchmarks, proof soundness review, and privacy review. Each gate should be documented before public claims widen.
Current Versus Target Status
The current status is migration posture, not completed migration. NIST has approved FIPS 203, FIPS 204, and FIPS 205, and the active NIST standardization page tracks additional work such as FALCON/FIPS 206 in development and HQC selection for standardization. Z00Z should reference those standards conservatively while still doing its own suite, wallet, proof, and settlement integration work. External standards are necessary inputs, not an automatic upgrade of the current codebase.
Read Next
- Privacy Threat Model explains how legacy cryptography affects privacy claims.
- Settlement Model explains the checkpoint and replay boundary that helps migration.
- Developers: Cryptography connects this posture to implementation-facing boundaries.
Evidence and Further Reading
- Post-Quantum Migration Whitepaper sections 2 through 14 define the authority map, current boundary, threat model, component risk matrix, migration principles, recommended path, integrity firewall, confidential amount frontier, operations guidance, communication guidance, and evidence gates.
- Privacy Threat Model And Metrics section 11 lists open privacy questions that remain relevant to migration and disclosure design.
- NIST CSRC, “Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography” (2024-08-13): https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved
- NIST CSRC, “Post-Quantum Cryptography Standardization Process” (updated 2026-06-16): https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization