September 2, 2026 Zilliqa Hard Fork: Where will your ZIL go during the migration?

If you hold ZIL on a cryptocurrency exchange and have been unable to recharge or withdraw money for weeks, September 2, 2026 will be the day that will change.

At that time, at block height 34,844,968 (expected at 12:58 UTC), Zilliqa will perform a hard fork to transfer ZIL balances from ten exchanges from old wallets to new addresses. Relevant trading platforms will subsequently reopen the recharge and withdrawal functions. You don't need to operate it yourself.

If you store ZIL in your own wallet on the old network, you will face another, larger process, and there is no specific date: every holder on the old network (including users who have never experienced asset theft) will subsequently need to migrate. Neither event was a planned upgrade and the root cause can be traced to signature flaws in the Zilliqa Ledger application. According to Zilliqa's own statistics, this defect resulted in the transfer of a total of 683,130,969.66 ZIL out of 6,772 accounts.

This article will distinguish between two levels: what actually occurred on September 2, and issues that remain unresolved since then.

What is a hard fork? What will happen to Zilliqa on September 2, 2026?

A hard fork is a change to blockchain rules that can lead to incompatibility between old and new software: starting from a specific block, only the new rules apply, and those who do not follow will not be able to connect to the network. It is triggered by the height of the block (i.e., the sequence number of the most recently written block) rather than by the clock time. Any time estimates associated with it are only predictions.

The fork itself changes little to the agreement, and its task is to transfer assets. The ZIL holdings stored by ten centralized exchanges for their customers in old Schnorr signature-based wallets will be written to the new wallet address on the Zilliqa EVM network. Each exchange needs to provide and confirm these target addresses in advance. Schnorr signature is a signature scheme of the old Zilliqa network that was used to prove that transactions indeed came from the account holder.

A background need to be understood: this fork is an administrative measure on exchange balances, not a network upgrade that brings new features, nor is it the recovery of stolen funds. We used the BNB Pasteur hard fork as a list to explain how regular and planned hard forks can be unfolded and what holders, traders and principals need to consider. The difference in the Zilliqa case lies in the cause, not the mechanism itself.

What is Zilliqa? Why does the Internet have two "faces"?

Zilliqa is a first-level blockchain with an independent consensus mechanism and native tokens. Its technical selling point is sharding. Sharping means that the network groups nodes to process transactions in parallel, rather than each node verifying all transactions, which improves throughput but also makes the protocol more complex. ZIL is a native token to the network and is used to pay for transaction fees.

During the rebuild to Zilliqa 2.0, the project added EVM compatibility and has since run the two environments in parallel. This transformation began before the event, which accelerated the process and made it irreversible: the main network (i.e., the main network in the production environment, unlike the test network) will in the future consist of only the EVM part, and the old network will be shut down rather than repaired.

Why was your ZIL stuck on the exchange for weeks?

On July 20, 2026, Zilliqa suspended all transactions on the old network. After that, neither your balance nor the attacker's assets can be moved on the old network. This is the reason why the exchange suspended ZIL replenishment and withdrawal-the trading platform is no longer technically able to operate on the old network.

Defect exists in eight bytes

Each Schnorr signature consumes a nonce, a random number that must be used once and never reused. The Zilliqa Ledger app correctly generated the random number, but an error occurred while copying it to the signature buffer: the app retained eight bytes of zero-padding but discarded eight bytes of true random number, causing the upper 64 bits of each random number to be fixed to zero.

Zilliqa's post-mortem analysis report accurately describes the consequences: each signature generated in this way will reveal about 64 bits of private key information, and from four or more signatures from the same account, the private key can be rebuilt in seconds on ordinary hardware. This can be done by using data that is already publicly stored on the blockchain, without deceiving anyone, hacking equipment, or stealing recovery phrases-the information is leaked through the transaction itself.

Who wrote this application?

It is necessary to clarify the attribution here because it involves the Ledger brand. According to Zilliqa, the original implementation of the affected application came from Zilliqa itself, the flaws exist in all released versions, and the fixes were written by Zilliqa developers and submitted to Ledger as pull requests. Your recovery phrase has never been affected, and other blockchain assets on the same device are not at risk due to this breach. This flaw only affects a specific signature path and does not involve other links.

Statistics and why the lower limit

The confirmed loss is 683,130,969.66 ZIL, involving 66 transactions. 6,772 accounts were confirmed as exposed, of which 51 accounts were completely cleared. Zilliqa made it clear that both numbers are lower limits and are based on evidence rather than estimates. According to the same statistic, 73.9% of classifiable old addresses are structurally safe because they are never signed by the affected application.

