rewrite this title and make it good for SEO Zilliqa Halts Native Transactions After Ledger App Flaw Exposes Private Keys – NFT Plazas Zilliqa Halts Native Transactions After Ledger App Flaw Exposes Private Keys

Zilliqa has halted native ZIL transactions following the discovery of a critical vulnerability in the network’s Ledger application, which allows the private keys of certain accounts to be recovered from public signatures on the blockchain. The incident was disclosed after an undisclosed amount of ZIL was stolen from an exchange partner’s cold wallet, forcing the project to request centralized platforms to pause ZIL deposits and withdrawals to curb the movement of funds. 

According to Zilliqa, the flaw lies in the native transaction signing process using the Ledger app and does not affect EVM transactions or official SDKs. The project stated that the vulnerability had existed in app versions dating back to 2019, with on-chain exploitation signs detected on July 19, 2026, two days before the root cause was isolated.

Exchange Theft and Initial Response

Zilliqa publicly disclosed the incident on July 20, stating that an undisclosed amount of ZIL had been stolen from an exchange partner’s cold wallet. At the time, the project did not specify the technical cause or the scale of damages, noting that an investigation was ongoing to determine the root cause and the scope of impact.

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…

— Zilliqa (@zilliqa) July 20, 2026

Exchanges were subsequently notified and requested to pause ZIL deposits and withdrawals as a precautionary measure to prevent the stolen funds from being transferred or sold through centralized platforms while the verification process continued. 

On July 21, Zilliqa updated that it found no evidence suggesting the incident originated from wallet management procedures or operational activities of the exchange. The investigation then shifted to a technical issue affecting transaction signing in a group of legacy ZIL1 wallets, before the project disclosed detailed information about the vulnerability in the Zilliqa Ledger app a day later.

Affected Wallets and Transaction Scope

Zilliqa limited the scope of impact to private keys that had been used to sign native Zilliqa transactions via a Ledger device. According to the project’s advisory, accounts that have broadcast approximately 5 or more native transactions using the Zilliqa Ledger app should be considered compromised. 

This risk applies to signatures already publicly recorded on-chain, meaning subsequent software updates cannot reverse the exposure level of affected private keys. Users with accounts in this group must stop using the compromised keys, rather than merely updating the transaction-signing app. 

EVM transactions are unaffected, while transactions signed through official SDKs such as zilliqa-js, gozilliqa-sdk, and pyzil are also outside the scope of the flaw. The incident is therefore isolated to the native signing path of the Zilliqa Ledger app. 

Zilliqa has not disclosed the amount of ZIL stolen, the number of affected accounts, or the total value of assets held in vulnerable addresses. As a result, the overall financial extent of the incident remains unclear.

Ledger App Vulnerability

The root cause lies in how the Zilliqa Ledger app generates nonces for EC-Schnorr signatures on the secp256k1 curve. For each signature, the app needs to generate a fresh, random, and unpredictable 256-bit nonce; if the nonce is biased or lacks entropy, multiple signatures can expose the private key. 

The app’s signing routine generates 40 bytes of randomness and then reduces this value modulo the order of the curve to produce a 256-bit number. However, when copying the result into the nonce buffer, the code mistakenly extracted 32 bytes from the 40-byte output, retaining 8 bytes of zero-padding while discarding 8 bytes of entropy. 

This flaw leaves the 64 most significant bits of each nonce fixed at zero. With approximately 5 or more affected signatures, the private key can be recovered in seconds on commodity hardware using Hidden Number Problem solving and lattice reduction techniques.

Native Transaction Halt

Zilliqa halted native non-EVM transactions as a protective measure while finalizing a remediation plan. The move aims to prevent further asset losses from vulnerable accounts while restricting the movement of stolen ZIL through the native transaction flow. 

Affected accounts cannot be protected by a standard transfer transaction either. If a private key can already be recovered from on-chain data, an attacker holding the same key can detect and front-run the user’s asset transfer transaction. Therefore, attempting to move funds independently may be ineffective and increase risk, while EVM transactions continue to remain unaffected.

Remediation Plan and User Guidance

A fixed build of the Ledger app is being prepared in coordination with Ledger. This fix will restore the full nonce generation process to prevent the app from creating further weakened signatures in the future. However, the patch cannot reverse the risk for private keys that have already signed the required number of affected native transactions previously. 

Keys belonging to the affected group ultimately need to be retired from use. Zilliqa is finalizing a remediation plan to safeguard balances in associated accounts and will publish separate instructions for users who have signed native Zilliqa transactions using Ledger. Until official guidance is provided, users are advised not to act independently and to monitor only the project’s official channels. 

KuCoin was credited by Zilliqa for assisting in identifying the root cause within the Ledger app’s nonce generation process, recovering affected private keys from on-chain data, and confirming ongoing exploitation activity. However, Zilliqa has not publicly confirmed whether KuCoin was the exchange partner that lost ZIL in the initial announcement.