Proposal: A Post-Quantum Readiness Track for Zano and Zenith

[Yep]

Proposal: A Post-Quantum Readiness Track for Zano and Zenith

Purpose of this proposal

This post expands on the suggestion that post-quantum readiness should become a core Zano roadmap priority.

It is a planning proposal, not a claim that Ed25519 will necessarily be broken in 2029 or on any other specific date. It also does not attempt to select a final post-quantum signature, commitment scheme, anonymous authorization system or private Proof-of-Stake construction.

The immediate question is narrower:

What should Zano begin building now so that users have somewhere safe to migrate their value before elliptic-curve security becomes practically insufficient?

A complete post-quantum reconstruction of Zano's privacy architecture will be a long research programme. The first deliverable should therefore be quantum-safe custody and a workable migration path, while the complete private post-quantum domain is developed in later stages.

1. Why this is now a roadmap issue

The planning environment has changed materially.

Microsoft states that, following Majorana 2, it expects to achieve a scalable quantum computer by 2029 and describes that target as commercially valuable. This does not establish that the resulting machine will be able to break Ed25519. It does, however, provide a reasonable conservative boundary for engineering preparation.

The United States has also issued Executive Order 14412, directing an accelerated federal migration to NIST-approved post-quantum cryptography. It requires a NIST migration pilot to be completed by the end of 2027, post-quantum key establishment for high-value and high-impact federal systems by the end of 2030, and post-quantum digital signatures for those systems by the end of 2031.

The lesson is not that a cryptographic break has been scheduled. The lesson is that migration has already become a current engineering programme for major public and private actors.

For Zano, deployment lead time matters more than prediction. A safe transition requires:

• a complete cryptographic inventory and threat model;
• protocol and wallet design;
• prototype implementation and performance measurement;
• independent cryptographic and implementation review;
• testnet operation;
• new backup and recovery procedures;
• support from exchanges, custodians and hardware-wallet providers;
• user education;
• and enough time for economically significant value to be migrated.

A privacy-preserving blockchain cannot safely improvise new ownership, anonymity, commitment and consensus proofs after the threat has already become practical.

2. The immediate Zano-specific custody problem

Zano's permanent wallet address is not written directly into every output. This is valuable for privacy, but address privacy and quantum-safe custody are different properties.

Each private or legacy UTXO publishes a one-time output public key of the form:

P = xG

where x is the corresponding one-time private spending key.

Under current assumptions, recovering x from P is computationally infeasible. If elliptic-curve discrete logarithms became tractable, however, an adversary could derive:

x = log_G(P)

The attacker would not need the user's permanent spend key, private view key, published wallet address, prior staking activity or an already revealed key image. The output public key is already present in the ledger.

This means that an unspent output may remain unlinkable to a known permanent address while nevertheless losing its custody security.

The wider post-quantum problem is larger than this single relation. Zano's private domain also relies on elliptic-curve assumptions for ring authorization, key images, Schnorr-type proofs, Pedersen commitments, confidential assets and private staking proofs. Those mechanisms will eventually require coordinated replacement.

Nevertheless, custody should be addressed first because it provides an achievable early objective: prevent an attacker who has recovered all elliptic-curve spending secrets from spending value that users have already migrated to a protected destination.

3. What Zenith changes — and what it does not

Zenith is a major consensus redesign. Its epochs, slots, snapshots, randomness, probabilistic leader election, fork choice and faster confirmation model may provide substantial operational and security improvements.

Those improvements do not, by themselves, make existing outputs post-quantum.

Shorter block intervals and faster confirmations do not protect a public output key that has been exposed since the output was created. Zenith's slot-dependent ephemeral key images improve the classical privacy and freshness properties of staking, but they remain part of an elliptic-curve construction. The specified eligibility proof also composes one-time output control, anonymous membership, commitments, d/v-CLSAG, Schnorr proofs and range relations.

A conventional post-quantum block signature would therefore be insufficient. It could authenticate a public validator, but it would not reproduce Zenith's private eligibility proof.

This does not make Zenith the wrong priority. It makes Zenith the best architectural opportunity to prepare the transition.

The high-level consensus semantics can be distinguished from their current cryptographic realization:

Consensus semantics:
    epochs, slots, snapshots, randomness,
    eligibility conditions, fork choice and confirmation

Cryptographic realization:
    output control, anonymous membership,
    nullification, confidential stake and threshold proof

HF7 should make that boundary as explicit as practical, even though a complete post-quantum private eligibility construction will come later.

4. Central recommendation: custody and migration first

The first post-quantum deliverable should not be a complete post-quantum version of Zenith, Zarcanum and Confidential Assets.

It should be:

A quantum-safe custody destination to which existing value can be migrated before elliptic-curve spending keys become practically recoverable.

The complete transition can then proceed in dependency order:

