Security
On Zano, Block 3,833,001 Arrived 31 Days After Block 3,833,000
An emergency release rolled the privacy chain back to the last block before Hard Fork 6, activated a new fork at that same height, and switched Gateway Addresses off. The patch removes the feature. It does not fix the bug, which the team has not yet published, and it takes a month of everyone's transactions with it.
On Zano's block explorer, block 3,833,000 carries a timestamp of 15:50:53 UTC on August 26. The next block, 3,833,001, is stamped 06:13:36 UTC on September 27. Nothing sits between them. The 31 days, 14 hours and 22 minutes in the gap used to hold a month of the privacy coin's history, and as of this weekend they hold nothing at all.
That is what the project's emergency release, version 2.2.3.600, was built to do. Its notes say it "rolls back the blockchain to the height 3833000 (2026-08-26 15:50 UTC)" and that "all transaction in the previous chain after that point will no longer be part of the chain followed by this release." Zano's statement of September 27 gives the reason: a "serious issue involving Gateway Addresses" had "enabled unauthorized ZANO and fUSD to enter circulation," and the team's answer was to restart the chain "immediately prior to Hard Fork 6," the upgrade that introduced the feature.
A fork that starts where the last one started
The commit that does the work is titled "hf7 emregency activation and rollback," pushed September 26 at 18:48 UTC. It is short, and it does not touch the Gateway Address code at all. Instead it defines a seventh hard fork and sets its activation height to 3,833,000, the same number already assigned to Hard Fork 6. On the recovered chain, HF6's rules governed no blocks. HF7 took over at the exact block where HF6 would have begun.
The substance of HF7 is a table. Zano's consensus code keeps a grid of which transaction components are permitted under each fork, and the commit adds a column. In the HF6 column, six gateway-specific entries, the input and output types, the signature, the balance proof, the ownership proof and the descriptor operation, are all marked allowed. In the HF7 column every one of them reads "no." The release notes describe this as "temporarily disabling gateway addresses." The June release that introduced the feature had described gateway addresses as "a new address type carrying asset transfers in the clear," with public asset identifiers and amounts on-chain, built so exchanges and services could hold a single readable balance instead of Zano's usual confidential outputs.
The same commit adds a startup check. When a node loads its database it now inspects block 3,833,001, and if that block does not carry the HF7 marker, the node truncates its own copy of the chain back to 3,833,000. In one truncation path the transactions being removed are, by a new flag, no longer returned to the memory pool. Whether a given node ever ran that code is a separate question: the release also moves the database to a new folder version, deletes the old one, and ships a fresh snapshot ending at the rollback height, so an upgraded node may simply have resynced from that.
Who chose
Zano's first notice, on September 25 at 22:29 UTC, said the upgrade "requires majority consensus to activate" and asked node operators, pools and exchanges to be ready. Quinten van Welzen, the project's head of marketing and growth, made the same point two days later, at more length: "The team can't roll back Zano. What it can do is publish new source code and ask the majority of the network to run it." He then conceded the obvious. "In practice, a few large players like the major mining pools carry a lot of weight in that decision, and that's a fair point to raise."
The explorer agrees. Block 3,833,001 on the recovered chain carries a WoolyPooly pool tag in its miner text, and its timestamp, 06:13 UTC on September 27, is 95 minutes earlier than the release's publication on GitHub at 07:48. Block timestamps are set by the producer, and binaries may have circulated before the release page went up, so the ordering is not proof of anything except that at least one pool had the code first. By 21:14 UTC on September 29 the new chain stood at height 3,837,732, which is 4,732 blocks in about 63 hours.
Van Welzen also acknowledged the project's early messaging. "Our first messages were rushed," he wrote. "We said '24 hours' and 'no other choice' before we fully understood what had happened." He told Cointelegraph the quantity of unauthorized assets "was considerable." Neither he nor the project has published a figure.
Timeline, from Zano's own records
| When (UTC) | What | Source |
|---|---|---|
| Aug 26, 15:50 | Block 3,833,000; Hard Fork 6 activates on the next block | Explorer, release notes |
| Sep 20 | v2.2.2.513 ships gateway hardening and an HF6 proof fix | Release notes |
| Sep 25, 22:29 | First public notice of a Gateway Address vulnerability | Zano on X |
| Sep 26, 18:48 | Commit "hf7 emregency activation and rollback" | GitHub |
| Sep 27, 06:13 | Block 3,833,001 produced on the recovered chain | Explorer |
| Sep 27, 07:48 | v2.2.3.600 published on GitHub | GitHub |
| Sep 27, 08:56 | Zano announces the restart | Zano on X |
| Sep 29, 21:14 | Recovered chain at height 3,837,732 | Explorer |
Seven days earlier, a hardening release
Hard Fork 6 was not rushed out. The height was fixed in a June 27 release, a July 22 release carried what it called "important security improvements for the upcoming hard fork 6," including consensus-enforced limits on gateway descriptors, and Zano's August update reported that "Block 3,833,000 passed on August 26 and the network upgraded on schedule." The feature was the point of the fork. A September 22 post explained why: tier-one exchanges decline privacy coins, so gateway addresses were meant to open a path to THORChain and NEAR Intents vaults and to an EVM bridge, with registration "gated by a 100 ZANO fee that gets burned."
Two days before that post, version 2.2.2.513 shipped with two gateway items in its changelog: a fix for "an HF6-specific issue" in the asset surjection proof "when a gateway output precedes a confidential (ZC) one," and a change to "validate gateway transactions before signing and relay (gateway hardening)." The Desk cannot tell from the notes whether either relates to the flaw that was exploited, and Zano has not said. The project's September 28 update promises a post-mortem "including an analysis of the Gateway Address code so that we can say with confidence what was affected and what was not," to be published "once that analysis is complete." Van Welzen's own account is that "a bug made it into Hard Fork 6 and went unnoticed for weeks."
What the month contained
Zano's September 29 post on recovery sorts the erased month into categories. Exchange withdrawals made between August 26 and September 27 are "back in the exchange's wallet on the updated chain," to be replayed when each exchange reopens. Deposits to exchanges in that window are to be covered by the team working "directly with each exchange." Payments between individuals "are back with the sender," and for cases that cannot be resolved that way "a process for individual users will follow." Frozen MEXC accounts "with no link to invalid transactions" are being worked through with the exchange, which crypto.news reported had suspended ZANO and fUSD deposits and withdrawals at the project's request. The money for all of it, the post says, comes from "the dev fund, team members' personal funds, and contributors who have committed support," with supply and emission unchanged.
The rollback cannot reach the other side of any trade. The September 27 statement notes it "cannot affect payments already settled in USDT, DAI, or other assets on separate networks." Someone who sold ZANO for a stablecoin during the month keeps the stablecoin; on the recovered chain the ZANO is back with them too, and the buyer has nothing. Van Welzen called that "genuinely complex," a month of payments "each depending on the one before it," and said he did not yet have all the answers on how the process would work.
Not everyone could get on the new chain immediately. A GitHub issue titled "Latest zano releases not working any more on ubuntu," reporting the Linux build crashing on launch, remained open as of this writing, and follow-up commits on September 27 added a check that turns away wallets still syncing in the old mode.
The Take
Zano's defense of the rollback is that immutability protects transactions made within the rules, and coins minted by a bug were not. That is a coherent position, and Ethereum made a version of it in 2016. But the honest cost is in the explorer, not the argument: 31 days of legitimate transactions, every one made within the rules, are gone alongside the illegitimate ones, because the fix chosen was not to correct the ledger but to abandon it. The pending post-mortem is where the claim that nothing else was possible gets tested, and two things belong in it. First, the actual defect, since the release that "fixed" the problem contains no fix, only a switch. Second, an account of the September 20 hardening release, which touched gateway validation a week before the emergency. If those changes were unrelated, say so; if they answered something already noticed, "unnoticed for weeks" needs revising. And the explorer shows a pool producing the first block before the release page existed. That is how proof-of-work chains actually decide. It is worth writing down before the next one.