Reposted in full: the previous submission was inadvertently truncated when pasted into the forum. This version contains the complete article.

A Security Framework for Gateway v2 and Future Post-Quantum Migration

Version 1.2 — forum edition, 12 October 2026.

Abstract

The HF6 Gateway Address incident motivates a broader architectural security question: how should one protocol preserve shared properties across domains with different state representations and validation semantics?

The official emergency release documented an attack affecting native-coin and asset supply, a rollback, and temporary disabling of Gateway Addresses. This article uses that documented outcome as its starting point; it proposes a security framework rather than reconstructing the exploit or certifying a redesigned implementation.

A transaction may contain objects that are locally valid under the rules of each participating domain while still representing an invalid transformation between those domains.

This article proposes Cross-Domain Invariant Enforcement as an architectural security principle for Zano:

A cross-domain transition must establish the semantic correctness of the transition itself, not merely the local validity of its endpoints.

The principle is intended as a reusable engineering framework rather than as a post-mortem of HF6. Its immediate application is the redesign and audit of Gateway Addresses. Its longer-term application may become even more important if Zano's post-quantum migration requires coexistence between classical, transitional and native post-quantum domains.

The framework introduces three practical ideas: explicit cross-domain transition proof obligations, a permanent Protocol Invariant Registry, and a Boundary Completeness Rule requiring every new or modified domain to be reviewed together with all boundaries it creates or changes.

---

1. The architectural lesson from HF6

HF6 introduced Gateway Addresses as a specialized state model alongside Zano's principal confidential transaction domain.

The documented Gateway design uses account-style balances and exposes the amounts involved in Gateway transfers, while the principal private path uses confidential UTXO representations. Both belong to one base-layer ledger and asset environment, with different state and validation semantics. The Gateway documentation describes a design and API; its presence does not establish that the functionality is currently enabled. Gateway documentation

On 27 September 2026, emergency release v2.2.3.600 documented an attack affecting native-coin and asset supply. It rolled the chain back to height 3,833,000, corresponding to 26 August 2026 at 15:50 UTC, and temporarily disabled Gateway Addresses under emergency HF7. Release v2.2.3.603, published on 5 October, explicitly carried that rollback forward. Emergency release, subsequent release

The release announcement establishes the economic impact and emergency response. It does not, by itself, establish the exact algebraic exploit path. The architectural argument below therefore does not depend on a specific reconstruction of the missing check or on a claim that every local verifier was independently correct.

The architectural question is broader than the presence or absence of one implementation check:

What must validation establish so that a protocol-wide economic property remains true when value crosses between different representations of state?

This gives the central observation:

Valid_A ∧ Valid_B ⇏ Valid_(A→B)

Local correctness of Domain A and local correctness of Domain B do not, by themselves, establish correctness of the transformation connecting them.

The boundary is therefore a security surface in its own right.

---

2. Protocol domains and domain boundaries

For the purposes of this framework, a protocol domain is a portion of the ledger architecture characterized by a sufficiently distinct combination of state representation, transaction objects, authorization semantics, state-transition rules, validation procedures, privacy properties or cryptographic assumptions.

Domains do not need to be separate blockchains. A ledger or state domain defines how state is represented, updated and validated. A cryptographic domain is a coherent family of objects, proof relations and assumptions implementing a declared property set. These dimensions can overlap without being interchangeable: a new authorization mechanism need not create a new ledger model.

This distinction is particularly relevant to Zano because its domains can share:

chain + consensus + asset environment

while differing in:

state representation + authorization + validation semantics + privacy

A domain boundary exists wherever protocol logic must relate those different semantic systems.

A cross-domain transition is therefore any consensus-relevant operation whose validity depends on objects or state belonging to more than one protocol domain, or which transforms value, ownership, authority or state from one domain representation into another.

For example:

Gateway balance → confidential ZC outputs

is one economic transformation expressed through two different state models, when that operation is permitted. Its specification must identify the complete source and destination state and the relation between them.

---

3. Cross-domain invariants

