Zano Forum

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!

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.

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

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