The timeline explains why the vulnerability has not been discovered for a long time: the first confirmed theft occurred on March 4, 2026, and the exploit was reported by the KuCoin Exchange on July 19, 2026, when the exchange discovered an abnormal outflow of funds from one of its cold wallets. A day later, the old transaction was closed. There is a technical reason why no one has issued an alarm before: in this scheme, the check value is derived from the message, so many duplicate value searches routinely used by blockchain to detect signature flaws are invalid here.

The defect is not in the network, but in the signature created during the signing process.

Which ten exchanges were involved in the first hard forks?

According to the announcement of Zilliqa's team, the first batch of trading platforms forked on September 2 include:

KuCoin, Binance.US, MEXC, OKCoin, Bitvavo, Korbit, WhiteBit, Bitrue, CoinSpot, CoinSwitch.

For European readers, Bitvavo is the most relevant on the list because it serves the European market. If your trading platform is not on the list, it does not mean you are excluded. Zilliqa made it clear that this is the first batch and has not announced specific dates for other platforms so far.

What can you expect after the fork?

It is not a simple "switch" switch. The first batch of exchanges plan to resume the recharge function on Zilliqa EVM after completing their respective migration and integration tests. Zilliqa itself said that the timetables for each platform may differ. Please plan in days, not minutes, and check the status page of the platform you use instead of relying on universal dates.

Which "side" is your ZIL: the old version of Zilliqa or Zilliqa EVM?

The prerequisite for understanding the whole thing is to distinguish between the following two points. Zilliqa runs on two sides: the older version of Zilliqa is the older, EVM-incompatible side, with its own account, Schnorr signature, and Ledger application built for it;Zilliqa EVM (also known as Zilliqa 2.0) is the newer side, using the same execution environment as Ethereum. EVM stands for Ethereum virtual machine and is the standard runtime environment for smart contract execution. EVM-compatible chains can directly accept Ethereum's contract and address formats. The difference is reflected in the address format: the old Zilliqa address starts with zi1 , and the EVM address starts with 0x.

This incident only affects old networks. Only users who are active on Zilliqa EVM are not affected. The same is true for pledged ZIL: if the pledge is on the EVM side, it will operate normally; if the pledge is in the old pledge contract, it will be suspended like all other assets on the old network, and will need to be processed through the recovery path. By the way, it is not only ZIL transfers that are affected, but also all types of transactions, such as transfers of ZRC-2 tokens. ZRC-2 is the token standard for the old Zilliqa network and is roughly equivalent to Ethereum's ERC-20.

For you, this raises a practical question that needs to be answered before September 2: Are your assets stored on an exchange, your software wallet or hardware device? Only the first situation can be solved through this fork. If this incident makes you rethink how to store assets in the future, you can compare different hardware wallets to see which standards are more suitable for you.

The term you will encounter on the official page

Zilliqa is communicated only in English, and the terms used on its status page are not always obvious in this context. The following checklist can help: Hard fork is a change in the above rules, Block height is the last serial number written to the block, Exchange balance is customer assets held by the trading platform, recharge and withdrawal are deposits and withdrawals. Old version refers to the old side of the network, and Recovery refers to the planned recovery procedure. accounts are also used in address checkers and post-mortem analysis reports to refer to personal wallets, and vulnerabilities are used to refer to the defect itself.

Are you affected? What can Zilliqa Address Checker do?

Starting from August 11, 2026, Zilliqa will provide an address checker. After entering the old Zilliqa address, the tool checks its public signature history for traces of vulnerabilities. There is no need to connect to a wallet and no requirement for mnemonics or private keys. According to the operator, only the address will be sent to the server for query and will not be stored.

If you have used the Zilliqa Ledger app to sign (regardless of the purpose: sending ZIL, transferring ZRC-2 tokens and NFT, or pledging), you may be affected by this. When signing in this way about four times, the risk becomes serious because it is now practical to rebuild the private key. The application version does not matter because all versions have this flaw.

According to the same statistics, you will not be affected if you meet any of the following conditions:

You have never used a Ledger device with Zilliqa; you have used a Ledger device but never run the Zilliqa app; you are only active on the EVM side; you are only signing through the software SDK (i.e. Zilliqa-js, gozliqa-sdk, or pyzil); you are pledging through Zilliqa's official pledge portal.

Why is "no abnormalities found" not "completely safe"?

Zilliqa himself points out this limitation, which should be included in every relevant note: signatures generated offline do not leave traces on the chain, so the checker cannot detect them. Therefore, a result of "no abnormalities found" only means that no exposure was found, not no exposure. Please regard the results as reminders rather than proof, and judge for yourself whether you have used the app.