A cross-domain invariant is a protocol property that must remain true over the combined state affected by a transition, independently of how each participating domain internally represents that property.

If I is such an invariant and T is an allowed transition,

I(S) ∧ Valid_T(S, S′) ⇒ I(S′)

Here, S and S′ denote the complete state relevant to the transition before and after acceptance. The statement is conditional on the declared rules and security assumptions.

The clearest example is monetary conservation.

The architectural responsibility is shared even where its realization differs: commitments and proofs in the private path, explicit amounts and directly tracked balances in account-style state.

For each asset a, a generic conservation relation can be expressed as:

V_consumed(a) + I_authorized(a)
    = V_created(a) + B_authorized(a) + F(a)

The accounting categories must be disjoint: created value excludes anything assigned to the fee term, and authorized burning excludes fee-related burning already counted there. Authorized issuance includes protocol emission where applicable. The equation does not assume that fees are transferred rather than burned, or require confidential quantities to become public.

Numerical conservation is insufficient without canonical asset correspondence and authorization of the complete transition. Consumption must not leave conflicting independently spendable representations of the same source value. A valid operation may split value among several destinations or combine several sources; uniqueness applies to consumption, not to the number of outputs.

The invariant belongs to the protocol, not to either individual domain.

---

4. The cross-domain transition proof obligation

The word proof must be used carefully. In the definition below, protocol invariants are the consensus-critical conditions applicable to the operation and its declared context. Broader properties, including privacy and operational recoverability, require additional evidence, as discussed in Section 8.

A cross-domain transition does not necessarily require one zero-knowledge proof or even one cryptographic proof object.

This article therefore uses the following definition:

A cross-domain transition proof obligation is the complete set of consensus-enforced conditions required to establish that a particular transition preserves every protocol invariant spanning the participating domains.

A proof obligation may be discharged through deterministic validation, cryptographic proofs, authorization checks, state lookups, type restrictions, sequencing rules, domain separation and other consensus logic.

The architectural question comes first:

What must consensus establish for this transformation to be valid?

Only afterwards should designers decide which cryptographic or deterministic mechanisms establish those facts.

This distinction prevents a dangerous reduction of the problem to questions such as:

Is the balance proof valid?

or:

Is the signature valid?

Those may both be true while the complete transition remains false.

---

5. Semantic completeness

This is perhaps the most important requirement.

A cryptographic proof may be perfectly sound while the protocol is economically unsound if the statement being proved fails to describe the complete economic transformation.

Therefore:

A sound proof of an incomplete statement does not produce a sound protocol.

Every economically meaningful degree of freedom available to a transaction constructor must either be fixed by protocol rules, explicitly authorized, or included in the relation validated by consensus.

This includes values that are mathematically well formed but semantically invalid.

Consider an asset representation encoded as an elliptic-curve point. Algebraic acceptability alone would not establish that it represents an asset the protocol is entitled to interpret in that context. This is a general review example, not a reconstruction of the HF6 exploit.

This gives a useful review rule:

Validation must establish protocol meaning, not merely mathematical well-formedness.

That principle applies well beyond elliptic-curve points. It applies to serialized objects, identifiers, commitment generators, nullifiers, domain tags, transaction versions and future post-quantum objects.

---

6. Privacy changes the assurance model

The incident also motivates examining how confidentiality changes the assurance available at a domain boundary.

In a transparent system, independent observers may sometimes reconstruct an economic inconsistency after the fact. A bridge, for example, may allow comparison between assets locked on one chain and assets issued on another.

Such auditing should never replace consensus validation, but it can provide an additional detection layer.

A confidential destination is different.

Where a destination conceals values and ownership relations, public observers may lack the information needed to reconstruct the full economic history of its outputs. Whether a particular incident remains traceable requires a separate analysis of the available evidence. The architectural requirement should not depend on an assumption that later tracing will recover that information.

The architectural requirement is that monetary correctness must not depend on later reconstruction that the privacy model does not make available.

Hence:

Consensus-critical transition invariants must be enforced before acceptance; external audit cannot substitute for that validation.

