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

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

[Glassmeadow]

Thorchain one of the two"

[Yep]

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.

[tommycat]

I'm glad they managed to remove the unauthorised supply but what about sales inside Zano? Can't be traced so if they did those would that still work?

[Yep]

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

[tommycat]

@yep That's good to hear. I don't mind going through some pain and even potentially small loss but I'd rather burn the Z than have it end up with a scummy scammer.

[Yep]

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.