Zilliqa Announcement

• The Third hard fork went live successfully. ZIL balances for Bithumb, Uphold and Bybit were migrated from Legacy Schnorr addresses to verified Zilliqa EVM addresses.

• Paribu and CEX.IO have also resumed ZIL deposits and withdrawals on Zilliqa EVM, alongside Binance, Bitvavo, HTX, MEXC, LBank and Bitkub.

• The Zilliqa Ledger app is now available. Ledger users can use it alongside the ZKP Migration App to migrate their liquid ZIL.

If you haven’t migrated the ZIL in your Legacy account yet, you can do so now. Read the full guide before starting: https://blog.zilliqa.com/migrate-zil-from-a-legacy-account-to-zilliqa-evm/

A quick follow-up on migration progress:

• The ZKP Migration App installation guide is now available for macOS, alongside the Linux and Windows guides https://blog.zilliqa.com/migrate-zil-from-a-legacy-account-to-zilliqa-evm/.

• Binance, Bitvavo, HTX, MEXC, LBank and Bitkub have resumed ZIL deposits and withdrawals on Zilliqa EVM.

• Third hard fork is scheduled for 5 October 2026 at 10:00 UTC, at block height 37,410,000.

This hard fork will migrate ZIL balances for Bithumb, Bybit and Uphold from Legacy Schnorr addresses to verified Zilliqa EVM addresses.

The ZKP Migration App is available for retail holders moving ZIL from a Legacy (Zil1...) account to a Zilliqa EVM (0x...) account.

We’ve published a step-by-step guide covering installation on Windows and Linux, what to expect inside the app, and how to submit your claim after generating a proof.

Full guide: https://blog.zilliqa.com/migrate-zil-from-a-legacy-account-to-zilliqa-evm/

A quick ZIL migration update:

- Binance has announced support for the ZIL token migration https://www.binance.com/en/support/announcement/detail/343ad3d991c64b27842482f1fb1fe11c.

- Bitvavo and MEXC have resumed ZIL deposits and withdrawals on Zilliqa EVM.

- The ZKP migration tool is in its final stages of preparation. It will be released soon.

- The second exchange migration hard fork was successfully activated on 22nd September at block height 36,383,378. ZIL balances for participating exchanges were migrated from legacy Schnorr addresses to verified Zilliqa EVM addresses.

- Participating exchanges are expected to restore ZIL deposits and withdrawals gradually on Zilliqa EVM. Please follow their official channels for timeline.

The Second hard fork for the migration of centralised exchange balances is scheduled for block height 36,383,378, with an estimated activation time of 22 September 2026 at approximately 07:21 UTC.

It will migrate participating exchange's ZIL balances from legacy Schnorr-based wallets to the verified Zilliqa EVM wallet addresses provided by each exchange.

The following exchanges are included in the second hard fork:
CoinEx
HTX (Huobi)
Bitkub
GOPAX
Coinone
OKX
LBank
Crypto.com
Gate
Paribu
CEX.IO
Bitget

Bybit and Bithumb are expected to be included in the third hard fork. We remain in contact with other exchanges, including Upbit, and aim to include them in subsequent hard forks once all required addresses have been verified and mapped.

Deposits and withdrawals: Once the hard fork is active and balances have been successfully migrated, exchanges included in this batch are expected to gradually restore ZIL deposits and withdrawals on Zilliqa EVM.

Timelines will vary by exchange. Please follow each exchange’s official channels for updates.

ZKP Migration tool: The ZKP migration tool audit is complete, and internal testing is underway.

Rollout is targeted for 22 September, when the second hard fork activates the required escrow contract.

Audit report: https://hacken.io/audits/zilliqa/sca-zilliqa-zilliqa-ownership-proof-aug2026/

MEXC has successfully completed the migration of ZIL to Zilliqa EVM.

ZIL deposits and withdrawals will reopen on 8 September 2026 at 10:00 UTC.

Users should ensure they select the Zilliqa EVM network when depositing, as legacy ZIL deposits will no longer be supported.

Read the full MEXC announcement.

Six weeks after legacy transactions were paused, we’ve published a full update on where things stand and what comes next.

Key developments:

- The first exchange migration hard fork completed today.
- A second exchange migration is planned for mid-September.
- The self-guided, zero-knowledge migration tool for legacy wallet holders is in its final stages and remains on track for mid-September.
- A community proposal is being prepared on a potential tokenomics adjustment and to compensate impacted holders.
- Once these migration milestones are complete, our focus will return fully to executing Zilliqa’s strategic roadmap.

We know the community has been asked for a great deal of patience. This update explains the progress made, the work still ahead, and how we intend to move forward.

Read the full update: https://blog.zilliqa.com/where-we-stand-migration-progress-the-path-to-compensation-and-getting-back-to-building/

Note: Exchanges included in this first batch are expected to begin restoring ZIL deposits and withdrawals on Zilliqa EVM soon. Timelines will vary, so please follow each exchange’s official channels for updates.

Exchange migration hard fork scheduled:

The first hard fork for the migration of Centralised exchange balances is scheduled for block height 34,844,968, with an estimated activation time of 2 September 2026 at approximately 12:58 UTC.

It will migrate the ZIL balances held in participating exchanges’ legacy Schnorr-based wallets to the new Zilliqa EVM wallet addresses provided and verified by each exchange.

The following Exchanges included in the first hard fork:

KuCoin
MEXC
OKCoin
Binance US
Bitvavo
DigitalX (Korbit)
Indodax
Bitrue
WhiteBIT
CoinSpot
CoinSwitch

We remain in contact with the remaining exchanges, including Binance, Upbit, Bithumb, Coinone and GOPAX. We aim to include remaining exchanges in subsequent hard forks to complete the ZIL migration for exchange partners.

Deposits and withdrawals:

Once the hard fork is active and balances have been successfully migrated, exchanges included in this first batch are expected to begin restoring ZIL deposits and withdrawals on Zilliqa EVM. Timelines will vary, so please follow each exchange’s official channels for updates.

Note: Balances identified as having been stolen by the attacker will not be restored through this hard fork. Efforts to trace and recover the stolen funds continues in coordination with the appropriate legal authorities, exchange partners and other relevant parties.

A full post-mortem into the legacy Zilliqa Ledger application incident has been published.

The report provides a transparent account of:
• The technical root cause
• How the vulnerability could be exploited
• The timeline of the incident and response
• The confirmed impact
• The actions taken to prevent further exploitation
• The migration and recovery work now under way

The investigation established that a flaw in the application’s handling of Schnorr signature nonces exposed information that could allow private keys to be reconstructed from public transaction data.

The report confirms:
• 683,130,969.66 ZIL in proven theft
• 6,772 accounts known to have been exposed
• 51 accounts drained
These figures are confirmed minimums based on available evidence, not estimates.

The report includes a technical annex explaining the methodology behind each figure.

Read the full post-mortem: https://www.zilliqa.com/ledger-incident/post-mortem/

Progress update: 12/08/2026

• The address checker is now live. Enter your legacy Zilliqa address (Zil1...) to check whether it was affected or may be vulnerable.

• The migration tool is expected to undergo an external security audit over the next two weeks, with the report targeted for early September. A launch date will follow once the findings have been reviewed.

• Several exchanges have confirmed support for the migration. We are targeting the first batch of exchange migrations by the end of August, enabling participating exchanges to work towards resuming ZIL deposits and withdrawals on Zilliqa EVM.

• Efforts to trace the stolen funds continue with legal authorities, exchange partners and other relevant parties. We cannot share further details while the investigation is ongoing.

Check your address and read the full update: https://www.zilliqa.com/ledger-incident/

Zilliqa Ledger incident: the recovery and transition plan is published

Read the full plan: zilliqa.com/ledger-incident/

- The legacy (non-EVM) side of Zilliqa is being retired, with recovery taking place through migration to Zilliqa EVM.
- Legacy balances do not expire, and nothing is forfeited by waiting.
- No migration tool has been released yet.
- No part of the published plan includes a cut-off date.
- Legacy transactions remain paused, and no action is required at this time.

Beware of impersonators and scammers sharing phishing links or inviting you to groups that appear official. Zilliqa team will never contact you first or ask for your recovery phrase.