And more specifically:

Transparent and confidential destinations require complete transition validation. Confidentiality makes reliance on later economic reconstruction particularly unsuitable.

External monitoring remains useful as defence in depth for whatever quantities and events are observable. It should respect the declared privacy model and avoid unnecessary identifying metadata. It can detect evidence of a failed assumption or implementation defect; it cannot replace the relation that makes a transition valid.

---

7. Security controls for a domain boundary

A practical review should cover at least the following twelve control classes. This is an audit framework, not a claim that the list alone establishes security:

1. Domain and type identification. Every object must have one unambiguous protocol interpretation under a specific domain and version.

2. Complete semantic coverage. Every field capable of affecting value, assets, authorization, issuance, burning or state construction must participate in the validated relation.

3. Value conservation. Conservation must hold across the complete transition, not separately on each side.

4. Asset integrity. Source and destination representations must correspond through one canonical protocol relation. Unknown or unsupported asset representations should fail closed.

5. Authorization binding. Authorization must cover the specific source state, destination state and operation being performed, rather than merely authorize activity inside one domain.

6. State-consumption integrity. Conflicting consumption of the same source must be rejected in accepted canonical state, including conflicts between ordinary spending and migration. Multiple destinations are valid if the complete operation conserves value and is authorized.

7. Atomic state application. A same-chain value-migration transition must consume its source and create its destinations atomically. A staged design must explicitly account for intermediate value and authority. Reorganizations must revert the related changes consistently; a restored source may subsequently be consumed again under the canonical rules.

8. Domain and version binding. Parsing, state lookup, dispatch, proofs and authorization must agree on domain, operation and version. Review must include activation boundaries and reorganizations across rule contexts; cryptographic domain separation alone is insufficient.

9. Replay and downgrade resistance. Reject replay against already consumed state and unintended reinterpretation under a different context. Retired permissions must not remain accidentally reachable. Review complete routes, including recovery and intermediate domains, for ways to restore weaker authority prohibited by policy.

10. Confidential-destination assurance. Discharge the complete economic relation before acceptance. Assess migration metadata and distinguish future confidentiality from concealment of previously exposed history.

11. Operational observability. Independent monitoring should track whatever public invariants, transition counts, issuance/burn activity and exceptional conditions remain observable.

12. Adversarial testing and resource accounting. Test semantically hostile yet structurally valid objects, arithmetic boundaries, alternate encodings, unsupported assets, missing or extra outputs, conflicts and prohibited routes. Assess whole-operation and aggregate-block costs, including expensive rejected inputs; distinguish deterministic consensus limits from local admission policy.

The relevant adversarial question is:

Can an attacker choose a combination for which every individual check succeeds while the overall economic statement is false?

That question directly targets compositional failures.

---

8. Protocol Invariant Registry

To make these principles operational, Zano could maintain a Protocol Invariant Registry alongside its architectural specifications.

This need not be a consensus object or a new source of protocol authority. It would be a specification and review record connecting each property to its scope, assumptions, permitted exceptions, enforcement points and supporting evidence. Changes to declared properties require an explicit architectural decision.

For example:

Invariant / property	Scope	Enforcement / evidence
Monetary conservation	Global / all value domains	Consensus
Asset conservation and identity	Per asset / relevant domains	Consensus
Authorized issuance and burning	Asset-operation paths	Consensus
Single state consumption	Domain and cross-domain	Consensus
Gateway private-state consistency	Gateway boundary	Consensus
Migration uniqueness	Permitted migration routes	Consensus
No unauthorized downgrade	Transitional/PQ domains	Consensus
Declared privacy properties	Specified domains and transitions	Cryptographic analysis + metadata assessment
Recoverability	Supported credentials, wallets and domains	Recovery policy + operational evidence
Validation resource limits	Complete operations and blocks	Deterministic consensus limits; separate local policy

Each entry should identify applicable versions and the checks or evidence supporting it. Privacy depends on assumptions and observable metadata; recoverability also depends on credentials, backups and wallet support. Listing a property does not make it enforceable by one consensus predicate.

