Zano Exploiter Used 36.9M Unauthorized ZANO Before Rollback

Zano has detailed the mechanics and scale of the exploit behind its Gateway Address vulnerability, explaining how an attacker minted millions of Zano tokens and additional stablecoin-like assets before the project ultimately chose to roll back roughly a month of blockchain history.

In a post-mortem published Thursday on X, the Zano team said the attacker used the vulnerability to create 36.9 million ZANO—along with Freedom Dollar (fUSD) tokens—before the network was rolled back to remove the unauthorized supply. The figures also clarify why the project warned that a rollback would be damaging to user trust while emphasizing that it was the only way to cleanly eliminate coins that could not be reliably distinguished from legitimate outputs.

Key takeaways

• The post-mortem attributes the exploit to Gateway Address misuse and describes two separate ZANO minting events of about 18.4 million ZANO each.


• Zano says the attacker also minted fUSD using the same method, with a portion of those tokens entering the Zano ecosystem.


• The project chose to roll back about a month of history because unauthorized coins appeared spendable and indistinguishable from normal outputs.


• Internal monitoring, audits, and bug bounties failed to detect the activity until after the second mint.


• Zano says recovery efforts are underway using a mix of a developer fund, team member contributions, and other committed resources, with execution largely routed through exchanges and payment services.

How the Gateway Address exploit worked

According to Zano’s post-mortem, the attacker first exploited the Gateway Address vulnerability on Aug. 29, minting approximately 18.4 million ZANO in a single transaction. The same approach was repeated on Sept. 25, generating another 18.4 million ZANO.

The team further said the attacker used the technique to mint fUSD as well, with some portion of those tokens flowing into the Zano ecosystem. Zano did not present a breakdown of exactly how much fUSD was minted or how many users were affected, but it did make the key point that the unauthorized coins were not “stuck” in an easily identifiable state.

“These coins functioned as authentic ZANO and could be spent normally,” the Zano team wrote in its post-mortem.

Why Zano rolled back part of its chain

The timing of the exploit—and the period during which it went undetected—helps explain Zano’s decision to reverse the chain. Zano stated that the first unauthorized 18.4 million ZANO mint was not noticed for nearly a month.

In the team’s account, the malicious outputs looked like ordinary transaction results. Internal teams flagged the activity only after the second mint, suggesting that the vulnerability did not trigger an obvious alarm condition at the time.

Zano acknowledged that a rollback would hurt trust because it disrupts legitimate transactions included in the reverted history. However, the project argued that it could not safely differentiate unauthorized mints from legitimate coins after the fact—meaning that simply letting the chain continue would leave persistent, spendable supply that the network could not cleanly isolate.

Exploit setup, entry fee, and testing window

Zano’s investigation also includes details about the attacker’s entry process. The post-mortem says the attacker paid a 100 ZANO fee to set up the exploit, which the team estimated to be about $553 at the time of publication.

Per Zano, the attacker registered a Gateway Address on Aug. 28, paid the registration fee, and then tested a fabricated asset before the first unauthorized mint occurred the next day on Aug. 29.

The team’s timeline implies an intentional sequence: establishing the Gateway Address, running tests to confirm the exploit behavior, then minting large amounts once the mechanism worked as intended.

What Zano says went wrong in detection—and what it’s doing next

Zano said multiple safeguards failed to catch the issue before it could be exploited at scale. In its post-mortem, the team stated that AI-assisted testing, internal audits, and bug bounty programs did not identify the vulnerability in time.

The disclosure comes alongside Zano’s ongoing recovery efforts. In a separate announcement shared on Wednesday, the project said it is working to restore affected balances using a combination of its developer fund, team members’ personal funds, and committed contributions.

According to Zano, recovery will primarily run through exchanges and payment services. The team also described how it will coordinate with exchanges to address the effects of the rollback: withdrawals that were reversed due to the chain reorganization would be replayed in a way that reflects the corrected state, while the team would credit affected deposits.

This approach matters for users because large-scale rollbacks can complicate custody and reconciliation. By routing the recovery through exchanges and payment processors, Zano is effectively trying to standardize how “what should have been credited” is reconstructed after the network state changes.

What investors and users should watch

For readers tracking the aftermath, the immediate question is whether Zano’s recovery process—particularly the exchange and payment-service replay and deposit-crediting plan—fully resolves the practical impact of the rollback without introducing new inconsistencies. Longer-term, the most important uncertainty is whether Zano can update its Gateway Address logic and validation so that future unauthorized mints cannot again appear indistinguishable from normal outputs.

https://www.cryptobreaking.com/zano-exploiter-used-36-9m/?utm_source=blogger%20&utm_medium=social_auto&utm_campaign=Zano%20Exploiter%20Used%2036.9M%20Unauthorized%20ZANO%20Before%20Rollback%20