We have published a dedicated Ledger Incident Hub with the latest confirmed information on the signing flaw affecting the Zilliqa Ledger application for Legacy accounts.

Legacy Zilliqa transactions remain paused as a precaution. Zilliqa EVM is not affected.

The hub explains:
• what happened
• who may be affected
• what is currently paused
• what action users should take
• how the recovery work is progressing

You do not need to take any action right now. The Zilliqa team will never contact you first or ask for your seed phrase, private key or recovery phrase.

Read the Incident Hub: https://www.zilliqa.com/ledger-incident/

Nonce-Generation Vulnerability in the Zilliqa Ledger App

A critical vulnerability has been identified in the Zilliqa Ledger application affecting the generation of Schnorr signatures for native (non-EVM) Zilliqa transactions. The vulnerability causes signatures to be generated with a predictably weakened ephemeral nonces, from which an attacker can recover the signer’s private key using only publicly available on-chain data.

Protective measures are already in place to prevent further loss, and a coordinated remediation plan is being finalised. Users who have signed native Zilliqa transactions with a Ledger device should await official guidance before taking any action.

Impact

The vulnerability affects private keys used to sign native Zilliqa transactions with a Ledger device. Any account that has broadcast approximately five or more native transactions signed through the Zilliqa Ledger app should be considered compromised. Its private key can be reconstructed from signatures already recorded on-chain, regardless of any subsequent software update.

The issue is confined to the Ledger app’s native signing path. EVM transactions are unaffected. Zilliqa software development kits, including zilliqa-js, gozilliqa-sdk and pyzil, generate nonces correctly and are not affected.

Root cause

Zilliqa native transactions are authenticated using EC-Schnorr signatures over secp256k1. Each signature requires a fresh, uniformly random 256-bit ephemeral nonce, (k). The secrecy and full-width randomness of (k) are essential, as any systematic bias can allow the private key to be recovered.

The signing routine generated 40 bytes of randomness and reduced them modulo the curve order, correctly producing a uniform 256-bit value. However, when copying this value into the nonce buffer, the code copied the wrong 32 bytes of the 40-byte output. This retained the eight zero-padding bytes introduced by the reduction and discarded eight bytes of entropy.

As a result, the most significant 64 bits of every generated nonce were fixed at zero, meaning (k < 2^{192}).

A nonce with 64 known bits leaks information about the private key with each signature. With five or more affected signatures, the private key can be recovered in seconds using commodity hardware by solving the resulting Hidden Number Problem through lattice reduction - a well-documented technique for attacking biased-nonce signatures.
Because the affected transactions are permanently recorded on-chain, this exposure cannot be reversed by updating the signing application. The affected keys must be retired.

Timeline

2019-2026: The defect was present in every released version of the Zilliqa Ledger app across all supported devices.

19 July 2026: On-chain activity consistent with active exploitation was observed.

21 July 2026: The root cause was isolated to the app’s nonce-handling code and confirmed by reproducing the issue against on-chain signatures.

Ongoing: A corrected version of the app is being prepared in coordination with Ledger. Release details will be announced separately.

Remediation

As soon as the issue was identified, native (non-EVM) transactions were suspended as a protective measure. This has halted further draining of affected accounts while a solution is prepared.

Affected accounts cannot be secured through an ordinary transfer. Because their private keys can be derived from data already recorded on-chain, an attacker with access to the same key could attempt to front-run a legitimate transfer as soon as transactions resume. Advising users simply to move their funds would therefore be ineffective and potentially unsafe.

A corrected build of the Ledger app has been prepared, restoring full-width nonce generation and preventing further weakened signatures from being produced. However, this does not protect keys that have already been used to sign affected transactions. Those keys must ultimately be retired.

A coordinated remediation plan to secure affected balances is being finalised and will be published separately. Until then, users who have signed native Zilliqa transactions with a Ledger device should take no independent action and should rely solely on official Zilliqa channels for instructions.

Users who hold or transact with ZIL exclusively through EVM-compatible tooling are not affected.

Acknowledgments

KuCoin played a key role in pinpointing the root cause in the Zilliqa Ledger app nonce generation, recovered affected private keys from publicly available on-chain signatures, and confirmed ongoing exploitation.