Every proposal introducing or modifying a transaction type, domain, migration path or lifecycle permission should identify the entries it affects and the evidence that must be updated.

This transforms an implicit expectation—

the new feature must not break monetary integrity

—into an explicit review obligation.

---

9. The Boundary Completeness Rule

A second practical principle follows directly:

A domain specification is incomplete until every new or modified boundary created by that domain has also been specified.

Introducing a domain therefore requires defining not only its local objects and validation rules, but also its permitted transitions to existing domains.

Likewise, modifying an existing domain requires re-evaluating every boundary whose correctness depends on the changed semantics.

This is particularly important during hard forks.

Versioning Domain A without reconsidering A → B may leave an old assumption embedded inside a transition whose endpoint semantics have changed.

A coherent cryptographic domain remains the principal unit of replacement. Its security-review scope includes every affected boundary, permitted direction, version and lifecycle restriction. Sequences through intermediate domains must also be reviewed: acceptable individual steps can compose into a prohibited downgrade or duplicate economic representation.

The unit of security review must therefore be:

domain + all affected boundaries

---

10. Application to Gateway v2

A redesigned Gateway would provide an immediate opportunity to apply the framework. Here, Gateway v2 names that prospective redesign; it does not imply a finalized specification, completed audit or deployed capability.

In a public forum statement, the Zano team said Gateway Addresses would stay disabled pending reassessment and audit, with third-party review among the stated goals. The same statement moved Zenith to HF8 because HF7 had been used for network recovery, gave no ETA, and declined to commit to a delivery order for Gateway v2, Zenith and ZEL. These are announced intentions, not evidence that the reviews or activations have occurred. Team statement

A Gateway v2 security specification should therefore describe not only Gateway-local rules but every permitted transformation between Gateway state and the private domain.

For each operation, the specification should identify the source and complete destination set; canonical asset correspondence and amount relations; authorization and fee/issuance/burn rules; consumption and atomicity; versions, activation and failure behavior; and the exact consensus checks discharging the obligation. Wallet construction, backup and recovery, storage, conflict detection and resource limits must support those semantics.

A particularly useful audit test would be:

Assume the adversary controls every field that protocol rules permit the transaction constructor to choose. Can any assignment satisfy all validators while violating the intended economic transition?

This is stronger than ordinary signature testing, balance-proof testing or happy-path transaction testing.

It asks whether the composition itself is secure.

---

11. Application to post-quantum migration

The same framework may become even more important in a post-quantum transition.

Zano's private architecture tightly integrates reception, ownership, anonymous authorization, state-consumption integrity, confidential amounts, assets and private staking. Replacing a conventional signature alone is therefore insufficient; different ledger or cryptographic domains may require different transition paths.

A possible directed migration topology is:

D_existing → D_transitional → D_successor

Each permitted edge has its own proof obligation. The illustration implies neither reverse routes nor a mandatory intermediate stage; a direct existing-to-successor route may also be specified. Hybrid authorization is a cryptographic policy, not necessarily a separate ledger domain.

Migration must prevent conflicting accepted consumption while preserving asset and value relations across the complete destination set. Ordinary spending and migration need compatible conflict detection. Return routes, recovery and withdrawal of obsolete authority require explicit policies; retaining historical parsing does not imply permission for new spending under retired rules.

Preventive migration also depends on trustworthy source authorization and economic state. If the relevant source assumptions have already failed, stronger destination authorization cannot retroactively establish legitimate ownership, quantity or asset identity. Emergency treatment requires a separately justified recovery basis; the framework promises no unconditional recovery path.

PQ spending authorization alone does not establish PQ protection of reception, confidential value, asset integrity, state consumption or consensus. Each stage must state its protected properties, remaining assumptions and permitted operations. Privacy changes must be deliberate: entering confidential state does not erase public history, migration linkage or metadata already exposed.

These properties should be specified before selecting the final post-quantum mechanisms.

That is one of the broader advantages of an invariant-oriented architecture: it separates what the protocol must preserve from how a particular generation of cryptography implements it.

