If you hold ZIL on a crypto exchange and have been unable to deposit or withdraw for weeks, September 2, 2026 is the day that is meant to change. On that date, at block height 34,844,968 and
If you hold ZIL on a crypto exchange and have been unable to deposit or withdraw for weeks, September 2, 2026 is the day that is meant to change. On that date, at block height 34,844,968 and an estimated 12:58 UTC, Zilliqa executes a hard fork that moves the ZIL balances of ten exchanges out of the old wallets into new addresses. The venues involved then intend to reopen deposits and withdrawals. You do not have to do anything yourself.
If you keep your ZIL in your own wallet on the old network, a second and larger process applies to you, and it still carries no date: every holder on the old side will have to migrate later, including everyone who was never robbed. Neither event is a planned upgrade. Both go back to a signing flaw in the Zilliqa Ledger app. By Zilliqa's own accounting, 683,130,969.66 ZIL drained out of 6,772 accounts as a result.
This article separates the two levels: what actually happens on September 2, and what remains open afterwards.
A hard fork is a rule change to a blockchain that makes old and new software incompatible: from a set block onwards only the new rulebook applies, and anyone who does not follow drops out of the network. It is triggered by block height, meaning the sequential number of the most recently written block, rather than by a clock time. Every time estimate attached to it is a projection.
The fork in question changes little about the protocol itself. Its job is a transfer. The ZIL holdings that ten centralised exchanges keep for their customers in the old, Schnorr-based wallets are written to new wallet addresses on the Zilliqa EVM network. Each exchange supplies and confirms these destination addresses in advance. A Schnorr signature is the signing scheme of the old Zilliqa network, through which a transaction proves that it comes from the account holder.
One point matters for context: this fork is an administrative measure for exchange balances. It is not a network upgrade that brings you new features, and it is not a recovery of stolen funds. We described how a regular, planned hard fork unfolds, and what holders, traders and delegators need to think about, using the BNB Pasteur hard fork as a checklist. The difference in the Zilliqa case lies in the occasion, not in the mechanics.
Zilliqa is a layer-1 blockchain, an independent chain with its own consensus and its own coin, and it launched with a technical selling point: sharding. Sharding means a network splits its nodes into groups that process transactions in parallel, instead of every node verifying every transaction. That raises throughput while making the protocol considerably more complex. ZIL is the native coin of this network and pays the transaction fees on it.
The rebuild into Zilliqa 2.0 added EVM compatibility, and since then the project has run two environments side by side. That shift was already under way before the incident. The incident accelerated it and made it irreversible: the mainnet, meaning the productive main network as opposed to a testnet, is to consist solely of the EVM side in future, and the old side will be shut down rather than repaired.
On July 20, 2026, Zilliqa halted all transactions on the old side of the network. Nothing has moved there since, neither your balance nor an attacker's. That pause is precisely why exchanges suspended ZIL deposits and withdrawals. The venues can no longer operate on the old side technically.
Every Schnorr signature consumes a nonce, a fresh random number that must be used exactly once and never reused. The Zilliqa Ledger app generated that number correctly and then copied it into the signature buffer incorrectly. In doing so, the app kept eight padding bytes of zeros and discarded eight bytes of genuine randomness. That fixed the top 64 bits of every nonce at zero.
Zilliqa's post-mortem describes the consequence precisely: every signature produced this way leaks roughly 64 bits about the private key, and from four or more signatures of the same account the key can be reconstructed on ordinary hardware in seconds. Doing so requires only data that already sits publicly in the blockchain. Nobody was deceived, no device was hacked, no recovery phrase was stolen. The information leaked through the transactions themselves.
Precise attribution is worth the space here, because the Ledger name is involved. According to Zilliqa, the original implementation of the affected application came from Zilliqa itself, the defect was present in every released version, and the fix was written by a Zilliqa developer and submitted as a pull request to Ledger. Your recovery phrase was never affected, and holdings you keep on the same device on other blockchains are not at risk on this account. The flaw reaches into exactly one signing path and not a step further.
Proven losses stand at 683,130,969.66 ZIL across 66 transactions. 6,772 accounts count as demonstrably exposed, 51 of them were emptied completely. Zilliqa explicitly calls both figures lower bounds, arrived at through proof rather than estimation. By the same accounting, 73.9 percent of the attributable old addresses are safe by construction, because they never signed through the affected app.
The timeline explains why this went unnoticed for so long. The first proven theft falls on March 4, 2026. The exploitation was reported on July 19, 2026 by the exchange KuCoin, after it had seen unusual outflows from one of its own cold wallets. A day later, old transactions were switched off. There is a technical reason nobody raised the alarm earlier: in this scheme the check value is derived from the message, so the usual search for duplicate values, with which many chains routinely hunt for signature faults, finds nothing here.
The defect did not sit in the network but in the signature created during signing. According to the Zilliqa team's announcement, the first batch that the fork processes on September 2 covers ten trading venues:
For European readers, Bitvavo is the most relevant name on this list, because the exchange serves the European market. If your trading venue is not on the list, that does not mean it has been excluded. Zilliqa expressly speaks of a first batch and has so far named no date for further venues.
What you can expect after the fork is not a switch being flipped. The exchanges in the first batch intend to resume deposits and withdrawals on Zilliqa EVM once their own migration and integration tests are complete. Zilliqa itself writes that timelines may differ between venues. Plan in days rather than minutes, and check your own provider's status page instead of relying on a general date.
The whole affair only makes sense once you take one distinction with you. Zilliqa runs two sides. Legacy Zilliqa is the older, non-EVM-compatible side with its own accounts, its Schnorr signatures and the Ledger application built for them. Zilliqa EVM, also called Zilliqa 2.0, is the newer side that uses the same execution environment as Ethereum.
EVM stands for Ethereum Virtual Machine and denotes the standardised runtime in which smart contracts execute. A chain that is EVM-compatible can take over contracts and address formats from the Ethereum world directly. The difference shows in the address format: old Zilliqa addresses begin with zil1, EVM addresses with 0x.
The incident affects the old side only. Anyone who was active on Zilliqa EVM alone is untouched by it. The same holds for staked ZIL: if it sits in staking on the EVM side, it keeps running. If it sits in an old staking contract, it is paused along with everything else on the old side and will need the recovery route later. Incidentally, it is not only ZIL transfers that are affected but every kind of transaction, including moving ZRC-2 tokens. ZRC-2 is the token standard of the old Zilliqa network and does roughly what ERC-20 does on Ethereum.
For you this leads to a practical question you should answer before September 2: does your holding sit at an exchange, in your own software wallet or on a hardware device? Only the first case is settled by this fork. If the occasion has you thinking about how you store your holdings in future, our comparison of crypto hardware wallets helps sort through the criteria.
Zilliqa communicates in English only, and the status page leans on vocabulary whose meaning is not always obvious in this context. This mapping helps: a hard fork is the rule change described above, block height is the running number of the last block written, exchange balances are the customer holdings the venues keep, deposits and withdrawals are paying in and paying out, legacy denotes the old side of the network and recovery the planned restoration procedure. The address checker and the post-mortem add accounts for the individual wallets and vulnerability for the flaw itself.
Since August 11, 2026, Zilliqa has offered an address checker. You enter an old Zilliqa address and the tool examines its public signing history for traces of the flaw. No wallet connection is required, and neither seed phrase nor private key is requested. According to the operator, only the address is sent to the server, answered there and not stored.
You come into question as affected if you ever used the Zilliqa Ledger app to sign, whatever the purpose: sending ZIL, moving ZRC-2 tokens and NFTs, or staking. It becomes critical from around four transactions signed this way, because at that point reconstructing the key becomes practically feasible. The app version does not matter, because every version carried the defect.
By the same accounting you are not affected if one of these points applies to you:
Zilliqa names this limit itself, and it belongs in every account of the case: signatures created off the chain leave no trace on it. The checker consequently does not see them. An unremarkable result therefore means that no exposure was found, not that none exists. Treat the finding as an indication rather than a certificate, and answer the additional question for yourself of whether you ever used the app.
The second point is more uncomfortable. The exposure is permanent. Signatures that are once in the chain cannot be withdrawn. A corrected app therefore protects new keys and changes nothing about keys that have already signed. An account that was exposed once will eventually have to be retired and its contents moved to a fresh address. That is precisely the job of the migration tool that is still outstanding.
The old side of the network is being retired, and Zilliqa EVM is to become the only productive side. The honest answer is: not much, but that little is worth doing. Four things are possible today.
First, check your old addresses in the checker and note the result with the date. If a recovery procedure starts later, your own record is worth more than memory. Second, establish where your holding actually sits, and separate exchange balances from self-custody. Third, find your trading venue's status page and check whether it is in the first batch. Fourth, keep your hands off any tool that someone sends you privately.
What you should not do is equally clear: do not try to move old holdings by workarounds. It does not work anyway while the pause is running, and any service promising you otherwise is not working in your interest.
The fork brings ten exchanges back into business. Three larger questions remain open afterwards, and none of them carries a firm date so far.
There is, first, the migration tool for self-custodians. As of the status report of August 11, 2026, it was in an external security audit whose report is expected in early September. Only after that does Zilliqa intend to name a start date. Second, the recovery procedure for holders of affected accounts: the plan is a route in which you prove ownership of an account without disclosing your seed phrase. Exactly what that proof looks like is still being worked out. Third, an updated tokenomics model meant to reflect the holdings of the retired side.
Zilliqa itself writes that no date is deliberately attached to this list. As a reader you should treat that neither as reassurance nor as an alarm, but as what it is: an open position. September 2 ends the freeze for one group of holders and leaves the other group waiting.
Deadlines tied to a block height shift when the network runs faster or slower than assumed. We therefore measured rather than adopting the figure. A query of the eth_blockNumber method against Zilliqa's mainnet node returned block height 34,541,838 on August 29, 2026 at 18:36 UTC. That left 303,130 blocks to the target block of 34,844,968.
At the block time of roughly one second that Zilliqa 2.0 works with, that corresponds to about three and a half days. Counting from the moment of measurement, this lands on September 2, 2026, exactly the announced day. The 12:58 UTC time is the least certain quantity in this calculation. Shifts of a few hours are normal; a jump of days would not be.
In practice this means: if you see no release on the afternoon of September 2, that is no cause for concern. Only once the target block has been passed and your exchange stays silent for several days does a support enquiry make sense.
A date on which thousands are waiting for the release of their money is an open goal for fraudsters. Zilliqa warns explicitly on its own status page about impersonators offering help with supposed recovery, and names two rules worth remembering: the team never contacts anyone first, and it never asks for a seed phrase, private key or recovery phrase under any circumstances.
A simple stance for the coming weeks follows from this. Every recovery form, every migration link and every tool that reaches you privately counts as hostile, even if it looks official or comes from a supposed moderator. Use only what has been announced through the project's official channels, and check the page address in your browser before you enter anything.
The Zilliqa case is unusual in its cause and entirely ordinary in its effect. A balance sits with a third party, a technical process freezes it, and the holder finds out last. You know the same pattern from migration deadlines for individual tokens and from trading suspensions where a holding can no longer be moved after a cut-off date. We have gathered the recurring dates on which exchange balances come under time pressure in a separate overview of deadlines at crypto exchanges.
The lesson is uncomfortable, because it creates work. A balance on an exchange is a claim against a company and not ownership on the chain. As long as everything runs, the difference is theoretical. On a day like this one it turns practical, because whether and when you get back in is decided by the trading venue and not by you. Anyone holding larger amounts is therefore well advised to spread them across several routes, and anyone choosing an exchange should look at domicile, supervision and communication behaviour in a crisis alongside the fees.
The two primary sources to read up on: the official Zilliqa status page on the incident with the address checker and the action plan, and the report on the hard fork date with block height and the exchange list.
(As of August 29, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)
