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