Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Zano)
  • No Skin
  • Gino
  • Zano
Collapse
Zano Forum

Zano Forum

Y

Yep

@Yep
Unfollow Follow
About
Posts
19
Topics
7
Shares
0
Groups
0
Followers
0
Following
5

Posts

Recent Best Controversial

  • Two Gateway Addresses Registered in Zano’s First Week After HF6
    Y Yep

    HF6 has only been live for a few days, but we already have an interesting early signal: at least two Gateway Addresses have been registered on-chain.

    HF6 was activated on August 28, and the first registration appeared shortly afterwards.

    First Gateway registration

    • Block: 3,836,052
    • Transaction: 03edb09ab5d9ec759aa2c2b98b377499cdb136e6a222622c75445d095902c517
    • Registration fee: 100 ZANO
    • The transaction contains a gateway_address_descriptor_operation_register operation.

    A second registration appeared only a few days later.

    Second Gateway registration

    • Block: 3,844,508
    • Date: September 3, 2026
    • Transaction: 99e48b4e35f03b0a2e8f531e9deeaed2c111765503171380fc745d6b9debc7ef
    • Registration fee: 100 ZANO
    • Total transaction fees in the block: 100.05 ZANO
    • The transaction also explicitly contains a gateway_address_descriptor_operation_register operation.

    This means that two Gateway Addresses have been registered during the first week after HF6 activation.

    There is another relevant detail: transaction fees in Zano are burned. Therefore, the 100 ZANO registration fee is not a refundable deposit or an amount transferred to another participant. It is permanently removed from circulation.

    These first two Gateway registrations have therefore already resulted in approximately 200 ZANO being burned through registration fees alone.

    Why this may be significant

    A Gateway Address registration is not just an ordinary transaction. According to the Gateway implementation, registering one requires a fee of at least 100 ZANO.

    And because that fee is burned, registering a Gateway Address represents a genuine economic commitment. The registrant is deliberately giving up 100 ZANO in order to create the address.

    That makes these registrations more interesting than simple test transactions costing a fraction of a ZANO.

    A single Gateway Address immediately after HF6 could easily be explained as an initial deployment or test. A second registered address several days later begins to provide evidence that the new Gateway functionality is actually being used on mainnet.

    The fact that approximately 200 ZANO have already been irreversibly spent on these registrations makes repeated registrations somewhat less likely to be casual experimentation.

    Can we identify the owners?

    This is probably the most interesting question now.

    The second registration exposes, among other information, the following public key:

    36975f30104699c2d8b941028de113b4a9b3887a39bd33eb9f58b62ec8063298

    and an Ethereum-related owner public key:

    03e46e58e6f3ae4cf8f9e8fa6e236e2b220519b9d863f184adc1cf29cd4a09e87b

    At the moment, however, there does not appear to be public evidence to attribute this Gateway Address confidently to a particular exchange or service.

    It will therefore be worth watching these addresses for subsequent activity, descriptor or metadata changes, asset movements, and other on-chain operations that might reveal their purpose.

    If anyone can associate either registration with a known service or entity from publicly verifiable information, that would be particularly useful.

    What to watch next

    It is too early to call this adoption by exchanges, but it is certainly an encouraging sign that the new infrastructure is already being exercised on mainnet — and at a non-trivial, irreversible cost to those registering the addresses.

    If anyone can identify the entities behind these first two registrations from publicly verifiable information, please share the evidence here.

    General Discussions

  • HF6 in Action: First Gateway Address Registered on Mainnet
    Y Yep

    @adiela-0 The next thing I would watch for is actual use of Gateway Addresses by services: balance changes, deposits and withdrawals, additional registrations, and possibly integration by exchanges or payment infrastructure.

    General Discussions

  • HF6 in Action: First Gateway Address Registered on Mainnet
    Y Yep

    @petrex-0 Gateway Addresses are mainly intended for services that need a persistent, publicly trackable account-style address on Zano: exchanges, payment processors, gateways, automated services, and similar infrastructure.
    Unlike normal private Zano addresses, a Gateway Address has directly trackable balances and visible asset/amount information, which makes accounting, deposits, withdrawals and automated integration much simpler.
    The idea is not to replace Zano’s private addresses, but to add a service-oriented option for cases where public, deterministic accounting is useful.
    In the future, with the right tooling and security controls, this model could also be well suited to autonomous AI agents, since they can work with directly queryable balances, deterministic accounting and automated payment flows.

    General Discussions

  • Freedom Dollar (fUSD) — the private, decentralized stablecoin native to Zano
    Y Yep

    fUSD has massive potential.

    Projects on Zano fusd stablecoin defi

  • HF6 in Action: First Gateway Address Registered on Mainnet
    Y Yep

    Just over two days after HF6 activation, the first Gateway Address has been registered on mainnet.

    The registration transaction was included in block 3,836,052 and contains a gateway_address_descriptor_operation_register, with the required 100 ZANO fee:

    https://explorer.zano.org/transaction/03edb09ab5d9ec759aa2c2b98b377499cdb136e6a222622c75445d095902c517

    This is a small but meaningful milestone. It provides the first visible on-chain confirmation that the Gateway Address registration mechanism introduced by HF6 is operating successfully on mainnet. HF6 is not only live: its new functionality has already produced its first observable result.

    Congratulations to the Zano team and everyone involved in this successful activation!

    General Discussions

  • Andre is LIVE with Cointelegraph to talk about Zenith
    Y Yep

    This was a very interesting interview, particularly the discussion about how AI is already being used as an engineering tool within the project.

    I may be mishearing a very brief remark at around 38:00, and Andrey’s wording is not entirely clear to me, but I think he says something close to:

    “It could be that not quantum computing will destroy most of crypto, but actually AI, way earlier than we expected.”

    I am also not certain whether “crypto” here means cryptography itself or the wider cryptocurrency ecosystem. If he means the latter, I agree with the broader point: AI may expose weak code, automate attacks and eliminate fragile projects much sooner than many people expect.

    My only reservation is that the comparison may unintentionally make the quantum risk sound more distant than recent developments justify. Progress has been remarkably rapid on both the theoretical and practical fronts. Taken together, recent advances suggest that estimated resource requirements are falling and that major engineering barriers — including error correction, control integration and the challenges of monolithic scaling — are being reduced faster than older expectations assumed.

    I hope I am not reading too much into a passing remark, but I also hope it does not reflect an underestimation by the Zano team of the extraordinarily rapid advances in quantum computing. For Zano, this is not merely a future signature replacement: output ownership, anonymous authorisation, key images, commitments, confidential assets and private Proof of Stake all depend on the present elliptic-curve domain. If preparation begins too late, that dependency could become an existential security risk on a much shorter horizon than is often assumed.

    Content

  • Zarcanum’s Passive Quantum Shield — and the Development Fund Exception
    Y Yep

    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?

    Development

  • Zarcanum’s Passive Quantum Shield — and the Development Fund Exception
    Y Yep

    @htzano Zano should not compare itself with the residual systems scheduled for completion by 2035. Functionally, it is much closer to a high-value, high-impact system: it secures live monetary value, irreversible bearer assets, confidential transaction history, and the integrity of its own consensus and asset rules.

    Under the current US programme, systems in that risk class are being inventoried and planned for in 2026–2027, piloted and migrated early in 2027–2028, and prioritised for migration during 2028–2030, with digital-signature migration completed and priorit in 2031.

    For Zano, even that comparison may be conservative. Federal agencies can impose migration, rotate credentials and centrally coordinate users. Zano cannot compel dormant holders to move their outputs, and a cryptographic failure could permit irreversible theft before an emergency fork could protect them.

    The relevant lesson is therefore not that Zano has until 2035. It is that a system holding high-value, irreversible assets should already be entering its planning and pilot phase.

    If Zano is treated as a high-value monetary system rather than as residual infrastructure, HF7 is not early preparation. It is already the natural architectural window for beginning that preparation.

    Development

  • Zarcanum’s Passive Quantum Shield — and the Development Fund Exception
    Y Yep

    @htzano Thanks for the comment, but I do not think it is justified to say that practical quantum attacks are “a fair while off”.

    Recent theoretical work has repeatedly reduced the estimated resources required to attack elliptic-curve cryptography, while hardware development, error correction and quantum-control techniques are also advancing faster than many earlier projections assumed. No one can currently establish a safe remaining window for Ed25519. Uncertainty is therefore not evidence that there is plenty of time.

    Nor is “larger targets will be attacked first” a security argument. Banks and major financial institutions are already conducting cryptographic inventories and preparing post-quantum migration. Ethereum has also established a public post-quantum research and transition programme. They are not volunteering to absorb the first successful attacks so that smaller networks receive advance warning.

    An attacker will select targets according to probability of success, cost, ease of monetisation and strategic impact—not simply nominal size. As larger systems become better protected, a smaller but less prepared network, particularly one containing a concentrated and identifiable development fund, may become comparatively attractive.

    A fast fork is not a substitute for preparation either. Once elliptic-curve security has failed, a fork cannot retroactively create a safe custody destination, complete a migration, recover stolen funds or undo the loss of historical privacy.

    Other potential victims are not a quantum-security layer for Zano. The burden of proof lies with anyone claiming that there is still ample time—not with those asking the protocol to prepare before that assumption is tested.

    Development

  • Zarcanum’s Passive Quantum Shield — and the Development Fund Exception
    Y Yep

    Zarcanum’s Passive Quantum Shield — and the Development Fund Exception

    Introduction

    A cryptographically relevant quantum computer would not necessarily begin by breaking every elliptic-curve key visible on every blockchain.

    The first machines capable of running Shor’s algorithm against 256-bit elliptic-curve cryptography would probably remain scarce, expensive and slow. An early attacker might be able to recover only a limited number of private scalars within a useful period. Each quantum computation would therefore need to be directed toward a target with a high expected return.

    This matters for Zano.

    Zarcanum does not make Zano post-quantum secure. Current Zano outputs still contain elliptic-curve one-time public keys, and the wider construction remains dependent on elliptic-curve discrete-logarithm assumptions. Nevertheless, Zarcanum may provide Zano with a valuable form of passive resistance during the first phase of the quantum threat.

    For an ordinary private wallet, an attacker sees many public curve points but lacks much of the information needed to decide which ones are worth attacking. Amounts are hidden, asset types are hidden, recipients use unlinkable one-time addresses, ring signatures obscure the real input, and Zarcanum allows stake to participate without publicly revealing either the staking output or its amount.

    The attacker therefore faces an economic selection problem:

    • Which outputs are still unspent?
    • Which outputs contain ZANO rather than another confidential asset?
    • How much does each output contain?
    • Which outputs belong to the same holder?
    • Which public keys justify the cost of a scarce Shor computation?

    This creates a kind of economic fog around Zano’s cryptographic attack surface.

    It is not post-quantum security. A sufficiently capable quantum attacker could eventually break the elliptic-curve relationships on which the system depends. But while quantum capacity remains limited, the inability to identify and value targets may make ordinary Zarcanum outputs less attractive than transparent and much more highly capitalised targets elsewhere.

    There is, however, an important exception inside the Zano ecosystem: the development fund.

    Transparency removes much of the economic fog

    Zano’s development fund is held in an auditable wallet. This is a legitimate and valuable transparency mechanism. The community can verify the fund’s balance and transaction history without receiving spending authority.

    Zano publishes the fund’s tracking seed, and the official explorer reports its balance in real time:

    • Zano Block Explorer
    • Zano documentation: Auditable Wallets
    • Zano documentation: Tokenomics and the Foundation Fund

    Under current cryptographic assumptions, the tracking seed cannot spend the fund. It provides observation capability, not the private spending authority.

    From the perspective of a resource-constrained quantum attacker, however, it supplies something extremely valuable: targeting information.

    For an ordinary private wallet, the attacker must search blindly among a very large number of outputs. For the development fund, the public audit mechanism identifies a wallet with a known institutional owner, a known live balance and a reconstructible history.

    The problem is no longer:

    Which unknown outputs might contain a significant amount of ZANO?

    It becomes much closer to:

    Which current outputs belong to this publicly tracked, high-value wallet?

    That difference could be decisive while Shor-capable resources remain scarce.

    Why the development fund is an unusually attractive target

    The development fund combines several properties that a selective quantum attacker would value.

    1. The target is publicly identified

    The attacker does not need to infer whether a valuable wallet exists. Its purpose, balance and history are intentionally public.

    2. The expected reward can be estimated

    The live explorer removes much of the uncertainty that normally protects confidential Zano balances. The attacker knows that the wallet controls a substantial amount of ZANO before committing expensive quantum resources.

    3. The tracking seed narrows the relevant output set

    The tracking seed is designed to let an observer reconstruct the wallet’s balance and transaction history. It therefore reduces the search space that protects ordinary users.

    It does not reveal the private spending key. It does, however, help an attacker distinguish the fund’s activity from the general mass of private Zano activity.

    4. The strategic value exceeds the market value of the coins

    A successful attack would not merely steal ZANO. It could also deprive the project of the resources needed to respond to the quantum emergency itself.

    The development fund finances engineering, maintenance, audits, integrations, partnerships and continued protocol development. During a post-quantum transition, those resources would become especially important.

    The attacker’s potential payoff would therefore be:

    [
    \text{direct financial theft}
    +
    \text{strategic weakening of the project}
    ]

    For an adversary whose purpose was disruption rather than simple profit, the second component might be the more important one.

    What the attacker would still have to do

    The fund is not automatically spendable merely because it is auditable.

    Each current output contains an elliptic-curve one-time public key, conventionally represented as:

    [
    P_i = x_iG
    ]

    A sufficiently capable quantum computer could use Shor’s algorithm to recover the corresponding scalar (x_i). But ZC transactions are more complex than ordinary transparent signature transactions. Their validity also involves confidential commitments, blinded asset tags, masking relations and d/v-CLSAG proofs.

    It should therefore not be asserted without a formal cryptographic analysis that recovering one one-time private scalar always produces an immediately spendable ZC output with no additional work.

    The narrower and safer conclusion is this:

    The public audit mechanism tells a quantum attacker which elliptic-curve outputs are associated with a large and strategically important reserve, greatly improving target selection.

    A broad break of the elliptic-curve discrete-logarithm assumption would ultimately threaten the entire construction. The open technical question is the minimum set of secrets and relations that an attacker would need to reconstruct in order to forge a valid confidential spend under different levels of quantum capability.

    The development fund remains exceptional even before that question is fully resolved, because the attacker does not have to spend scarce quantum resources discovering where the valuable target is.

    Zarcanum still raises the cost

    The development fund does not lose every benefit of Zarcanum.

    Its balance may be distributed among multiple outputs. An attacker might need several successful quantum computations rather than one. Outputs may also be consumed and recreated through transactions or staking, forcing the attacker to follow their current descendants.

    The confidential transaction structure may impose additional cryptographic work beyond the recovery of a single scalar.

    These factors could make an attack difficult and expensive. But they do not restore the economic uncertainty enjoyed by an ordinary private wallet. The fund remains a known, measurable and strategically concentrated target.

    Classical multisignature is not a complete answer

    A conventional elliptic-curve multisignature structure could improve governance and increase the number of classical keys an attacker must compromise.

    For example, an (m)-of-(n) arrangement might require several independent Shor computations. That could be useful as a temporary cost multiplier during the earliest quantum phase.

    But it would not change the underlying security assumption:

    [
    \text{several vulnerable classical keys}
    \neq
    \text{post-quantum custody}
    ]

    Classical multisignature can increase attack cost. It cannot provide durable protection once the relevant elliptic-curve system becomes routinely breakable.

    The solution should not be specific to the fund

    Protecting the development fund does not justify creating a special consensus exception for one wallet.

    A fund-only post-quantum rule would introduce special-case logic, increase protocol complexity and leave ordinary users unprotected. It would also duplicate work that the network would later have to perform for everyone else.

    The correct architecture is:

    [
    \text{general-purpose hybrid custody}
    \longrightarrow
    \text{development fund among the first migrations}
    \longrightarrow
    \text{wider ecosystem migration}
    ]

    The difficult work is general in nature:

    • defining a versioned hybrid output format;
    • associating an independent post-quantum authorization with each output;
    • requiring both classical and post-quantum authorization during the hybrid period;
    • defining the corresponding input and transaction formats;
    • integrating the new authorization with confidential amounts and assets;
    • validating it under consensus;
    • updating wallets and recovery procedures;
    • supporting migration from existing ZC outputs;
    • and eventually retiring exclusively classical authorization paths.

    This work would make hybrid custody available to every user. The development fund should be prioritised as an early migration target, not given a separate cryptographic mechanism.

    Why the fund should migrate first

    Once a general hybrid format exists, the development fund should be among the first major balances moved into it.

    That order would be justified because:

    1. It is highly identifiable.
      The fund lacks much of the economic fog that protects ordinary private wallets.

    2. It is strategically essential.
      Its resources may be needed to finance the rest of the transition.

    3. Its migration can be publicly verified.
      The community can confirm that the fund remains present and auditable.

    4. It provides a high-value operational test.
      The migration would exercise the new format, wallet tooling, backup procedures and auditability model under real conditions.

    5. It creates a reference procedure.
      Exchanges, bridges, custodians and large holders could learn from the fund’s migration.

    This does not mean that the hybrid format should initially be restricted to the fund. Once activated by consensus, it should be available generally. The distinction is one of migration priority and operational sequencing.

    Auditability must be preserved

    The solution should not require sacrificing the transparency of the fund.

    Auditability and spending authorization are separate properties:

    • the audit mechanism determines who can observe the wallet;
    • the authorization mechanism determines who can spend from it.

    A hybrid auditable wallet should therefore preserve:

    • a publicly verifiable live balance;
    • a reconstructible transaction history;
    • a public tracking mechanism;
    • and community accountability;

    while replacing exclusively elliptic-curve spending authority with a hybrid requirement such as:

    [
    \text{classical authorization}
    \land
    \text{independent post-quantum authorization}
    ]

    The precise post-quantum scheme and its integration with Zano’s privacy model require careful design and audit. But there is no architectural reason why stronger spending authorization must make the fund less transparent.

    What HF7 could do even without complete hybrid custody

    If a production-ready hybrid scheme cannot be completed in HF7, HF7 could still reduce future migration time by introducing or reserving the necessary crypto-agility.

    Useful preparatory work could include:

    • versioned output and input formats;
    • extensible authorization fields;
    • domain-separated transaction hashing;
    • consensus rules able to recognise future hybrid output classes;
    • wallet metadata for post-quantum public keys;
    • a defined migration path for auditable wallets;
    • and explicit rules for the eventual retirement of classical-only outputs.

    This would not protect the fund by itself. But it could prevent the project from having to redesign transaction structure under emergency conditions.

    Zarcanum’s passive resistance may buy time. That time is most valuable when used to prepare a migration before the first public demonstration of a cryptographically relevant quantum attack.

    Conclusion

    Zarcanum may give Zano a meaningful strategic advantage during the initial quantum period.

    An attacker with limited Shor capacity would find it difficult to identify and value the outputs of ordinary private users. Hidden amounts, hidden asset types, unlinkable outputs and private staking create an economic fog that may direct early quantum resources toward easier and more valuable targets on other chains.

    The development fund is an important exception.

    Its public tracking seed and real-time balance remove much of the uncertainty that protects normal Zarcanum wallets. It is a large, identifiable and strategically critical reserve. Its theft could both reward the attacker and weaken Zano’s ability to complete its post-quantum transition.

    The appropriate response is not a fund-specific cryptographic exception.

    It is to develop a general-purpose hybrid custody architecture for Zano, preserve auditability within that architecture, and make the development fund one of the first major balances migrated to it.

    Zarcanum’s passive quantum resistance may buy Zano valuable time. Protecting the development fund should be one of the first operational uses of the general hybrid custody capability developed during that time.

    Development

  • Introducing Zenith: Zano's move to pure Proof of Stake
    Y Yep

    @fbirde Thanks for clarifying. Since this thread is specifically about Zenith, your broader concerns about Proof of Stake are certainly relevant. I was the one who introduced the post-quantum dimension because Zenith itself will eventually need to operate under different cryptographic assumptions.

    Recent theoretical advances have substantially reduced the estimated quantum resources required to solve the elliptic-curve discrete-logarithm problem on comparable 256-bit curves. That does not mean that a practical attack exists today, but it does reduce the planning margin available for redesigning, reviewing, deploying and completing a protocol migration.

    There is also a broader and worthwhile question about which consensus model is better suited to the quantum era. My own view is that a private Proof-of-Stake system such as Zarcanum and Zenith may ultimately be better positioned than Proof of Work, provided that its ownership, authorisation and eligibility mechanisms are migrated in time.

    That comparison probably deserves a separate thread of its own. Ideally, HF7 should already introduce hybrid authorisation. At minimum, it should establish the transaction formats, wallet support and architectural boundaries required for an orderly post-quantum transition, rather than leaving Zano to improvise an emergency migration later.

    Announcements

  • Introducing Zenith: Zano's move to pure Proof of Stake
    Y Yep

    @fbirde If this was intended as a response to my comment, I should clarify that this is not primarily a question of balance privacy. The risk I described concerns ownership and custody: if the current elliptic-curve assumptions fail, an attacker may be able to recover or reproduce the witness material required to spend outputs or forge protocol proofs.

    PoW versus PoS is a separate consensus debate. Retaining PoW would not remove the need for an orderly post-quantum migration of Zano’s transaction and custody mechanisms.

    Announcements

  • Can Zano Complete a Post-Quantum Transition in Time?
    Y Yep

    @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.

    Development

  • Zarcanum’s Economic Fog: Why It May Slow the First Quantum Attacks — but Cannot Make Zano Quantum-Resistant
    Y Yep

    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.

    Development

  • Can Zano Complete a Post-Quantum Transition in Time?
    Y Yep

    Zano is approaching one of the most consequential periods in its history.

    The project is preparing Zenith, a transition from hybrid Proof of Work and Proof of Stake to a private pure Proof-of-Stake consensus. It is also developing new service-oriented capabilities, an execution sidechain, additional integrations and broader commercial infrastructure. At the same time, Zano must eventually confront a much deeper challenge: most of its private transaction and consensus architecture depends on elliptic-curve cryptography that would not survive a sufficiently capable quantum adversary.

    At first sight, three years appears to be an uncomfortably short period for a small team to address such a broad problem.

    That concern is justified. However, it does not necessarily follow that Zano cannot succeed.

    The decisive question is how success is defined.

    Zano probably cannot reproduce its complete present-day privacy architecture on post-quantum foundations, deploy it, review it and retire the classical domain within three years.

    But it may be entirely feasible for Zano to reach that period with its economically active funds protected, a credible migration mechanism operating, Zenith prepared for cryptographic replacement and the foundations of a native post-quantum private domain already under development.

    That distinction changes the outlook considerably.

    The transition is much larger than replacing a signature

    A common misunderstanding is that a blockchain becomes post-quantum by replacing its elliptic-curve signature with a standardized post-quantum signature.

    That might be approximately true for a simple public-account system in which one visible public key authorizes one transaction. It is not true for Zano.

    Zano’s private domain combines several interdependent mechanisms:

    • one-time output ownership;
    • unlinkable reception;
    • anonymous authorization;
    • key images for double-spend prevention;
    • confidential amount commitments;
    • range and balance proofs;
    • confidential asset identifiers;
    • asset issuance and burning relations;
    • private staking;
    • and public verification of all those properties.

    These are not isolated algorithms. They form a coherent cryptographic domain whose objects, witnesses and proofs share the same elliptic-curve environment.

    The forthcoming Zenith protocol preserves this integration. Its private eligibility construction relates control of a staking output, anonymous membership, an ephemeral key image, a confidential stake value, an eligibility threshold and a signature of knowledge. It uses elliptic-curve points, d/v-CLSAG, Schnorr-type proofs, commitments and range proofs.

    A post-quantum signature alone would therefore protect only one part of the system. It would not automatically provide:

    • post-quantum unlinkable addresses;
    • anonymous spending;
    • a post-quantum equivalent of key images;
    • confidential values;
    • confidential assets;
    • or private Proof-of-Stake eligibility.

    A complete transition means progressively replacing an entire cryptographic ecosystem.

    Three years is probably insufficient for full equivalence

    A native post-quantum version of Zano would need coherent replacements for several property groups.

    First, it would need quantum-safe custody: recovering an elliptic-curve output secret must no longer be sufficient to spend the corresponding funds.

    Second, it would need unlinkable post-quantum reception. A reusable address must still generate transaction-specific destinations without revealing that multiple outputs belong to the same recipient.

    Third, it would need anonymous authorization and a new double-spend identifier. The system must prove that one valid member of a set authorized a transaction without revealing which member, while still making repeated use detectable.

    Fourth, it would need post-quantum commitments and proof systems that preserve confidential values, conservation of funds, range correctness and confidential assets.

    Finally, Zenith would require a private post-quantum eligibility proof that composes ownership, hidden stake, threshold satisfaction, anonymous membership and unique slot participation.

    Each of these areas is a serious cryptographic research problem. Their secure composition is harder still.

    A small team should not be expected to design, implement, formally analyse, optimize, independently review and deploy the entire structure within a short emergency schedule. Attempting to do so could create a larger security risk than proceeding in carefully separated stages.

    But full completion is not the only meaningful deadline

    The most important insight is that Zano does not need to finish everything before it can substantially reduce its exposure.

    A successful first phase can concentrate on custody.

    Every conventional private output publishes a one-time public key of the form:

    P = xG
    

    where x is the secret that ultimately controls the output.

    If elliptic-curve discrete logarithms became tractable, an adversary could recover x from P. The fact that the user’s permanent address remains hidden would not protect the output itself.

    The fastest meaningful defence is therefore to introduce a new output type that also contains or commits to an independent post-quantum authorization credential. Spending would require both:

    classical authorization
    AND
    post-quantum authorization
    

    Even if the classical secret were recovered, the attacker would still be unable to spend the migrated output without the post-quantum private key.

    Such an output would not immediately reproduce every privacy property of the current ZC/Zarcanum domain. It could initially function as a quantum-safe custody destination while the more difficult private mechanisms are developed separately.

    That would radically improve Zano’s position.

    The project would no longer be attempting to complete an entire post-quantum privacy system before a single meaningful protection existed. It would already possess a safe destination into which users, exchanges and custodians could migrate value.

    A realistic definition of success by 2029

    For planning purposes, success should not initially mean that every classical construction has disappeared.

    A credible success state would contain several elements.

    Protected custody

    The network supports hybrid or native post-quantum custody outputs, and the principal wallets can create, back up, restore and spend them.

    Operational migration

    Users can move existing funds into protected outputs through a well-tested process. Exchanges, custodians and other major services support that migration.

    Substantial economic adoption

    A large proportion of economically active value has moved, even if dormant outputs and abandoned wallets remain on the classical side.

    Explicit cryptographic versioning

    Transaction and staking formats identify the cryptographic domain to which they belong. Classical, hybrid and future native post-quantum objects can coexist under controlled rules.

    A replaceable Zenith eligibility layer

    Epochs, slots, randomness, snapshots, chain selection and confirmation rules are separated as clearly as possible from the particular proof system used to demonstrate private eligibility.

    Advanced private-domain prototypes

    Post-quantum reception, anonymous authorization, nullification and confidential-value mechanisms are undergoing test-network evaluation and external review, even if they are not yet mature enough for universal mainnet use.

    A retirement policy

    The protocol has defined the conditions under which classical-only outputs will stop being created, lose staking eligibility or eventually cease to be accepted.

    This outcome would not complete the transition, but it would prevent the project from reaching the threat period with no defence and no migration path.

    Artificial intelligence changes the feasibility calculation

    Artificial intelligence cannot solve the cryptographic research problem by itself. It can, however, significantly improve the effective capacity of a small, technically strong team.

    The most immediate benefit lies in understanding and modifying a large, tightly coupled codebase.

    AI-assisted engineering can help identify every place where elliptic-curve points, scalars, key images, commitments and domain-specific proofs cross subsystem boundaries. It can compare the Legacy, ZC, Gateway and Zenith paths; generate dependency maps; identify serialization assumptions; trace wallet ownership derivation; and detect where cryptographic representations are embedded in higher-level logic.

    That work is laborious but unusually suitable for automated assistance.

    AI can also help produce:

    • unit and regression tests;
    • malformed transaction corpora;
    • migration test cases;
    • differential tests between classical and hybrid formats;
    • protocol documentation;
    • interface specifications;
    • property-to-mechanism matrices;
    • benchmark harnesses;
    • wallet recovery tests;
    • and static analysis rules for detecting unsafe object handling.

    This could allow the core developers to spend less time on repetitive implementation work and more time on architectural and cryptographic decisions.

    Planning may benefit as much as programming

    The post-quantum programme is not only a programming project. It is a dependency-management problem.

    A useful planning system must continuously relate:

    architectural property
        ↓
    protocol object
        ↓
    cryptographic mechanism
        ↓
    mathematical assumption
        ↓
    wallet, node and consensus dependency
    

    AI systems can assist in maintaining this map as specifications and implementations evolve.

    They can help identify when a proposed shortcut protects custody but breaks recovery, when a new proof requires an incompatible output format, or when a Zenith modification silently assumes that a classical key image will remain permanent.

    They can also compare competing migration sequences, generate adversarial scenarios and detect contradictions between white papers, implementation notes, wallet behaviour and activation rules.

    For a small team, reducing this organisational burden may be almost as important as accelerating code production.

    AI is an accelerator, not a security authority

    There is nevertheless a strict boundary.

    Artificial intelligence may generate plausible cryptographic reasoning that contains a subtle but fatal error. It may reproduce an incorrect assumption consistently across code, tests and documentation. It may produce an implementation that passes ordinary tests while violating a security property that was never encoded.

    This matters especially in Zano because the mechanisms are compositional.

    A proof may be individually sound while failing to bind the correct output, commitment, nullifier or eligibility statement. A migration transaction may protect authorization while introducing an inflation path. A new nullifier may prevent ordinary double spending while allowing duplicate participation across epochs. A post-quantum commitment may conceal values but fail to provide the binding property required by public conservation.

    AI can help explore and implement these systems. It cannot provide the final basis for trusting them.

    Human cryptographers and independent reviewers remain necessary for:

    • formal security definitions;
    • threat modelling;
    • proof analysis;
    • compositional soundness;
    • implementation review;
    • side-channel evaluation;
    • consensus analysis;
    • and final activation decisions.

    The central bottleneck may therefore shift. Producing code and prototypes can become much faster, while obtaining sufficient confidence remains slow.

    Zano’s historical strengths matter

    Zano is not beginning from an architecturally static system.

    The project has already demonstrated the ability to introduce major cross-layer changes while preserving chain continuity and protocol identity.

    The transition from legacy CryptoNote-style objects to the ZC/Zarcanum domain showed that a new cryptographic generation can coexist with an older one during migration. HF6 demonstrates a different pattern: the addition of a specialized Gateway domain alongside the principal private domain.

    These precedents do not prove that post-quantum cryptography can be inserted automatically. Zano does not currently possess transparent, plug-and-play cryptographic interchangeability.

    They do show that the protocol can support:

    • versioned object types;
    • domain-specific validation;
    • coexistence of formats;
    • hard-fork activation;
    • historical compatibility;
    • and progressive migration.

    That is precisely the architectural foundation needed for a staged transition.

    Zano’s strongest advantage may not be the size of its team, but the depth with which that team understands its own protocol and its demonstrated willingness to redesign core mechanisms rather than preserve obsolete structures indefinitely.

    The greatest danger is not technical impossibility

    The greatest danger is programme overload.

    Zenith, the Execution Layer, wallet improvements, integrations, commercial expansion and post-quantum migration all draw on overlapping resources:

    • core protocol developers;
    • wallet engineers;
    • test infrastructure;
    • release management;
    • exchange coordination;
    • cryptographic reviewers;
    • and the small number of people who understand the deepest invariants of the system.

    Artificial intelligence can increase productivity, but it cannot allow the same senior engineer to approve several security-critical architectures simultaneously. Nor can it create an unlimited supply of qualified external reviewers.

    If the project attempts to advance every major initiative at equal priority, post-quantum work may remain permanently important but never urgent enough to displace more visible short-term features.

    That would be the most dangerous outcome: not an explicit rejection of the problem, but a gradual delay until migration must be improvised under pressure.

    Conditions under which success is realistic

    Zano’s prospects become considerably stronger if several conditions are met.

    First, post-quantum custody and Zenith’s future replaceability must become explicit base-layer priorities rather than background research topics.

    Second, development should be separated by responsibility. Work that does not require the core consensus and cryptographic team should be assigned to genuinely independent contributors wherever possible.

    Third, AI-assisted development should operate within a disciplined process:

    • specifications before implementation;
    • explicit security properties;
    • automated test generation;
    • reproducible benchmarks;
    • traceable changes;
    • mandatory human review;
    • and independent validation for security-critical components.

    Fourth, the team should establish continuing relationships with external cryptographers rather than commissioning only a final audit after design decisions have become expensive to change.

    Fifth, the transition should be judged by staged security outcomes. Custody protection should not be delayed until complete privacy equivalence is available.

    Conclusion

    Zano can plausibly emerge successfully from the post-quantum transition, but only if success is defined in operational rather than symbolic terms.

    A realistic objective is not:

    Complete every post-quantum component before an arbitrary date.

    It is:

    Ensure that the network possesses a safe custody destination, a functioning migration path, replaceable consensus interfaces and an externally reviewed route toward full native post-quantum privacy before the classical assumptions become unsafe.

    Three years is probably too short for a small team to rebuild the entirety of Zano’s private cryptographic domain with complete maturity.

    It may be sufficient to protect the economically active system, establish the transition architecture and move the remaining research out of the realm of emergency.

    Artificial intelligence improves that prospect. It can accelerate code analysis, documentation, prototyping, testing and programme coordination. It can make a small team operate more like a larger engineering organization.

    But it cannot replace cryptographic maturity, independent review or careful sequencing.

    Zano’s success will therefore depend less on whether every technical problem can be solved immediately than on whether the project chooses the correct order:

    Protect custody first, preserve architectural optionality, develop native post-quantum privacy in stages, and refuse to let parallel expansion consume the resources needed to secure the base layer.

    Under those conditions, the challenge remains enormous—but it is no longer implausible.

    Development

  • Majorana 2 and the Shrinking Quantum Cost of ECC-256: What It May Mean for Zano
    Y Yep

    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.

    1. 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.

    1. 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.

    1. 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.

    1. 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.

    1. 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.

    1. 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

    1. 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

    2. Microsoft Quantum, "Calculating resource estimates for cryptanalysis"
      https://quantum.microsoft.com/en-us/insights/blogs/resource-estimation/calculating-resource-estimates-for-cryptanalysis

    3. Babbush et al., "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations," arXiv:2603.28846
      https://arxiv.org/abs/2603.28846

    4. Luo et al., "Quantum Algorithm for Elliptic Curve Discrete Logarithms with Space-Efficient Point Addition," arXiv:2607.13816
      https://arxiv.org/abs/2607.13816

    Development

  • What else would you like to see on the Zano roadmap?
    Y Yep

    The updated roadmap is ambitious, and the Zano Execution Layer could eventually add substantial utility to the ecosystem. My concern is not its potential value, but the order of priorities.

    The published roadmap does not yet appear to reflect the recent change in the post-quantum planning environment. Following Majorana 2, Microsoft now aims to achieve a scalable quantum computer by 2029. Separately, Executive Order 14412 has made post-quantum migration a current United States engineering programme, with a federal pilot due by the end of 2027 and migration deadlines for high-value and high-impact systems in 2030 and 2031.

    None of those dates proves that Ed25519 will be broken in 2029, 2030 or 2031. They do, however, show that waiting for a demonstrated cryptographically relevant quantum computer before beginning architectural preparation would be an unsafe strategy.

    Zano also has a specific custody exposure that should be distinguished from address privacy. Each unspent output publishes a one-time public key P = xG. The permanent wallet address may remain hidden, but if elliptic-curve discrete logarithms became tractable, the corresponding one-time spending secret x could be recovered directly from the output. Zenith's shorter block times and faster confirmations do not remove that exposure.

    I therefore believe that post-quantum custody and migration should become a core roadmap priority, particularly while HF7 and Zenith are still being prepared. The first objective need not be a complete post-quantum reconstruction of Zarcanum and Zenith. It should be a protected custody destination, probably beginning with a hybrid output requiring both classical and post-quantum authorization, together with wallet migration, backup and recovery support.

    This may require postponing lower-priority expansion work where it competes for the same core developers, wallet engineers, cryptographic reviewers, testing capacity or hard-fork coordination. The Execution Layer is the clearest example: it may be valuable later, but it does not protect existing Zano outputs or prepare the base layer for cryptographic migration.

    Projects developed by genuinely independent teams would not necessarily need to stop. The point is that base-layer custody and migration should take precedence wherever resources overlap.

    This is not an argument against Zenith. On the contrary, Zenith may be the best opportunity to introduce the versioning, migration paths and architectural separation required for an orderly post-quantum transition.

    General Discussions

  • Introducing Zenith: Zano's move to pure Proof of Stake
    Y Yep

    Zenith looks like a major improvement for Zano, particularly in confirmation speed, removal of the PoW dependency and preservation of private staking.

    My main concern is whether HF7 is also being used as an opportunity to begin Zano's post-quantum preparation.

    Microsoft now targets a scalable quantum computer by 2029, while US Executive Order 14412 has already turned post-quantum migration into a current engineering programme. This does not mean that Ed25519 will necessarily be broken in 2029, but designing, reviewing, deploying and completing a blockchain migration takes years.

    Zano has a specific custody exposure: every unspent output publishes a one-time public key P = xG. The permanent wallet address may remain hidden, but if elliptic-curve discrete logarithms became tractable, the corresponding one-time spending secret x could be recovered directly from the output. Faster blocks and confirmations do not remove that exposure.

    I am not suggesting that a complete post-quantum version of Zarcanum and Zenith must be finished before HF7. A more realistic first step would be to use HF7 to introduce:

    • explicit cryptographic-domain versioning;
    • support for a hybrid custody output requiring both classical and post-quantum authorization;
    • wallet migration and backup foundations;
    • and a clearer separation between Zenith's consensus semantics and its current elliptic-curve eligibility proof.

    Zenith is not the problem. It may be the best opportunity to make an orderly cryptographic transition possible before it becomes an emergency.

    Announcements

  • Proposal: A Post-Quantum Readiness Track for Zano and Zenith
    Y 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
    Development
  • Login

  • Don't have an account? Register

  • Login or register to search.
Powered by NodeBB Contributors
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups