Love seeing this. Another step towards making private payments practical and accessible. The merchant adoption possibilities here are huge. Excited to see this go live!

Reposted in full: the previous submission was inadvertently truncated when pasted into the forum. This version contains the complete article. A Security Framework for Gateway v2 and Future Post-Quantum Migration Version 1.2 — forum edition, 12 October 2026. Abstract The HF6 Gateway Address incident motivates a broader architectural security question: how should one protocol preserve shared properties across domains with different state representations and validation semantics? The official emergency release documented an attack affecting native-coin and asset supply, a rollback, and temporary disabling of Gateway Addresses. This article uses that documented outcome as its starting point; it proposes a security framework rather than reconstructing the exploit or certifying a redesigned implementation. A transaction may contain objects that are locally valid under the rules of each participating domain while still representing an invalid transformation between those domains. This article proposes Cross-Domain Invariant Enforcement as an architectural security principle for Zano: A cross-domain transition must establish the semantic correctness of the transition itself, not merely the local validity of its endpoints. The principle is intended as a reusable engineering framework rather than as a post-mortem of HF6. Its immediate application is the redesign and audit of Gateway Addresses. Its longer-term application may become even more important if Zano's post-quantum migration requires coexistence between classical, transitional and native post-quantum domains. The framework introduces three practical ideas: explicit cross-domain transition proof obligations, a permanent Protocol Invariant Registry, and a Boundary Completeness Rule requiring every new or modified domain to be reviewed together with all boundaries it creates or changes. 1. The architectural lesson from HF6 HF6 introduced Gateway Addresses as a specialized state model alongside Zano's principal confidential transaction domain. The documented Gateway design uses account-style balances and exposes the amounts involved in Gateway transfers, while the principal private path uses confidential UTXO representations. Both belong to one base-layer ledger and asset environment, with different state and validation semantics. The Gateway documentation describes a design and API; its presence does not establish that the functionality is currently enabled. Gateway documentation On 27 September 2026, emergency release v2.2.3.600 documented an attack affecting native-coin and asset supply. It rolled the chain back to height 3,833,000, corresponding to 26 August 2026 at 15:50 UTC, and temporarily disabled Gateway Addresses under emergency HF7. Release v2.2.3.603, published on 5 October, explicitly carried that rollback forward. Emergency release, subsequent release The release announcement establishes the economic impact and emergency response. It does not, by itself, establish the exact algebraic exploit path. The architectural argument below therefore does not depend on a specific reconstruction of the missing check or on a claim that every local verifier was independently correct. The architectural question is broader than the presence or absence of one implementation check: What must validation establish so that a protocol-wide economic property remains true when value crosses between different representations of state? This gives the central observation: Valid_A ∧ Valid_B ⇏ Valid_(A→B) Local correctness of Domain A and local correctness of Domain B do not, by themselves, establish correctness of the transformation connecting them. The boundary is therefore a security surface in its own right. 2. Protocol domains and domain boundaries For the purposes of this framework, a protocol domain is a portion of the ledger architecture characterized by a sufficiently distinct combination of state representation, transaction objects, authorization semantics, state-transition rules, validation procedures, privacy properties or cryptographic assumptions. Domains do not need to be separate blockchains. A ledger or state domain defines how state is represented, updated and validated. A cryptographic domain is a coherent family of objects, proof relations and assumptions implementing a declared property set. These dimensions can overlap without being interchangeable: a new authorization mechanism need not create a new ledger model. This distinction is particularly relevant to Zano because its domains can share: chain + consensus + asset environment while differing in: state representation + authorization + validation semantics + privacy A domain boundary exists wherever protocol logic must relate those different semantic systems. A cross-domain transition is therefore any consensus-relevant operation whose validity depends on objects or state belonging to more than one protocol domain, or which transforms value, ownership, authority or state from one domain representation into another. For example: Gateway balance → confidential ZC outputs is one economic transformation expressed through two different state models, when that operation is permitted. Its specification must identify the complete source and destination state and the relation between them. 3. Cross-domain invariants A cross-domain invariant is a protocol property that must remain true over the combined state affected by a transition, independently of how each participating domain internally represents that property. If I is such an invariant and T is an allowed transition, I(S) ∧ Valid_T(S, S′) ⇒ I(S′) Here, S and S′ denote the complete state relevant to the transition before and after acceptance. The statement is conditional on the declared rules and security assumptions. The clearest example is monetary conservation. The architectural responsibility is shared even where its realization differs: commitments and proofs in the private path, explicit amounts and directly tracked balances in account-style state. For each asset a, a generic conservation relation can be expressed as: V_consumed(a) + I_authorized(a) = V_created(a) + B_authorized(a) + F(a) The accounting categories must be disjoint: created value excludes anything assigned to the fee term, and authorized burning excludes fee-related burning already counted there. Authorized issuance includes protocol emission where applicable. The equation does not assume that fees are transferred rather than burned, or require confidential quantities to become public. Numerical conservation is insufficient without canonical asset correspondence and authorization of the complete transition. Consumption must not leave conflicting independently spendable representations of the same source value. A valid operation may split value among several destinations or combine several sources; uniqueness applies to consumption, not to the number of outputs. The invariant belongs to the protocol, not to either individual domain. 4. The cross-domain transition proof obligation The word proof must be used carefully. In the definition below, protocol invariants are the consensus-critical conditions applicable to the operation and its declared context. Broader properties, including privacy and operational recoverability, require additional evidence, as discussed in Section 8. A cross-domain transition does not necessarily require one zero-knowledge proof or even one cryptographic proof object. This article therefore uses the following definition: A cross-domain transition proof obligation is the complete set of consensus-enforced conditions required to establish that a particular transition preserves every protocol invariant spanning the participating domains. A proof obligation may be discharged through deterministic validation, cryptographic proofs, authorization checks, state lookups, type restrictions, sequencing rules, domain separation and other consensus logic. The architectural question comes first: What must consensus establish for this transformation to be valid? Only afterwards should designers decide which cryptographic or deterministic mechanisms establish those facts. This distinction prevents a dangerous reduction of the problem to questions such as: Is the balance proof valid? or: Is the signature valid? Those may both be true while the complete transition remains false. 5. Semantic completeness This is perhaps the most important requirement. A cryptographic proof may be perfectly sound while the protocol is economically unsound if the statement being proved fails to describe the complete economic transformation. Therefore: A sound proof of an incomplete statement does not produce a sound protocol. Every economically meaningful degree of freedom available to a transaction constructor must either be fixed by protocol rules, explicitly authorized, or included in the relation validated by consensus. This includes values that are mathematically well formed but semantically invalid. Consider an asset representation encoded as an elliptic-curve point. Algebraic acceptability alone would not establish that it represents an asset the protocol is entitled to interpret in that context. This is a general review example, not a reconstruction of the HF6 exploit. This gives a useful review rule: Validation must establish protocol meaning, not merely mathematical well-formedness. That principle applies well beyond elliptic-curve points. It applies to serialized objects, identifiers, commitment generators, nullifiers, domain tags, transaction versions and future post-quantum objects. 6. Privacy changes the assurance model The incident also motivates examining how confidentiality changes the assurance available at a domain boundary. In a transparent system, independent observers may sometimes reconstruct an economic inconsistency after the fact. A bridge, for example, may allow comparison between assets locked on one chain and assets issued on another. Such auditing should never replace consensus validation, but it can provide an additional detection layer. A confidential destination is different. Where a destination conceals values and ownership relations, public observers may lack the information needed to reconstruct the full economic history of its outputs. Whether a particular incident remains traceable requires a separate analysis of the available evidence. The architectural requirement should not depend on an assumption that later tracing will recover that information. The architectural requirement is that monetary correctness must not depend on later reconstruction that the privacy model does not make available. Hence: Consensus-critical transition invariants must be enforced before acceptance; external audit cannot substitute for that validation. And more specifically: Transparent and confidential destinations require complete transition validation. Confidentiality makes reliance on later economic reconstruction particularly unsuitable. External monitoring remains useful as defence in depth for whatever quantities and events are observable. It should respect the declared privacy model and avoid unnecessary identifying metadata. It can detect evidence of a failed assumption or implementation defect; it cannot replace the relation that makes a transition valid. 7. Security controls for a domain boundary A practical review should cover at least the following twelve control classes. This is an audit framework, not a claim that the list alone establishes security: Domain and type identification. Every object must have one unambiguous protocol interpretation under a specific domain and version. Complete semantic coverage. Every field capable of affecting value, assets, authorization, issuance, burning or state construction must participate in the validated relation. Value conservation. Conservation must hold across the complete transition, not separately on each side. Asset integrity. Source and destination representations must correspond through one canonical protocol relation. Unknown or unsupported asset representations should fail closed. Authorization binding. Authorization must cover the specific source state, destination state and operation being performed, rather than merely authorize activity inside one domain. State-consumption integrity. Conflicting consumption of the same source must be rejected in accepted canonical state, including conflicts between ordinary spending and migration. Multiple destinations are valid if the complete operation conserves value and is authorized. Atomic state application. A same-chain value-migration transition must consume its source and create its destinations atomically. A staged design must explicitly account for intermediate value and authority. Reorganizations must revert the related changes consistently; a restored source may subsequently be consumed again under the canonical rules. Domain and version binding. Parsing, state lookup, dispatch, proofs and authorization must agree on domain, operation and version. Review must include activation boundaries and reorganizations across rule contexts; cryptographic domain separation alone is insufficient. Replay and downgrade resistance. Reject replay against already consumed state and unintended reinterpretation under a different context. Retired permissions must not remain accidentally reachable. Review complete routes, including recovery and intermediate domains, for ways to restore weaker authority prohibited by policy. Confidential-destination assurance. Discharge the complete economic relation before acceptance. Assess migration metadata and distinguish future confidentiality from concealment of previously exposed history. Operational observability. Independent monitoring should track whatever public invariants, transition counts, issuance/burn activity and exceptional conditions remain observable. Adversarial testing and resource accounting. Test semantically hostile yet structurally valid objects, arithmetic boundaries, alternate encodings, unsupported assets, missing or extra outputs, conflicts and prohibited routes. Assess whole-operation and aggregate-block costs, including expensive rejected inputs; distinguish deterministic consensus limits from local admission policy. The relevant adversarial question is: Can an attacker choose a combination for which every individual check succeeds while the overall economic statement is false? That question directly targets compositional failures. 8. Protocol Invariant Registry To make these principles operational, Zano could maintain a Protocol Invariant Registry alongside its architectural specifications. This need not be a consensus object or a new source of protocol authority. It would be a specification and review record connecting each property to its scope, assumptions, permitted exceptions, enforcement points and supporting evidence. Changes to declared properties require an explicit architectural decision. For example: Invariant / property Scope Enforcement / evidence Monetary conservation Global / all value domains Consensus Asset conservation and identity Per asset / relevant domains Consensus Authorized issuance and burning Asset-operation paths Consensus Single state consumption Domain and cross-domain Consensus Gateway private-state consistency Gateway boundary Consensus Migration uniqueness Permitted migration routes Consensus No unauthorized downgrade Transitional/PQ domains Consensus Declared privacy properties Specified domains and transitions Cryptographic analysis + metadata assessment Recoverability Supported credentials, wallets and domains Recovery policy + operational evidence Validation resource limits Complete operations and blocks Deterministic consensus limits; separate local policy Each entry should identify applicable versions and the checks or evidence supporting it. Privacy depends on assumptions and observable metadata; recoverability also depends on credentials, backups and wallet support. Listing a property does not make it enforceable by one consensus predicate. Every proposal introducing or modifying a transaction type, domain, migration path or lifecycle permission should identify the entries it affects and the evidence that must be updated. This transforms an implicit expectation— the new feature must not break monetary integrity —into an explicit review obligation. 9. The Boundary Completeness Rule A second practical principle follows directly: A domain specification is incomplete until every new or modified boundary created by that domain has also been specified. Introducing a domain therefore requires defining not only its local objects and validation rules, but also its permitted transitions to existing domains. Likewise, modifying an existing domain requires re-evaluating every boundary whose correctness depends on the changed semantics. This is particularly important during hard forks. Versioning Domain A without reconsidering A → B may leave an old assumption embedded inside a transition whose endpoint semantics have changed. A coherent cryptographic domain remains the principal unit of replacement. Its security-review scope includes every affected boundary, permitted direction, version and lifecycle restriction. Sequences through intermediate domains must also be reviewed: acceptable individual steps can compose into a prohibited downgrade or duplicate economic representation. The unit of security review must therefore be: domain + all affected boundaries 10. Application to Gateway v2 A redesigned Gateway would provide an immediate opportunity to apply the framework. Here, Gateway v2 names that prospective redesign; it does not imply a finalized specification, completed audit or deployed capability. In a public forum statement, the Zano team said Gateway Addresses would stay disabled pending reassessment and audit, with third-party review among the stated goals. The same statement moved Zenith to HF8 because HF7 had been used for network recovery, gave no ETA, and declined to commit to a delivery order for Gateway v2, Zenith and ZEL. These are announced intentions, not evidence that the reviews or activations have occurred. Team statement A Gateway v2 security specification should therefore describe not only Gateway-local rules but every permitted transformation between Gateway state and the private domain. For each operation, the specification should identify the source and complete destination set; canonical asset correspondence and amount relations; authorization and fee/issuance/burn rules; consumption and atomicity; versions, activation and failure behavior; and the exact consensus checks discharging the obligation. Wallet construction, backup and recovery, storage, conflict detection and resource limits must support those semantics. A particularly useful audit test would be: Assume the adversary controls every field that protocol rules permit the transaction constructor to choose. Can any assignment satisfy all validators while violating the intended economic transition? This is stronger than ordinary signature testing, balance-proof testing or happy-path transaction testing. It asks whether the composition itself is secure. 11. Application to post-quantum migration The same framework may become even more important in a post-quantum transition. Zano's private architecture tightly integrates reception, ownership, anonymous authorization, state-consumption integrity, confidential amounts, assets and private staking. Replacing a conventional signature alone is therefore insufficient; different ledger or cryptographic domains may require different transition paths. A possible directed migration topology is: D_existing → D_transitional → D_successor Each permitted edge has its own proof obligation. The illustration implies neither reverse routes nor a mandatory intermediate stage; a direct existing-to-successor route may also be specified. Hybrid authorization is a cryptographic policy, not necessarily a separate ledger domain. Migration must prevent conflicting accepted consumption while preserving asset and value relations across the complete destination set. Ordinary spending and migration need compatible conflict detection. Return routes, recovery and withdrawal of obsolete authority require explicit policies; retaining historical parsing does not imply permission for new spending under retired rules. Preventive migration also depends on trustworthy source authorization and economic state. If the relevant source assumptions have already failed, stronger destination authorization cannot retroactively establish legitimate ownership, quantity or asset identity. Emergency treatment requires a separately justified recovery basis; the framework promises no unconditional recovery path. PQ spending authorization alone does not establish PQ protection of reception, confidential value, asset integrity, state consumption or consensus. Each stage must state its protected properties, remaining assumptions and permitted operations. Privacy changes must be deliberate: entering confidential state does not erase public history, migration linkage or metadata already exposed. These properties should be specified before selecting the final post-quantum mechanisms. That is one of the broader advantages of an invariant-oriented architecture: it separates what the protocol must preserve from how a particular generation of cryptography implements it. 12. Formal specification and testing Cross-domain boundaries are attractive targets for formal methods because their central properties are relational. A useful initial model could focus on Gateway state, private-state abstractions, the asset registry, consumption and permitted transition types. It could test or prove selected invariants under explicit assumptions. A model proof does not automatically verify the implementation, the cryptographic relations it abstracts or wallet behavior; those require separate evidence. Formal verification of related cross-domain economic properties already exists. Marić, Scholz and Subotić formally verified a fail-safe cross-chain bridge by defining and proving invariants governing the equilibrium between the connected systems. drops.dagstuhl.de OmniLedger similarly required a dedicated atomic cross-shard protocol rather than assuming local shard validity was sufficient for cross-shard transactions. UCL Discovery Kim's 2026 preprint studies mechanized preservation of regulatory state across domains under an explicitly scoped model. It offers a further methodological analogy, not a security result for Zano or for confidential monetary transitions. Preprint, version 4 The proposed Zano principle is therefore not a claim that invariant preservation across domains is a newly discovered idea. Its more specific contribution is to apply that reasoning to heterogeneous state domains within one privacy-oriented base-layer ledger, where limited observability makes dependence on later economic reconstruction particularly unsuitable. 13. Cross-Domain Invariant Enforcement The principle can now be stated compactly: Cross-Domain Invariant Enforcement In a multi-domain ledger, every transition between domains with different state, authorization or validation semantics must explicitly preserve every applicable consensus invariant spanning those domains. The local validity of the participating domains is necessary but not sufficient. Consensus must validate the semantic relation connecting their source and destination states. Preservation must be established before acceptance. Confidentiality makes reliance on later economic reconstruction particularly unsuitable; transparent state does not remove the obligation. Its operational corollary is: A cross-domain proof obligation must cover the complete semantic transition, not merely demonstrate that its individual objects are locally valid. Conclusion The HF6 incident makes the responsibilities of a multidomain architecture especially concrete. The lesson should not be that Zano should avoid specialized domains. Gateway Addresses address real integration requirements, and future post-quantum evolution may itself benefit from controlled coexistence between different cryptographic domains. Multidomain architecture can therefore be an important source of evolutionary flexibility. But modularity moves part of the security problem to the boundaries. As domains become more explicit, their transitions must become equally explicit. Monetary conservation, asset integrity, authorization, state consumption and migration semantics should not remain emergent properties of interacting code paths. They should become named invariants with explicit enforcement points. A future Gateway redesign is an immediate opportunity to apply this discipline before reactivation. A future post-quantum migration may make it indispensable. The objective is therefore not merely to ensure that every Zano domain is secure independently. It is to ensure that: every transformation between domains preserves the properties that make all of those domains one coherent protocol. References hyle-team/zano, v2.2.3.600 — Emergency release, 27 September 2026. Primary source for the documented supply incident, rollback and temporary Gateway disabling. Official release hyle-team/zano, v2.2.3.603, 5 October 2026. Confirms continuation of the emergency rollback. Official release Zano Docs, Gateway Addresses (GW) in Zano. Design and API reference; not an operational-enablement or audit attestation. Official documentation GinoFPM, Zano Team, statement in Introducing Zenith: Zano's move to pure Proof of Stake. Source for the announced audit policy, revised fork numbering and absence of a committed delivery order. Specific forum post E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta and B. Ford, OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding, IEEE Symposium on Security and Privacy, 2018, DOI 10.1109/SP.2018.000-5. UCL Discovery F. Marić, B. Scholz and P. Subotić, Formal Verification of a Fail-Safe Cross-Chain Bridge, FMBC 2025, DOI 10.4230/OASIcs.FMBC.2025.8. drops.dagstuhl.de Jinwook Kim (for the Oraclizer Core Team), The Cross-Domain State Preservation Functor: A Mechanized Theory of Regulatory State Synchronization in Isabelle/HOL, 2026 preprint, version 4, revised 23 August 2026. arXiv:2604.03844v4