KuCoin’s timely reporting and responsible collaboration enabled rapid protective measures, helping safeguard users, ecosystem participants, and the broader Zilliqa ecosystem while the remediation plan was being developed.

We sincerely appreciate the KuCoin team’s professionalism, technical expertise, and cooperation throughout this process.

As our investigation has progressed, we would like to clarify one important point:

At this stage, we have found no evidence that the incident was caused by the exchange’s wallet management or operational processes. We appreciate the exchange’s cooperation in identifying the issue quickly and assisting throughout the investigation.

The investigation has instead identified a technical issue affecting transaction signing in a specific set of legacy ZIL1 wallets. We are continuing to verify the precise root cause before publishing a detailed technical report.

We will share a full post-mortem, including technical findings and any recommended actions, as soon as the investigation is complete.

Thank you for your patience while we work to ensure the information we share is accurate.

We have been made aware of a security incident involving one of our exchange partners, in which ZIL was stolen from a cold wallet.

The incident is under active investigation, and we are working with the relevant parties to establish the root cause and full scope. As a precaution, all exchanges have been notified and asked to temporarily pause ZIL deposits and withdrawals to prevent the stolen funds from being moved or sold through centralised platforms.

We understand the community will have questions. We will share further updates as soon as we have verified information. Please rely only on official Zilliqa channels for updates.

A question institutional teams ask: why not just run a compliance layer over an existing settlement chain?

On a chain built to settle first, settlement is the state transition; permission would have to be built into the definition of a valid transaction, not added after it. You cannot retrofit that.

The new post works through the architecture, and through the two-hander it depends on: LTIN issues the identity, Zilliqa runs the check beside it. https://blog.zilliqa.com/mediation-defined/

August 2022. A counterparty already on the sanctions list. The payment goes out in USDT - the issuer doesn't block on designation, so it confirms and settles like any other transfer. Send the same value in USDC and the token itself would have refused it; on a permissionless rail you don't get to choose what your counterparty holds.

Screening happens afterward: a disclosure filed, the transfer still standing. Enforcement that depends on which coin moved isn't enforcement.

The fix is a permission check before settlement - run beside the rail, not by it.

- identity issued by LTIN
- checked by Zilliqa before a transaction settles

That is what this partnership is built for.

A new chapter, not a new pitch.

LTIN and Zilliqa first started building together at LTIN's launch last October; today it becomes a partnership, which creates a new category. LTIN issues the verifiable identity; Zilliqa runs the neutral check that confirms permission before a transaction settles, beside it, on any chain.

Follow along. https://www.ltin.li/insights/ltin-and-zilliqa-deepen-partnership-to-build-trustworthy-global-digital-infrastructure-as-a-public-good

The roadmap is live - and there's a blog post explaining the thinking behind it.

Short version: Institutional blockchain finance has always settled first, checked
compliance after. Zilliqa is built to run that check before - on any chain or
settlement rail. The roadmap sets out how we build that infrastructure from now
through 2027, phase by phase, each step tied to something we ship.

Read the blog: https://blog.zilliqa.com/compliance-before-settlement-the-zilliqa-roadmap/
Read the roadmap: https://zilliqa.com/roadmap

More to come later this year. For now - this is the direction, on the record.
Tell us what you think.

Protofire has completed a major upgrade across the Zilliqa Safe stack.

What's new for users?

- Better protection against scams and address poisoning attacks
- Faster loading and fewer delays thanks to backend and performance upgrades
- Export your transaction history to CSV
- Batch multiple transactions together, including existing transaction batches
- Improved WalletConnect experience when switching networks
- Safe account limit increased from 10 to 40
- Cleaner signing flow with clearer transaction status
- Automatic execution option when enough signatures have been collected

Behind the scenes, the infrastructure has also been upgraded to improve reliability, scalability, and security across the platform.

This release lays the groundwork for upcoming features including:
Spaces - shared workspaces for teams and organisations
Nested Safes - manage Safes within Safes with a dedicated interface

Built on the trusted Safe protocol, Zilliqa Safe continues to improve with stronger security, better usability, and a smoother overall experience.

Try now: https://safe.zilliqa.com/home