Zilliqa Ledger App Key Leak Places ZIL Under Upbit Trading Caution
Key Takeaways
- •Upbit placed Zilliqa under formal trading caution on July 22, with a review window expected to run through August 17 to 21, during which ZIL spot trading remains open but deposits and withdrawals are suspended.
- •The vulnerability in the Zilliqa Ledger app stems from flawed nonce generation in Schnorr signatures that left 64 bits fixed at zero, allowing attackers to reconstruct private keys after approximately five or more native transactions using only publicly available on-chain data.
- •The bug has affected every released version of the Zilliqa Ledger app's native transaction-signing path from 2019 through 2026, though users of software wallets, exchange-hosted wallets, or Ledger devices that only signed EVM-based transactions are not impacted.
- •A corrected Ledger application has been prepared in coordination with Ledger, but the patch only prevents new vulnerable signatures and cannot repair keys already exposed through signatures permanently recorded on the blockchain.
- •Zilliqa has advised affected Ledger users not to move funds independently, as attackers who have already reconstructed private keys could submit competing transactions and potentially win a race to drain remaining balances when native transfers resume.

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 — operated by Dunamu and the largest crypto trading platform in Korea by volume — has not delisted ZIL. Spot trading remains available while Upbit reviews the incident, Zilliqa's response and the protections being developed for affected balances. The designation gives Zilliqa time to address the security issue, but it also creates a route toward delisting if Upbit determines that the vulnerability or its consequences have not been adequately resolved.
Upbit Keeps ZIL Trading Open During Review
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 may remove the caution designation if the security concerns are resolved, extend the review if more time is needed, or terminate trading support if it 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 may be returned through the exchange's recovery process. Upbit also said withdrawals will receive priority when transaction services begin reopening. Deposits are expected to remain unavailable until the exchange issues a separate announcement.
The result is an unusual trading environment. 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.
ZIL Trades Within 1% of Its All-Time Low
The market reaction pushed ZIL close to its record low. 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 was roughly 1% above Zilliqa's all-time low of $0.002339, according to CoinMarketCap.
The heaviest daily selling volume of the previous two months occurred on July 20, the day a theft from a partner wallet was disclosed. The daily Relative Strength Index had fallen to about 28, below the traditional oversold threshold of 30. The price was also far below the 50-day, 100-day and 200-day moving averages, all of which continued to slope downward.
The decline reflects more than the risk 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.
Seven-Year Ledger App Bug Weakened Signatures
The security incident originated in the Zilliqa application used on Ledger hardware wallets. It did not originate in Ledger's core hardware and did not involve Zilliqa's consensus mechanism.
Zilliqa launched its mainnet in 2019 as one of the first public blockchains designed around sharding for transaction throughput. 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… — 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 error left the most significant 64 bits of each nonce fixed at zero, materially reducing the randomness that protected each signature.
Flawed nonce generation has caused high-profile private-key recoveries in other cryptographic systems. The most widely known case involved Sony's PlayStation 3, where the company reused a static nonce across ECDSA signatures, allowing hackers to extract the signing key and unlock the console. The Zilliqa Ledger vulnerability is different in mechanism but exploits the same principle: insufficient nonce randomness exposes the underlying private key through mathematics alone.
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 by 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.
Scope of the Vulnerability
The incident does not amount to a breach of every Zilliqa wallet or of the blockchain itself. The risk is narrower, but remains critical for users whose native transactions were signed through the affected Ledger application.
The vulnerability applies to native, non-EVM Zilliqa transactions signed with the impacted Ledger app. Zilliqa's disclosure focused on the app's nonce generation for Schnorr signatures, rather than on Ledger hardware, Zilliqa's consensus system, or all wallet types across the network. Users of software wallets, exchange-hosted wallets, or Ledger devices that only signed EVM-based Zilliqa transactions are not affected by this specific flaw.
Exploitation Was Detected Before Public Disclosure
The timeline developed rapidly. 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.
Why Users Were Told Not to Move Funds Independently
The usual response to a compromised cryptocurrency wallet is to create a new address and move the remaining assets immediately. Zilliqa has warned that this 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.
A standard wallet evacuation could therefore 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."
Zilliqa's official security disclosure
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 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.
Patch Does Not Repair Previously Exposed Keys
The permanent nature of blockchain transaction history is 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 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 Decision Depends on Remediation Plan
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 August review window 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.