1. programme foundation and cryptographic inventory;
2. quantum-safe custody and migration;
3. post-quantum unlinkable reception;
4. post-quantum anonymous authorization and double-spend prevention;
5. post-quantum commitments, confidential values and assets;
6. private post-quantum eligibility for Zenith;
7. progressive restriction and retirement of classical-only outputs.

This sequencing protects value early without pretending that an ordinary post-quantum signature recreates Zano's full privacy architecture.

5. Minimum viable hybrid custody output

A realistic early measure would be a new, explicitly versioned hybrid output.

The output would preserve the current classical objects needed for compatibility, while adding an independent post-quantum public credential. Spending would require both authorizations:

classical authorization
        AND
post-quantum authorization

A simple logical OR would not be sufficient. If either branch independently authorized the spend, breaking the classical branch would still permit theft.

The essential acceptance test should be deliberately severe:

Assume that the attacker knows every elliptic-curve secret associated with the output. The output must still be unspendable without the independent post-quantum private credential.

Existing outputs cannot receive this protection retroactively because they contain no post-quantum credential selected by their owner. Users would need an explicit migration transaction:

existing classical output
        ->
owner-authorized migration
        ->
hybrid protected output

The wallet would need to generate and back up the new keys, identify unmigrated value, construct migration transactions, verify that the protected output has been confirmed, and support recovery from the new backup format.

The first hybrid output should be treated as a transitional custody vault, not as the final post-quantum private payment domain. To reduce schedule risk, it may initially:

• offer less spending anonymity than ordinary ZC outputs;
• be excluded from staking;
• use larger transactions;
• omit post-quantum confidential-asset functionality;
• and coexist with the current private domain rather than replace it.

Those limitations must be explicit and voluntary. Preserving value should not be delayed until every current privacy property can be reproduced simultaneously.

The precise construction, primitive selection and recovery policy require formal specification and independent review. A hybrid mechanism must also consider the possibility that an early post-quantum implementation is later found defective, so credential rotation and upgrade paths should be designed from the start.

6. Changes worth incorporating into HF7

Before HF7 formats and interfaces become difficult to change, Zenith development should be used to introduce the foundations of cryptographic evolution.

6.1 Explicit cryptographic-domain versioning

Inputs, outputs, authorization proofs, nullifiers or key images, addresses and staking proofs should identify the cryptographic domain and version under which they are interpreted.

Versioning should not be limited to a signature identifier. A future private domain may require different object types, scanning procedures, state-consumption identifiers, commitments and resource limits.

6.2 A new hybrid output type

HF7 should leave room for a protected output that can coexist with current payment and staking outputs, even if the first version is not eligible for staking.

6.3 Native migration paths

Migration should be a defined protocol and wallet operation, not a manual emergency procedure. Fees, change outputs, privacy consequences and domain conversion rules should be explicit.

6.4 Separation of consensus semantics from eligibility proofs

The implementation boundary should minimise assumptions by the epoch, slot, snapshot and fork-choice logic about the internal form of a particular elliptic-curve proof.

This will not make cryptography interchangeable automatically, but it can reduce the cost of integrating a future eligibility domain.

6.5 Capability negotiation

Wallets, exchanges and custodians should be able to determine which address, output and authorization versions are supported before creating a transaction.

6.6 Emergency and retirement states

The protocol should define in advance how it could:

• warn against new classical-only outputs;
• restrict their creation;
• suspend deposits to vulnerable formats;
• require protected destinations;
• and eventually retire classical-only authorization.

Emergency rules designed during an incident are more likely to create consensus or custody failures.

6.7 Resource accounting by domain

Post-quantum signatures and proofs may have very different bandwidth, verification, memory and storage costs. Fee and block-resource policies should be able to account for those differences explicitly.

7. Proposed roadmap reprioritisation

The public roadmap currently places the Zenith testnet and the Zano Execution Layer mainnet in Q4 2026, with Zenith mainnet planned for Q2 2027. It also includes a new mobile wallet, a networking privacy upgrade, DEX integration research, alias markets, multisignature work, hardware-wallet support and other ecosystem projects.

A genuine post-quantum programme does not require every other project to stop. It does require a clear rule:

Base-layer custody and migration work should take precedence whenever projects compete for the same core developers, wallet engineers, cryptographic reviewers, testing capacity or hard-fork coordination.

Priority A — Begin immediately

• cryptographic inventory and threat model;
• hybrid custody-output specification and prototype;
• wallet migration, backup and recovery;
• HF7 cryptographic-domain versioning;
• consensus/eligibility separation;
• independent cryptographic review;
• early exchange, custodian and hardware-wallet coordination.

Priority B — Reorient or reuse current and planned work