Can we have a forum post with links to zano website and wallets and stuff like we had in discord ?*

It is useful to know that the team regards quantum resistance as part of Zano’s long-term security. However, the public roadmap does not yet make any corresponding preparation visible, even though this is precisely the stage at which a cryptographic inventory and transition planning should already be under way, as reflected in the preparatory phases already set out by the United States, the European Union and the United Kingdom. As I noted earlier, HF7 is the natural architectural window in which to begin that preparation. The remaining question is narrower: Is HF7 being designed to preserve the ability to introduce hybrid authorisation and an orderly migration path later, without requiring the transaction architecture to be redesigned under emergency conditions?

@fbirde That is a separate and interesting debate, but it falls outside the scope of this post. The question addressed here is whether Zano can complete an orderly post-quantum transition in time — before the failure of its current cryptographic assumptions turns a planned migration into an emergency.

Zarcanum’s Economic Fog: Why It May Slow the First Quantum Attacks — but Cannot Make Zano Quantum-Resistant Introduction Discussions about quantum attacks on blockchains often assume a simple transition: One day elliptic-curve cryptography is secure; the next day every vulnerable key can be broken immediately. The real transition may be much less abrupt. The first quantum systems capable of running Shor’s algorithm against production elliptic-curve cryptography are likely to remain scarce, expensive and operationally constrained. Even after the first successful cryptographic breaks, an attacker may be able to recover only a limited number of private scalars within a useful period. This distinction matters. A quantum adversary with abundant capacity could eventually process enormous parts of a blockchain, recover private scalars from public curve points, reconstruct historical transaction relations and attack every remaining classical output. A resource-constrained adversary must instead choose: Which public keys should be attacked first? Zarcanum may give Zano an important advantage during this initial phase. Zarcanum is not post-quantum cryptography. It does not remove Zano’s dependence on elliptic-curve discrete-logarithm hardness. However, it conceals much of the economic and transactional information an attacker would need to allocate scarce quantum resources efficiently. This article refers to that effect as economic fog. The expression does not describe a formal cryptographic security property. It describes an operational obstacle: the attacker can see many public cryptographic objects, but cannot easily determine which ones contain the greatest accessible value. That distinction may create meaningful initial quantum friction. It must not, however, be confused with genuine quantum resistance. 1. The quantum problem begins at the output level A private Zano output uses a one-time public key of the general form: [ P=xG ] where: (P) is published in the blockchain; (x) is the one-time private scalar controlling that particular output; (G) is the elliptic-curve base point. The user’s permanent wallet address is not written directly into the output. This is a major privacy property: different incoming payments do not publicly expose one reusable receiving identity. But address privacy and output custody are different properties. If an adversary can solve the elliptic-curve discrete logarithm problem, it can recover: [ x=\log_G(P) ] The attacker does not first need to discover the permanent wallet address. It does not need the private view key, the permanent spend key or a previous staking event. The published output key itself contains the relation that becomes invertible under Shor’s algorithm. Therefore: Zarcanum outputs are not quantum-safe merely because their owners and amounts remain hidden. Every unspent classical Zano output ultimately depends on the continued exclusivity of its one-time private scalar. 2. What Zarcanum actually hides Although Zarcanum does not remove the vulnerable public-key relation, it changes the information environment surrounding it. A normal Zarcanum-era output does not publicly reveal, in directly readable form: its amount; its asset type; the permanent wallet that received it; which other outputs belong to the same holder; whether it represents a large or insignificant part of a wallet; or whether it later participated in staking. Zano’s confidential transaction system combines several mechanisms: one-time destination keys; confidential amount commitments; blinded asset tags; ring-based anonymous authorization; key images for double-spend prevention; and proofs connecting ownership, amount, asset type and validity. Zarcanum extends this private output domain into proof of stake. A participant can prove control of an eligible native-asset output and satisfy the staking condition without publicly disclosing the selected output or its amount. The result is not that the public key disappears. The result is that the attacker sees: [ P_1,P_2,P_3,\ldots,P_n ] without an obvious public ranking such as: [ P_7 = 250{,}000\ \text{ZANO} ] [ P_{31} = 0.8\ \text{ZANO} ] [ P_{82} = \text{another confidential asset} ] For a classical observer, those economic distinctions remain hidden. For a quantum attacker whose available executions of Shor are still limited, that uncertainty matters. 3. The attacker’s targeting problem Suppose an early quantum adversary can recover only a relatively small number of elliptic-curve scalars per day or per month. The attacker must estimate the expected return from targeting a public output: [ \text{expected return} \text{probability that it is unspent} \times \text{expected value} \times \text{probability of successful exploitation} ] Zarcanum makes each factor harder to estimate. Is the output still unspent? In a transparent UTXO system, the active unspent-output set can be directly enumerated. In a ring-signature system, the blockchain publishes a set of candidate outputs for each spend and a key image derived from the real input. Under classical assumptions, observers cannot determine which ring member generated that image. A quantum attacker can resolve the ambiguity, but doing so may itself require quantum work. For a candidate output: [ P_i=x_iG ] the attacker can recover (x_i), calculate the corresponding key image relation and compare it with published key images. If a match exists, that output was spent. If no match exists, it may remain unspent. But an attacker with limited Shor capacity may have spent one of its valuable computations merely to discover that the chosen output is already obsolete. Historical ring anonymity would eventually collapse under sufficiently broad discrete-logarithm recovery, but this does not mean that every ring can be resolved without cost during the first phase. How much value does it contain? Zarcanum-era amounts are hidden inside commitments. A simplified Pedersen commitment can be written as: [ C=aH+fG ] where: (a) is the amount; (f) is a random blinding factor; (G) and (H) are public generators. Even if a quantum adversary learns the discrete-logarithm relation between the generators, the published commitment does not necessarily reveal one unique historical amount. Many amount-and-mask combinations may correspond to the same point. This is an important nuance. Breaking elliptic-curve discrete logarithms may destroy the binding property of the commitment, threatening balance proofs and monetary integrity, without automatically revealing every historical amount in a unique and convenient form. Thus, an attacker may recover the one-time spending scalar of an output and still have lacked a reliable public estimate of its value before committing resources to the attack. What asset does it contain? Zano supports confidential assets through blinded asset tags and associated proofs. An ordinary observer cannot simply sort all outputs into: ZANO; fUSD; another confidential asset; or a negligible-value token. A complete failure of the underlying curve assumptions would threaten the soundness and binding of those asset relations. But again, total failure of integrity does not necessarily imply that every historical asset label becomes immediately and uniquely readable. For a selective attacker, uncertainty about the asset further reduces the value of blindly choosing a public output key. Does it belong to an important holder? A normal Zano wallet does not publicly expose one stable balance-bearing account. Outputs belonging to the same wallet are designed not to be trivially grouped. A large holder may therefore be represented by many apparently unrelated outputs whose combined value is not publicly visible. The attacker may see millions of public points while lacking a reliable way to say: These 27 outputs together belong to one holder controlling 400,000 ZANO. That is the core of the economic fog. 4. Zarcanum adds friction at more than one stage The protection is not a single obstacle. It appears at several stages of the attack. Target discovery The attacker cannot easily rank all private outputs by amount or wallet balance. Spent-output classification Determining whether an output remains live may require recovering its scalar and testing its key-image relation. Historical reconstruction Following the ancestry of a wallet may require resolving rings repeatedly across multiple transactions. Successor identification A transaction can produce more than one output. Even after identifying the true spent input, determining which new output carries forward the target’s value may require additional wallet information, later transaction analysis or further quantum work. Current-state maintenance If an output is consumed legitimately before the attacker completes the theft, its recovered private scalar no longer controls the current value. The attacker must locate and attack the successor. This can occur through an ordinary transaction or when an eligible output actually wins a Zarcanum staking event and is consumed and recreated. This renewal effect should not be exaggerated. Only outputs that are actually spent or selected successfully for staking are replaced. Many outputs may remain unchanged for long periods. Nevertheless, against a slow and selective adversary it adds another source of possible wasted effort. 5. Limited Shor capacity does not mean a partially broken key The expression “limited quantum attacker” needs precision. Shor’s algorithm does not normally return half of a usable private key. Either the discrete logarithm is recovered successfully or it is not. The limitation lies instead in throughput: how many logical qubits are available; how deep and reliable the quantum circuit is; how long one computation takes; how frequently it can be repeated; how many machines can operate in parallel; and how many attacks can be completed before defenders react. The relevant early scenario is therefore not “partial Shor” in the mathematical sense. It is: Successful Shor computations, but only against a limited number of selected public points. Economic fog is most valuable in exactly that scenario. If the attacker can process every public point on the chain cheaply, target selection no longer matters. 6. Three possible stages of quantum pressure The decline of Zarcanum’s passive protection can be understood in three broad stages. Stage 1: Selective quantum attacks The attacker can recover only a small number of private scalars. It will prefer targets that are: publicly identified; known to contain substantial value; known to remain active; and simple to exploit. Ordinary private Zarcanum outputs may be unattractive because the attacker cannot easily determine their economic value. Transparent accounts, public treasury wallets, known service reserves and old outputs with visible amounts may be selected first. At this stage, Zarcanum’s economic fog may provide substantial passive protection. Stage 2: Analytical quantum attacks The attacker can process larger numbers of outputs and ring members. It begins to: resolve historical rings; calculate candidate key images; distinguish spent from unspent outputs; follow selected transaction lineages; group activity using external metadata; and attack known wallets systematically. The fog begins to thin. Private outputs remain harder to analyse than transparent balances, but the attacker can now invest enough resources to reconstruct selected portions of the ledger. Stage 3: Industrial-scale curve compromise The attacker can process large fractions of the chain or routinely recover the secrets behind all relevant elliptic-curve relations. At this stage: one-time output secrets become recoverable at scale; historical ring members can be identified; key-image privacy collapses; Schnorr- and CLSAG-family proofs lose their classical security basis; Pedersen commitments lose binding; confidential-asset proofs may become forgeable; and private staking eligibility becomes vulnerable. The economic fog no longer provides meaningful custody protection. Zano must then be considered fundamentally compromised unless value and consensus have already migrated to cryptographic constructions based on independent post-quantum assumptions. 7. Important exceptions to the fog Not every Zano wallet receives the same passive protection. Auditable wallets A public tracking mechanism can identify a wallet’s balance and history without exposing its classical private spending key. This transparency is useful for accountability, but it also helps an attacker locate the wallet’s relevant outputs. The development fund is the clearest example. Its live balance and public auditability remove much of the target-selection uncertainty that protects an ordinary private wallet. Exchanges, bridges and custodians Large services may be identifiable through: published addresses; operational wallet patterns; deposits and withdrawals; internal leaks; regulatory disclosures; or infrastructure compromise. Zarcanum protects on-chain privacy, but it cannot erase information revealed outside the chain. Legacy outputs Pre-Zarcanum outputs with explicit amounts are easier to value. Most economically active holders appear likely to have migrated to Zarcanum-era outputs, particularly because only the new output domain participates in current private staking. But dormant, abandoned or lost legacy outputs may remain. Those outputs could become attractive early targets because their value is visible and their owners may no longer be capable of reacting. Known individual wallets A private wallet loses part of its economic fog when an adversary possesses: its tracking information; exchange records; compromised wallet metadata; address correspondence; or reliable knowledge of its output set. Zarcanum provides on-chain opacity, not immunity from external operational intelligence. 8. Why Zarcanum is still not quantum-resistant The strongest possible misunderstanding would be to conclude: Because Zarcanum hides the attacker’s best targets, Zarcanum protects funds against Shor. It does not. The public one-time output relation remains: [ P=xG ] The authorization system still depends on elliptic-curve secrets and proofs. The confidential-value system still depends on commitments whose binding relies on unknown generator relations. The anonymous-spending system still depends on ring and key-image relations whose security assumes discrete-logarithm hardness. The private staking system composes: output ownership; anonymous membership; confidential amount proofs; native-asset proofs; key-image or linkability relations; and block authorization. These mechanisms form one deeply connected elliptic-curve domain. Zarcanum extends classical privacy into consensus; it does not create a cryptographically independent post-quantum layer. Therefore, economic fog can change: the order of attacks; their cost; their expected profitability; and the time required to map the ledger. It cannot change the final mathematical result once curve discrete logarithms become routinely solvable. 9. Passive friction should accelerate migration, not delay it The possible advantage of Zarcanum is strategically valuable precisely because it may buy time. That time could be used to: define cryptographic-domain versioning; introduce hybrid protected outputs; create wallet migration and recovery tools; protect the development fund and other known reserves; coordinate exchanges and custodians; test new transaction formats; and begin replacing the private cryptographic domain in stages. A first hybrid custody mechanism does not need to recreate the whole of Zarcanum immediately. It could introduce a new output type requiring: [ \text{classical authorization} \land \text{independent post-quantum authorization} ] An adversary who later recovers every associated elliptic-curve scalar would still be unable to spend the migrated output without the independent post-quantum secret. This would protect custody while research continued into the harder problems: post-quantum unlinkable reception; anonymous authorization; double-spend nullifiers; confidential commitments; range and balance proofs; confidential assets; and private proof-of-stake eligibility. The economic fog should therefore be treated as a migration window, not as a substitute for migration. 10. The strategic opportunity for Zano Zano may occupy an unusual position during the first stage of the quantum transition. Compared with transparent blockchain systems, it can be difficult to rank its private outputs by value. Compared with much larger privacy systems, it may offer a smaller total economic reward to an attacker. Compared with large ecosystems, it may also have fewer exchanges, custodians and wallet implementations to coordinate during migration. These factors do not guarantee safety. A state actor, hostile laboratory or strategic adversary may choose Zano for reasons unrelated to immediate profit. The development fund and other known institutional wallets remain obvious targets. A hidden attacker may also possess information unavailable to public observers. But Zarcanum may still alter the economics of the earliest attacks enough to create a valuable interval in which Zano can act. The critical question is not whether the fog will last indefinitely. It will not. The question is: Can Zano use the period in which quantum attacks remain selective and expensive to migrate economically important value before attacks become broad and routine? Conclusion Zarcanum does not make Zano post-quantum secure. Every classical output still publishes an elliptic-curve one-time public key. The authorization, ring, commitment, confidential-asset and private-staking systems remain dependent on mathematical assumptions that Shor’s algorithm is designed to defeat. But this is only half of the strategic picture. Zarcanum conceals the information a resource-constrained attacker would normally use to select targets: output values; asset types; wallet groupings; staking-output identity; and much of the transaction lineage. This creates an economic fog around ordinary private outputs. During an initial period of scarce Shor-capable resources, that fog may increase the cost of reconnaissance, cause attackers to waste computations on spent or low-value outputs, and direct their attention toward clearer and more profitable targets. That is meaningful passive resistance. It is not durable cryptographic resistance. The correct conclusion is therefore: Zarcanum may slow the first selective quantum attacks, but only a migration to independent post-quantum authorization can protect Zano once elliptic-curve compromise becomes scalable. The time potentially gained by Zarcanum should not be used to postpone the transition. It should be used to make the transition possible before the fog begins to disappear.

