Upbit has placed Zilliqa under formal trading caution after a critical flaw in the Zilliqa Ledger app allowed private keys to be reconstructed from transaction signatures already visible onchain.
The South Korean exchange has not delisted ZIL. Spot trading remains available while Upbit reviews the incident, Zilliqa’s response and the protections being developed for affected balances.
This is important because the current designation gives Zilliqa time to resolve the security issue, but it also opens a direct path toward delisting if the exchange concludes that the vulnerability or its consequences have not been adequately addressed.
According to Upbit’s official notice, ZIL entered its cautionary review period on July 22. The observation window is expected to continue through the third week of August, covering August 17 to August 21.
During that period, ZIL/KRW and ZIL/BTC trading remains open. Upbit can remove the caution designation if the security concerns are resolved, extend the review if more time is required or terminate trading support if the exchange determines that the risks remain unresolved.
ZIL deposits and withdrawals had already been suspended on July 20. New deposits sent to Upbit while the service is blocked may not be credited and can be returned through the exchange’s recovery process.
Upbit also indicated that withdrawals will receive priority when transaction services begin reopening. Deposits are expected to remain unavailable until the exchange issues a separate announcement.
This creates an unusual position for traders. ZIL can still be bought and sold inside Upbit, but tokens cannot currently move freely into or out of the exchange. Trading therefore continues while the underlying settlement route remains restricted.
The market reaction has pushed ZIL to the edge of uncharted territory. On the ZIL/USD daily chart on OKX, the token traded near $0.0024 as of 13:15 UTC on July 22, down about 7% on the day, after touching an intraday low of $0.00236. That low sits roughly 1% above Zilliqa’s all-time low of $0.002339, according to CoinMarketCap.
The chart also shows when the real damage happened. The heaviest daily selling volume of the past two months arrived on July 20, the day the theft from a partner wallet was disclosed, and the daily Relative Strength Index has fallen to about 28, below the traditional oversold threshold of 30. Price now sits far beneath the 50-day, 100-day and 200-day moving averages, all of which continue to slope downward.
The decline reflects more than the possibility of losing an exchange listing. The underlying flaw affects the private keys of some Ledger users and cannot be reversed simply by updating the wallet application.
The security incident originated in the Zilliqa application used on Ledger hardware wallets, not in the Ledger device’s core hardware and not in Zilliqa’s consensus mechanism.
In its official vulnerability disclosure, Zilliqa said the flaw affected every released version of the app’s native transaction-signing path from 2019 through 2026.
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… https://t.co/sudV7WA3TV
— Zilliqa (@zilliqa) July 22, 2026
Native Zilliqa transactions use Schnorr signatures. Each signature depends on a temporary secret number, known as a nonce, which must be generated with sufficient randomness and must never be predictable.
The Zilliqa Ledger app generated the required randomness but copied the wrong section of the result into the signing process. That mistake left the most significant 64 bits of each nonce fixed at zero, materially reducing the randomness protecting each signature.
A single weakened signature leaks only part of the information needed to reconstruct a private key. Repeated signatures from the same account reveal more. Zilliqa said an attacker could recover the private key of an affected account after approximately five or more native transactions using publicly available onchain signatures.
The attacker does not need physical possession of the Ledger device, its PIN or the user’s recovery phrase. The necessary signature data is permanently recorded on the blockchain.
| Category | Status | Explanation |
|---|---|---|
| Native ZIL transactions signed through Ledger | Affected | The vulnerable signing process generated weakened nonces that can expose the account’s private key. |
| Accounts with roughly five or more affected signatures | Potentially compromised | The private key may be reconstructed from signatures already recorded onchain. |
| Zilliqa EVM transactions | Not affected | The flaw is limited to the native Ledger app signing path. |
| Zilliqa software development kits | Not affected | Zilliqa’s JavaScript, Go and Python development kits generate transaction nonces correctly. |
| Ledger hardware security | Not identified as the source | The defect was found in Zilliqa’s application-level signing code rather than Ledger’s secure hardware. |
This scope prevents the incident from being described accurately as a breach of every Zilliqa wallet or of the blockchain itself. The risk is narrower, but it is still critical for users whose native transactions were signed through the affected Ledger application.
The sequence moved quickly: suspicious onchain activity was observed on July 19, a theft was reported on July 20, the root cause was isolated on July 21, and Upbit’s caution designation followed on July 22.
The July 20 report involved ZIL stolen from a cold wallet operated by an exchange partner, which Zilliqa did not name. The project contacted exchanges and requested temporary restrictions on native ZIL deposits and withdrawals while the source of the incident was investigated.
Zilliqa credited KuCoin with helping identify the failure, reconstructing affected private keys from public signatures and confirming that exploitation was taking place. Native Zilliqa transactions were then suspended to prevent additional funds from being drained while a recovery procedure was developed.
A corrected version of the Ledger application has also been prepared in coordination with Ledger. The patch restores the full randomness required when producing new signatures.
The usual response to a compromised cryptocurrency wallet is to create a new address and move the remaining assets immediately. Zilliqa has warned that the same response may be ineffective or dangerous in this case.
If an attacker has already reconstructed the private key, both the legitimate holder and the attacker can sign valid transactions from the same address. When native transfers resume, an attacker could monitor the account and attempt to submit a competing transaction before the owner’s transfer is confirmed.
That means a standard wallet evacuation could become a race between two parties controlling the same key. It could also alert an attacker to an account that still contains assets.
“Users who have signed native Zilliqa transactions with a Ledger device should await official guidance before taking any action.”
Affected private keys will ultimately need to be retired, but Zilliqa has not advised users to perform that process independently. The project is finalizing a coordinated plan intended to protect affected balances while native transactions remain suspended.
Users should therefore avoid following unverified wallet-migration instructions, entering recovery phrases into new websites or responding to direct messages offering assistance. The remediation process should be followed only through official Zilliqa and Ledger communications.
The permanent nature of blockchain transaction history creates the central challenge. The corrected application only prevents the creation of new weakened signatures; every vulnerable signature already published remains publicly available forever.
An attacker can perform the private-key recovery calculation at any time using old signatures. Updating the app, changing the Ledger PIN or reinstalling wallet software does not change the private key controlling the affected address.
Resetting a hardware wallet with the same recovery phrase would also recreate the same underlying keys. A genuinely retired key would eventually need to be replaced with a newly generated key that is not derived from the compromised recovery material.
Even that technical step does not solve the immediate transfer problem while an attacker may control the old address. The missing piece is a coordinated mechanism for moving or protecting balances without exposing users to a transaction race once the network resumes.
Upbit’s final decision is likely to depend on more than the release of a patched Ledger application. The exchange must also evaluate how Zilliqa protects balances associated with keys that may already be compromised.
A complete response would need to establish the affected account population, provide a safe recovery process, prevent additional unauthorized transfers and explain how native transaction services can resume without creating another opportunity for attackers.
The approaching August review window therefore creates a clear deadline for Zilliqa. Repairing the signing code addresses the original technical defect, but restoring exchange confidence requires a credible solution for the keys and balances that were exposed before the patch existed.
Until that plan is published, ZIL remains tradable on Upbit but operationally restricted, while affected Ledger users are being asked to wait rather than attempt an independent transfer.
Source review: Based on Upbit’s official notice, Zilliqa’s security disclosures on X, ZIL/USD market data from TradingView (OKX) and all-time-low data from CoinMarketCap, checked July 22, 2026.
This article is provided for informational purposes only and does not constitute financial, investment or legal advice.
The post Zilliqa’s Seven-Year Key Leak Puts Its Upbit Listing at Risk appeared first on Coindoo.
