Binance backs Zilliqa EVM migration as legacy ZIL network is retired

Binance has moved to support Zilliqa’s EVM network for ZIL deposits and withdrawals as the blockchain retires its legacy transaction system following a security incident that exposed thousands of accounts.

Binance said ZIL will be migrated from legacy Zilliqa mainnet addresses to the Zilliqa EVM network at a 1:1 ratio, with the exchange handling the technical process for users who hold the token on its platform.

Deposits and withdrawals through the legacy Zilliqa network have remained suspended on Binance since Aug. 5 at 01:00 UTC. Once its migration is complete, the exchange will open ZIL deposits and withdrawals through Zilliqa EVM without issuing a separate announcement.

Legacy Zilliqa deposits and withdrawals will no longer be supported after the migration. Spot trading, margin trading, futures and Binance Earn products involving ZIL will remain available during the process.

The Binance move forms part of Zilliqa’s ongoing effort to migrate exchanges, custodians and individual holders away from its legacy Schnorr based transaction system after a flaw in the Zilliqa Ledger application left some private keys vulnerable.

Zilliqa migration follows Ledger signing flaw

The migration stems from a vulnerability in Zilliqa’s Ledger application that affected native, non EVM transactions signed using Ledger devices.

As crypto.news previously reported, the problem involved the way the application generated Schnorr signatures. Each signature requires a random secret number, known as a nonce, but the affected application incorrectly copied the generated data into the signing buffer.

Zilliqa’s Aug. 20 post mortem found that the error left the top 64 bits of each nonce fixed at zero, reducing the randomness needed to protect a private key. An attacker could use several public signatures from the same account to reconstruct its private key.

The defect had been present in every released version of the Zilliqa Ledger application between 2019 and 2026. Zilliqa said the first proven theft occurred on March 4, months before the problem was detected.

Activity picked up in July, and KuCoin notified Zilliqa on July 19 after finding unusual outgoing transactions from one of its cold wallets. Zilliqa disabled legacy transactions on July 20 before identifying the root cause the following day.

The project later confirmed at least 683.13 million ZIL had been stolen across 66 transactions. A total of 6,772 accounts were identified as exposed, while 51 accounts were drained. Zilliqa described both figures as minimum confirmed totals because further exposed accounts could still be identified.

Initial details were much more limited when ZIL transfers were suspended in July. At the time, Zilliqa disclosed that an exchange partner had suffered a cold wallet theft but had not identified the attack method or the amount involved.

Zilliqa EVM transactions were not affected by the vulnerability. The project said software wallets using its supported SDKs generated nonces correctly, while the recovery phrase stored on Ledger devices was not exposed.

ZIL balances are moving to EVM addresses

Fixing the Ledger application could prevent new weak signatures, but Zilliqa said it could not secure private keys that had already been exposed through signatures stored permanently onchain.

The project consequently chose to retire the legacy non EVM transaction system and move users to Zilliqa EVM. Legacy addresses are being retired as balances are reassigned at the protocol level to EVM addresses.

Exchange migrations have been carried out in batches because each participating platform must provide and verify its EVM wallet addresses before balances can be reassigned.

The first exchange migration hard fork took place on Sept. 2, moving balances held in legacy Schnorr based wallets to EVM addresses supplied by participating exchanges.

KuCoin, MEXC, OKCoin, Binance US, Bitvavo, Korbit, Indodax, Bitrue, WhiteBIT, CoinSpot and CoinSwitch were included in the first batch. Users holding ZIL on the participating exchanges were not required to take any action.

A second hard fork was scheduled for Sept. 22 and covered CoinEx, HTX, Bitkub, GOPAX, Coinone, OKX, LBank, Crypto.com, Gate, Paribu, CEX.IO and Bitget.

Bybit and Bithumb were expected to join a third migration hard fork, while Zilliqa said it remained in contact with other platforms as address mappings were collected and verified.

Binance had remained outside the earlier batches. Its latest announcement now confirms that the exchange will stop supporting the old network and move its ZIL deposit and withdrawal infrastructure to Zilliqa EVM.

Self custody holders have a separate ZIL migration route

Exchange customers are not the only holders affected by the retirement of legacy addresses.

Zilliqa has developed a zero knowledge proof based migration system for users who hold ZIL in their own legacy wallets. The system is designed to allow a holder to prove ownership of an old address and transfer the associated balance to an EVM address without giving Zilliqa a seed phrase or private key.

The audit of the ZKP migration tool has been completed, according to a September update from Zilliqa, with internal testing following the security review. Its rollout was targeted for Sept. 22 alongside activation of an escrow contract required for the migration process.

The project has warned users against attempting to move funds through exposed legacy keys. Once an attacker reconstructs a private key from old signatures, both the legitimate holder and attacker can sign transactions from the account.

Legacy transactions were therefore disabled for all holders, including accounts that were never exposed. Zilliqa said freezing the old transaction system prevented attackers with reconstructed keys from moving funds while the migration process was being prepared.

Balances linked to ZIL already stolen during the incident are being handled separately and are not automatically restored through the exchange migration hard forks.

Zilliqa has been working with exchanges and law enforcement to trace the stolen assets. Its post mortem said an exchange account used to liquidate part of the stolen funds had been identified and frozen, while the project was working with Singapore Police and a law firm on the recovery process.

The team has separately proposed a community vote on changes to ZIL tokenomics that could include minting tokens to compensate affected holders. Zilliqa said details covering eligibility, amounts and mechanics would be released with the governance proposal because any new issuance would change ZIL supply.

Zilliqa EVM becomes the network’s production environment

Zilliqa’s move toward EVM infrastructure began before the Ledger incident.

The blockchain transitioned to Zilliqa 2.0 in June 2025, bringing full Ethereum Virtual Machine compatibility alongside a proof of stake consensus system and changes to the network’s architecture.

Its six month testing period involved 21 external validators, with the proto mainnet processing 7.5 million blocks and completing 15 client upgrades before the transition.

Legacy transaction support continued after Zilliqa 2.0 went live, leaving the blockchain with both the older native transaction infrastructure and its EVM environment.

Zilliqa said the Ledger incident brought forward a decision it had already been considering to retire the old infrastructure completely. The project described the legacy stack as an increasing development and security liability and said Zilliqa EVM would become its sole production environment.

The security incident came after several earlier technical problems involving the blockchain, though Zilliqa has not linked those outages to the Ledger vulnerability. A January 2025 network outage was attributed to problems involving lookup nodes, while a separate bug in September 2024 had halted block production.

Zilliqa’s post mortem said the patch for the Ledger application was submitted on July 24 and merged by a Ledger engineer on July 27. The corrected version restores full nonce generation for new signatures, while private keys already exposed through earlier legacy signatures must be retired.