This post examines a narrower question than whether quantum computers will eventually threaten elliptic-curve cryptography: Has the combination of Microsoft's 2029 roadmap and recent reductions in the quantum resources required for elliptic-curve discrete logarithms made a cryptographically relevant machine by the end of the decade a credible planning scenario? The answer is still uncertain, but the possibility can no longer be dismissed as remote. What Microsoft has actually announced Microsoft has not announced that the current Majorana 2 processor will enter industrial production in 2029, nor has it published the number of logical qubits that its proposed 2029 machine will provide. Majorana 2 is a multi-tetron experimental device. Microsoft describes a tetron as a topological qubit built from two superconducting nanowires with Majorana Zero Modes at their ends. The four-qubit array shown in the Majorana 2 publication therefore represents four topological physical qubits, not four fault-tolerant logical qubits. This distinction is essential. A logical qubit is obtained only after quantum error correction and must remain reliable throughout a very long computation. Consequently, it is not valid to divide the logical-qubit requirement of Shor's algorithm by four and interpret the result as a number of Majorana 2 processors. What Microsoft does state is that Majorana 2 has improved qubit stability by approximately three orders of magnitude over its previous processor, with mean lifetimes around 20 seconds, operations on the microsecond scale, and an architecture intended to scale. On that basis, Microsoft says that it now aims to deliver a scalable and practical quantum computer by 2029. That is a roadmap target, not a declaration that ECC-256 will be breakable in 2029. However, it provides a concrete engineering horizon against which cryptographic migration lead times can be assessed. Microsoft's own earlier estimate for attacking P-256 Microsoft's Azure Quantum Resource Estimator previously evaluated a Shor attack against the P-256 elliptic curve. Under its predefined Majorana hardware assumptions, the estimate was approximately: Majorana, reasonable assumptions: 3.69 million physical qubits 8 hours Majorana, optimistic assumptions: 1.10 million physical qubits 4 hours These estimates were based on an older logical circuit and assumed gate and measurement times of 100 nanoseconds. They should not be treated as a prediction for Majorana 2. Microsoft now describes Majorana 2 operations as occurring on the microsecond scale, and the actual physical-to-logical conversion, logical error rate, code distance, magic-state production capacity and system architecture of a 2029 machine have not been disclosed. Nevertheless, the estimate is important for one reason: Microsoft itself has modelled an ECC-256 attack as a million-scale physical-qubit problem under a topological architecture, rather than as a problem requiring an astronomically larger machine. The logical-qubit requirement is falling The cryptanalytic side of the equation has changed materially during 2026. A March 2026 analysis of elliptic-curve cryptocurrencies estimated that the 256-bit elliptic-curve discrete logarithm problem could be solved using either: fewer than 1,200 logical qubits and fewer than 90 million Toffoli gates, or: fewer than 1,450 logical qubits and fewer than 70 million Toffoli gates. The authors estimated minute-scale execution on a fast superconducting architecture with fewer than half a million physical qubits under their stated assumptions. Those physical estimates do not transfer directly to Microsoft's topological architecture, but they demonstrate that improved circuits can substantially reduce the cryptanalytic threshold. A further paper published in July 2026 reduced the width for a 256-bit prime-field curve to 835 logical qubits. This is a space-optimized construction and therefore involves a significant time/gate trade-off. It should not be interpreted as proving that any machine with 835 logical qubits can immediately break ECC-256. The machine would also need sufficient logical fidelity, circuit depth, non-Clifford operations, classical feed-forward and total execution time. The important trend is not one isolated number. It is the downward progression: approximately 2,124 logical qubits in the earlier estimate, then approximately 1,100-1,450, and now 835 in a space-optimized construction. Hardware roadmaps and attack algorithms are improving simultaneously. What can and cannot be inferred for Zano Zano uses Ed25519-domain elliptic-curve constructions rather than P-256 or secp256k1. The published figures above therefore cannot be copied directly into a Zano threat estimate. A defensible calculation would require a circuit and resource estimate specifically adapted to the curve operations, coordinate system, error-correction model and hardware assumptions relevant to Ed25519. However, Ed25519 is not outside the scope of Shor's algorithm. It relies on the hardness of an elliptic-curve discrete logarithm over a prime field of comparable security scale. It is therefore reasonable to expect the required resources to be in a broadly comparable class, while leaving the exact count as an open technical question. For Zano, the consequence is more direct than a conventional on-spend attack against a temporarily exposed public key. Every private or legacy UTXO publishes a one-time output public key of the form: P = xG where x is the one-time private spending key. If an adversary can solve the discrete logarithm on the curve, the attack is: x = log_G(P) The permanent wallet address may remain hidden, but the individual output can lose custody security. The attacker does not need to wait for the owner to spend the output or reveal a permanent public key. Historical unspent outputs are already available for precomputation and prioritisation. This means that faster blocks or shorter confirmation times under Zenith do not remove the underlying exposure. They may improve the response window for some transaction-race scenarios, but they do not protect a public one-time output key whose secret can be recovered directly. The appropriate conclusion The evidence does not justify the statement: Microsoft will break ECC-256 in 2029. It does justify a more careful statement: A fault-tolerant machine of the scale Microsoft is targeting for the end of the decade may fall within the resource class required by increasingly efficient attacks against 256-bit elliptic curves. This remains conditional on unresolved factors: the number of usable logical qubits; the physical-to-logical overhead; logical error rates and code distance; gate and measurement speed; magic-state production throughput; system interconnection and control; the runtime of the selected attack circuit; and the exact resource requirements for Ed25519. The probability is not established. The planning consequence is clearer. A post-quantum migration for Zano requires architectural design, implementation, independent review, testnet operation, wallet changes, backup changes, service integration and enough time for users to migrate economically significant value. Beginning that work only after a cryptographically relevant quantum computer has been demonstrated would be too late, because existing output public keys are already on-chain. For planning purposes, 2029 should therefore be treated as a conservative engineering boundary, not as a predicted break date. A concrete question for the Zano roadmap The most useful immediate step may be to commission or reproduce a Zano-specific quantum resource estimate covering Ed25519 and the principal Zano relations built upon it. At minimum, it should distinguish: logical-qubit width; Toffoli or T-gate count; circuit depth; physical-qubit requirements under several error-correction models; expected runtime under fast and slow hardware clocks; and the difference between recovering a one-time spending key and attacking the wider Zarcanum/Zenith proof system. Such an estimate would not solve the transition problem, but it would replace broad analogy with a measurable threat model and help determine how much of the post-quantum groundwork must be incorporated into the HF7/HF8 architectural cycle. My present assessment is therefore: It is not confirmed that Microsoft's proposed 2029 machine will be able to attack Ed25519. However, given the scale Microsoft is targeting and the reduction of published ECC-256 attack estimates to approximately 835-1,450 logical qubits, that possibility is no longer remote enough to justify postponing Zano's post-quantum preparation until after 2029. References Microsoft Quantum, "Majorana 2 – Microsoft's Scalable Quantum Processor With Reliable, Long-Lasting Qubits" https://quantum.microsoft.com/en-us/insights/blogs/majorana-2-scalable-quantum-processor Microsoft Quantum, "Calculating resource estimates for cryptanalysis" https://quantum.microsoft.com/en-us/insights/blogs/resource-estimation/calculating-resource-estimates-for-cryptanalysis Babbush et al., "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations," arXiv:2603.28846 https://arxiv.org/abs/2603.28846 Luo et al., "Quantum Algorithm for Elliptic Curve Discrete Logarithms with Space-Efficient Point Addition," arXiv:2607.13816 https://arxiv.org/abs/2607.13816

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: programme foundation and cryptographic inventory; quantum-safe custody and migration; post-quantum unlinkable reception; post-quantum anonymous authorization and double-spend prevention; post-quantum commitments, confidential values and assets; private post-quantum eligibility for Zenith; 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 Is a post-quantum cryptographic inventory or transition architecture already being developed internally? Are the HF7 input, output and proof formats still open to explicit cryptographic-domain versioning? Could a hybrid custody output be introduced alongside Zenith while remaining initially ineligible for staking? Can the epoch, slot, snapshot and fork-choice implementation be separated more clearly from the concrete eligibility-proof verifier? Which roadmap projects actually compete for the same core developers, wallet engineers, auditors and release capacity? Would the team consider publishing a formal post-quantum threat model and migration requirements before selecting final primitives? 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