The second and more disturbing issue is that exposure is permanent. Once on the chain, the signature cannot be revoked. Therefore, the repaired application can only protect the new key and has no effect on the signed key. The previously exposed accounts must eventually be scrapped and their assets transferred to a new address-this is the task of the migration tool that has yet to be completed.

The old side of the network is being retired, and Zilliqa EVM will become the only production side.

What can you do specifically before September 2?

The honest answer is: Not much, but this small thing is worth doing. There are currently four things you can do:

First, check your old address in the checker and record the results and dates. If the recovery process is initiated later, your notes will be more valuable than your memories. Second, identify where your assets are physically located, distinguishing between exchange balances and self-custody assets. Third, look up the status page of your trading platform and make sure it is on the first list. Fourth, don't use any tools that others privately give you.

Equally clear is what not to do: Don't try to move old assets through workarounds. This simply doesn't work during the suspension, and anything you are promised to do is not in your interest.

What couldn't the September 2 hard fork solve?

This fork allowed ten exchanges to resume operations. But since then, three larger issues remain unresolved, none of which have a clear date.

The first is the migration tool for self-custody users. As of August 11, 2026, the tool is undergoing an external security audit, and the audit report is expected to be completed in early September. Only after that does Zilliqa plan to announce a launch date. Second, there is the recovery process for affected account holders: The plan is to create a path for you to prove account ownership without revealing the mnemonic. Specific certification methods are still being formulated. Third, it is an updated token economics model, which aims to reflect the holdings of retired assets.

Zilliqa made it clear that this list does not attach any dates. As a reader, you should regard this neither as comfort nor as an alarm, but as it is: a pending matter. On September 2, the freezing status of some holders ended, while others were allowed to wait.

Why is the block height of 34,844,968 not a fixed date?

Deadlines related to block height change with network operation speed. So we took the measurement rather than directly adopting the number. On August 29, 2026, at 18:36 UTC, the eth_blockNumber method of the Zilliqa main network node was queried, and the block height was returned to 34,541,838. There are 303,130 blocks left to the target block of 34,844,968.

Based on Zilliqa 2.0 's block time of approximately one second, this is equivalent to approximately three and a half days. Starting from the measurement time, it falls exactly on September 2, 2026, the date of announcement. 12:58 World Standard Time is the most uncertain quantity in this calculation. A deviation of a few hours is normal, but a deviation of a few days will not.

In practice this means: If you don't see the release by the afternoon of September 2, don't worry. Only when the target block has passed and your exchange has remained silent for several days is it worthwhile to have a customer service consultation.

Why do fraudsters like this deadline?

Thousands of people are waiting for the date when funds will be released and are an excellent target for fraudsters. Zilliqa clearly warned on its status page that someone pretended to provide so-called recovery assistance, and gave two rules worth remembering: the team will never proactively contact anyone and will never ask for mnemons, private keys or recovery phrases.

This leads to a simple strategy for the next few weeks: Every recovery form, migration link, and tool sent to you privately should be considered malicious, even if it appears official or comes from a so-called moderator. Use only content announced through the project's official channels and check the page address in your browser before entering any information.

What issues does this case reveal with cryptocurrency exchange deadlines?

The Zilliqa case is rare in its cause, but its effect is extremely common: assets are stored with a third party, technical processes freeze them, and the holder learns about it last. You can see the same pattern in migration deadlines and trading suspensions for individual tokens (assets cannot be moved after the deadline). We have compiled common dates when exchange balances are under time pressure and summarized in a separate article.

This lesson is disturbing because it brings extra work. The balance on the exchange is a claim on the company, not an on-chain ownership. When everything is running normally, this difference is only theoretical. But in days like these, it becomes practical: Whether and when it can be restarted is up to the trading platform, not you. Therefore, those holding large amounts should disperse them into multiple paths, and when choosing an exchange, they should also pay attention to its location, regulatory conditions and communication performance in times of crisis, rather than just fees.

Checking the Zilliqa hard fork: What you need to remember

Confirm your ZIL storage location by September 1. If your trading platform is in the first batch, there is no need to operate, just wait for release. If not, be prepared to wait longer. Check your old address in the address checker and record the result and date. "No exceptions found" is not completely safe, but it is a documented starting point if the recovery process is subsequently launched. Do not migrate until the migration tool audit report is released. As long as there is no official launch date, any ready-made tool is a risk. Two main sources of information: the official Zilliqa event status page (with address checker and action plan), and reports on hard fork dates, block heights, and exchange lists.

(As of August 29, 2026. This article does not constitute investment advice. Price and fee structures may change; please confirm terms with your provider before purchasing.)