---

12. Formal specification and testing

Cross-domain boundaries are attractive targets for formal methods because their central properties are relational.

A useful initial model could focus on Gateway state, private-state abstractions, the asset registry, consumption and permitted transition types. It could test or prove selected invariants under explicit assumptions. A model proof does not automatically verify the implementation, the cryptographic relations it abstracts or wallet behavior; those require separate evidence.

Formal verification of related cross-domain economic properties already exists. Marić, Scholz and Subotić formally verified a fail-safe cross-chain bridge by defining and proving invariants governing the equilibrium between the connected systems. drops.dagstuhl.de OmniLedger similarly required a dedicated atomic cross-shard protocol rather than assuming local shard validity was sufficient for cross-shard transactions. UCL Discovery Kim's 2026 preprint studies mechanized preservation of regulatory state across domains under an explicitly scoped model. It offers a further methodological analogy, not a security result for Zano or for confidential monetary transitions. Preprint, version 4

The proposed Zano principle is therefore not a claim that invariant preservation across domains is a newly discovered idea.

Its more specific contribution is to apply that reasoning to heterogeneous state domains within one privacy-oriented base-layer ledger, where limited observability makes dependence on later economic reconstruction particularly unsuitable.

---

13. Cross-Domain Invariant Enforcement

The principle can now be stated compactly:

Cross-Domain Invariant Enforcement

In a multi-domain ledger, every transition between domains with different state, authorization or validation semantics must explicitly preserve every applicable consensus invariant spanning those domains.

The local validity of the participating domains is necessary but not sufficient. Consensus must validate the semantic relation connecting their source and destination states.

Preservation must be established before acceptance. Confidentiality makes reliance on later economic reconstruction particularly unsuitable; transparent state does not remove the obligation.

Its operational corollary is:

A cross-domain proof obligation must cover the complete semantic transition, not merely demonstrate that its individual objects are locally valid.

---

Conclusion

The HF6 incident makes the responsibilities of a multidomain architecture especially concrete.

The lesson should not be that Zano should avoid specialized domains. Gateway Addresses address real integration requirements, and future post-quantum evolution may itself benefit from controlled coexistence between different cryptographic domains.

Multidomain architecture can therefore be an important source of evolutionary flexibility.

But modularity moves part of the security problem to the boundaries.

As domains become more explicit, their transitions must become equally explicit. Monetary conservation, asset integrity, authorization, state consumption and migration semantics should not remain emergent properties of interacting code paths. They should become named invariants with explicit enforcement points.

A future Gateway redesign is an immediate opportunity to apply this discipline before reactivation.

A future post-quantum migration may make it indispensable.

The objective is therefore not merely to ensure that every Zano domain is secure independently.

It is to ensure that:

every transformation between domains preserves the properties that make all of those domains one coherent protocol.

---

References

hyle-team/zano, v2.2.3.600 — Emergency release, 27 September 2026. Primary source for the documented supply incident, rollback and temporary Gateway disabling. Official release

hyle-team/zano, v2.2.3.603, 5 October 2026. Confirms continuation of the emergency rollback. Official release

Zano Docs, Gateway Addresses (GW) in Zano. Design and API reference; not an operational-enablement or audit attestation. Official documentation

GinoFPM, Zano Team, statement in Introducing Zenith: Zano's move to pure Proof of Stake. Source for the announced audit policy, revised fork numbering and absence of a committed delivery order. Specific forum post

E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta and B. Ford, OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding, IEEE Symposium on Security and Privacy, 2018, DOI 10.1109/SP.2018.000-5. UCL Discovery

F. Marić, B. Scholz and P. Subotić, Formal Verification of a Fail-Safe Cross-Chain Bridge, FMBC 2025, DOI 10.4230/OASIcs.FMBC.2025.8. drops.dagstuhl.de

Jinwook Kim (for the Oraclizer Core Team), The Cross-Domain State Preservation Functor: A Mechanized Theory of Regulatory State Synchronization in Isabelle/HOL, 2026 preprint, version 4, revised 23 August 2026. arXiv:2604.03844v4