• New mobile wallet: make migration, dual-key backup and domain support primary architectural requirements.
• Hardware-wallet support: design for both current and post-quantum credentials rather than completing a classical-only integration.
• Multisignature: redirect part of the work towards hybrid and threshold custody.
• Dynamic fees: expand the design into domain-specific resource accounting.
• Full-chain membership research: reuse the completed research, indexing and anonymity-set work, but evaluate post-quantum membership and one-of-many proof directions before committing further production work to the current algebraic domain.
• Grants: use part of the programme for targeted post-quantum research, benchmarking and external review.

Priority C — Candidates for deferral

The clearest candidate is the Zano Execution Layer.

An EVM-compatible sidechain may eventually create substantial ecosystem utility. It does not protect existing Zano outputs, provide a migration destination or make the Zano base layer cryptographically agile. Its testnet, bridge, mainnet integration, contract environment, operational support and auditing can consume significant engineering and coordination capacity.

Where those resources overlap, the Execution Layer should be deferred in favour of post-quantum custody.

Other candidates include:

• alias markets and premium alias auctions;
• additional DEX integration research;
• non-essential bridge expansion;
• and other ecosystem functions that do not contribute directly to custody, migration or HF7 transition architecture.

Projects built and reviewed by genuinely independent teams need not stop. The objective is not to centralise all development around one task, but to prevent expansion work from displacing base-layer security.

8. A compact staged programme

The following schedule is illustrative rather than a fixed commitment.

Stage 1 — Architecture and prototype: approximately 0–3 months

• complete the cryptographic inventory and threat model;
• define the hybrid-output security properties;
• evaluate candidate signature families and key sizes;
• prototype node verification and serialization;
• benchmark transaction size and verification cost;
• define wallet backup and recovery requirements.

Stage 2 — Wallet and testnet migration: approximately 3–6 months

• implement output and input versions;
• implement wallet key generation and recovery;
• add migration transactions;
• test failure cases and chain reorganisation handling;
• perform the total-elliptic-compromise acceptance test;
• deploy an internal and then public testnet.

Stage 3 — Independent review and mainnet readiness: approximately 6–9 months

• external cryptographic and implementation review;
• hard-fork and compatibility testing;
• exchange and custodian integration;
• hardware-wallet planning;
• activation, emergency and rollback procedures;
• mainnet release candidate.

Stage 4 — Native post-quantum privacy: multi-year research and engineering

• unlinkable reception;
• anonymous authorization;
• post-quantum nullifiers;
• confidential commitments and range proofs;
• confidential assets;
• and private Zenith eligibility on the new foundation.

9. Non-goals and limits

This proposal does not claim that:

• Ed25519 will be broken in 2029;
• Microsoft has published the resources required for a practical Shor attack against Zano;
• every historical amount or asset type will necessarily become uniquely readable;
• replacing one signature makes Zano post-quantum;
• Zano is uniquely vulnerable among elliptic-curve blockchains;
• Zenith should be abandoned;
• or privacy should be permanently sacrificed.

It also does not select a final primitive family. The first public decision should concern architecture, threat model, acceptance criteria and migration order. Primitive selection should follow reproducible benchmarking, security analysis and external review.

10. Questions for the Zano team

1. Is a post-quantum cryptographic inventory or transition architecture already being developed internally?
2. Are the HF7 input, output and proof formats still open to explicit cryptographic-domain versioning?
3. Could a hybrid custody output be introduced alongside Zenith while remaining initially ineligible for staking?
4. Can the epoch, slot, snapshot and fork-choice implementation be separated more clearly from the concrete eligibility-proof verifier?
5. Which roadmap projects actually compete for the same core developers, wallet engineers, auditors and release capacity?
6. Would the team consider publishing a formal post-quantum threat model and migration requirements before selecting final primitives?
7. Would external cryptographic researchers be welcomed for targeted review and prototype evaluation?

Conclusion

Zano has already demonstrated that it can introduce deep protocol changes while preserving chain continuity and protocol identity. HF4 and HF6 provide different precedents for the coexistence of new and historical domains.

The next step should be to turn that evolutionary capacity into deliberate cryptographic agility.

Zenith is not the obstacle. It is the opportunity to establish versioned domains, migration paths and a cleaner boundary between consensus semantics and cryptographic eligibility.

The most urgent objective is not to complete every post-quantum privacy primitive at once. It is to ensure that users can move existing value into an output that remains secure even after complete compromise of the present elliptic-curve spending secrets.

More detailed vulnerability and architectural analyses are being prepared separately. This post is intended to define the roadmap decision that should come first.

References

• Microsoft — Introducing Majorana 2
• The White House — Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks
• Zano Roadmap
• Zano and Common Prefix — Zenith: Privacy-Preserving PoS Protocol, June 2026
• Zano — Confidential Assets Scheme for RingCT and Zarcanum, version 1.1
• CryptoNote — CryptoNote v2.0