When this thread started, Zenith was expected to be HF7, following HF6 and the introduction of Gateway Addresses.

Now that HF7 has instead become the emergency recovery fork and Gateway Addresses are temporarily disabled, could Zenith become the next hard fork, effectively HF8?

If Zenith is already sufficiently advanced, would there be advantages in deploying the new consensus first and then reintroducing Gateway Addresses v2 on top of it?

That would allow Gateway v2 to be designed, tested and audited directly against Zano's long-term pure-PoS consensus, rather than against the current hybrid model shortly before another major consensus change.

The obvious downside would be timing: if Zenith still requires substantial implementation and testing, this could delay Gateway v2, ZEL and the integrations that depend on them.

How is the team thinking about that trade-off at this point?

Looking back: we were watching the right thing, but asking the wrong question

After reading the post-mortem, I went back through this thread and the earlier thread about the first Gateway Address. There is an analytical mistake in our discussion that I think is worth acknowledging.

We were watching the right thing. From the first Gateway Address, we discussed following balance changes, deposits and withdrawals, additional registrations and, later, descriptor or metadata changes, asset movements and other on-chain activity.

But our attention was focused almost entirely on identifying legitimate adoption. In this thread we tried to determine who might be behind the first two Gateway Addresses and what services they represented. Even @Glassmeadow’s brief “Thorchain one of the two” reflected that same direction of inquiry.

We were essentially asking:

Who is using Gateway Addresses, and what are they building?

What we failed to ask was:

What would malicious or abnormal use of a Gateway Address look like?

This is especially striking when rereading @freedomsawp’s September 1 question about the first Gateway Address:

“Do we have any idea who registered this one and what they will be using it for?”

We now know that this was the Gateway Address used by the attacker.

I do not want to rewrite history. Nothing in that question, or in the mere registration of the address, demonstrated that an attack was taking place. I am not claiming that we could have identified the exploit from what we knew then.

But there is a methodological lesson here:

We identified the right object to watch and even described the right evidence to watch for, but we failed to interpret that evidence through an adversarial threat model.

We were watching Gateway for signs of adoption. We should also have been watching it for signs of abuse.

When the new version of Gateway Addresses goes live, I think we should go one step further: not only watch individual addresses and their activity, but also systematically monitor the protocol invariants that must always hold.

The exact invariants will depend on the redesigned Gateway mechanism. But the principle is already clear: do not only watch what Gateway users are doing; watch whether Gateway itself is behaving within its invariants.

That, for me, is the main lesson from rereading these threads.

@freedomswap Unfortunately, we do now.
You asked this on September 1. We did not know how to answer it at the time. We now know that this was the Gateway Address used by the attacker.
Looking back, your question was much more important than we realized then.

@tommycat Any transactions involving the unauthorized ZANO after the rollback point were also removed, including private transactions. They don't need to be traced individually — they simply no longer exist on the new canonical chain.

Unfortunately, the first Gateway Address documented in this post turned out to belong to the attacker.

Zano’s post-mortem identifies the exact same registration transaction (03edb09ab5d9ec759aa2c2b98b377499cdb136e6a222622c75445d095902c517) as the attacker’s Gateway registration on August 28. The first exploit followed on August 29, creating approximately 18.4 million unauthorized ZANO. The report then describes further activity involving that Gateway Address and two additional exploits on September 25, creating another 18.4 million ZANO and unauthorized fUSD through the same vulnerability.

What we initially interpreted as an encouraging sign of early adoption was, sadly, preparation for the attack. The report does not link the second Gateway registration documented here to the attacker.

On a more encouraging note, the team and participating network operators have removed the unauthorized supply from the recovered chain and disabled the vulnerable functionality. Although the rollback has real consequences for affected users and services, restoring supply integrity and publishing a detailed account of the incident are meaningful steps toward recovery.

New release v2.2.3.600 is online

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.

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

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

fUSD has massive potential.

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!

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.

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?

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

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

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.

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