Lina Irawan
Zilliqa, a prominent blockchain platform, has taken the drastic step of halting all native ZIL transactions following the discovery of a critical vulnerability within its Ledger application. This security lapse allows for the potential recovery of private keys associated with certain accounts, a risk amplified by the theft of an undisclosed amount of ZIL from an exchange partner’s cold wallet. The incident has compelled Zilliqa to request centralized exchanges to pause ZIL deposits and withdrawals to prevent further illicit movement of funds, underscoring the severity of the exploit.
The flaw specifically impacts the native transaction signing process facilitated by the Ledger app. Crucially, Zilliqa has clarified that this vulnerability does not extend to EVM (Ethereum Virtual Machine) compatible transactions or those initiated through official Software Development Kits (SDKs). Investigations indicate that the vulnerability has existed in app versions dating back to 2019. Signs of on-chain exploitation were first detected on July 19, 2026, with the root cause being isolated two days later. This timeline highlights a significant period during which users may have been unknowingly exposed.
Genesis of the Crisis: Exchange Theft and Initial Response
The public revelation of the security incident occurred on July 20, 2026, when Zilliqa announced that an unspecified quantity of ZIL had been pilfered from a cold wallet belonging to an exchange partner. At the outset, the project refrained from detailing the precise technical cause or the full extent of the financial damage, stating that an investigation was underway to pinpoint the origin and impact of the breach.
In a public statement on X (formerly Twitter), Zilliqa conveyed, "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…" The incomplete nature of the statement at the time reflected the unfolding and uncertain nature of the situation.
Following this announcement, Zilliqa’s operational teams promptly engaged with centralized exchanges. These platforms were formally requested to temporarily suspend all ZIL deposit and withdrawal services. This precautionary measure was designed to act as a circuit breaker, preventing the stolen ZIL from being transferred, traded, or laundered through the broader centralized exchange ecosystem while the investigation progressed.
By July 21, 2026, Zilliqa provided an update, stating that their preliminary investigation had yielded no evidence suggesting the incident originated from the exchange partner’s internal wallet management procedures or operational protocols. This crucial finding shifted the focus of the investigation towards a potential technical anomaly. The inquiry then pivoted to examine a specific technical issue affecting transaction signing within a cohort of legacy ZIL1 wallets. This narrowed scope paved the way for the subsequent identification of the vulnerability within the Zilliqa Ledger application, which was officially disclosed a day later.
Pinpointing the Exposure: Affected Wallets and Transaction Scope
Zilliqa has meticulously worked to define the precise boundaries of the vulnerability’s impact. The core of the issue is confined to private keys that have been utilized to sign native Zilliqa transactions through a Ledger hardware wallet. According to Zilliqa’s official advisory, any account that has broadcast approximately five or more native transactions using the Zilliqa Ledger app should be considered compromised. This threshold is critical for users attempting to assess their personal risk.
The inherent danger stems from signatures that have already been publicly recorded on the blockchain. This means that even future software updates to the Ledger app or the Zilliqa network cannot retroactively mitigate the exposure of these compromised private keys. Consequently, users whose accounts fall into this category are strongly advised to cease using the compromised keys entirely, rather than merely updating their transaction-signing application.
It is imperative to note that EVM transactions executed on Zilliqa remain unaffected by this vulnerability. Furthermore, transactions signed using official SDKs, such as zilliqa-js, gozilliqa-sdk, and pyzil, are also outside the scope of this specific flaw. The incident, therefore, appears to be isolated exclusively to the native signing pathway of the Zilliqa Ledger application.
As of the latest disclosures, Zilliqa has not publicly revealed the total amount of ZIL stolen, the exact number of affected accounts, or the aggregate value of assets held within the identified vulnerable addresses. This lack of specific financial quantification leaves the overall economic impact of the incident somewhat unclear, prompting a degree of uncertainty within the Zilliqa community.
The Technical Root: Unpacking the Ledger App Vulnerability
The fundamental cause of the security breach lies in the intricate process by which the Zilliqa Ledger app generates nonces for EC-Schnorr signatures on the secp256k1 cryptographic curve. In the context of digital signatures, a nonce (number used once) is a random, unpredictable value that is unique to each signature. If this nonce is biased or lacks sufficient randomness (entropy), it can create a cryptographic weakness that allows for the recovery of the associated private key.
The Zilliqa Ledger app’s signing routine was designed to generate 40 bytes of randomness, which would then be reduced modulo the order of the secp256k1 curve to produce a 256-bit nonce. However, a critical implementation error occurred during the process of copying this generated value into the nonce buffer. The code mistakenly extracted only 32 bytes from the 40-byte output. This resulted in the retention of 8 bytes of zero-padding while critically discarding 8 bytes of entropy from the random number.
This technical oversight had a profound consequence: the 64 most significant bits of each generated nonce were fixed at zero. This predictable characteristic, when combined with a sufficient number of affected signatures (approximately five or more), creates a vulnerability exploitable through advanced cryptographic techniques. Using methods such as the Hidden Number Problem (HNP) and lattice reduction algorithms, attackers can, on commodity hardware, recover the private key within a matter of seconds. This highlights the sophistication of the exploit and the critical importance of rigorous cryptographic implementation.
The Immediate Fallout: Native Transaction Halt
In response to the imminent threat posed by the vulnerability, Zilliqa made the decisive decision to halt all native non-EVM transactions. This action serves as a critical protective measure while the project finalizes its comprehensive remediation plan. The primary objectives of this halt are twofold: to prevent any further asset losses from accounts that may be vulnerable and to effectively restrict the movement of any stolen ZIL through the native transaction channels of the blockchain.
A significant challenge arising from this vulnerability is that even a standard transfer transaction cannot adequately protect affected accounts. If a private key can already be reconstructed from publicly available on-chain data, an attacker who possesses the same key can detect and potentially "front-run" any user’s attempt to move their assets. This means that independent attempts by users to safeguard their funds by initiating transfers might prove ineffective and could inadvertently increase their risk exposure. In stark contrast, EVM transactions on the Zilliqa network continue to function without interruption, providing a degree of continuity for users engaged in those activities.
Charting a Path Forward: Remediation Plan and User Guidance
Zilliqa is currently working in close coordination with Ledger to prepare a fixed build of the Zilliqa Ledger application. This updated version will rectify the nonce generation process, ensuring that the application can no longer create weakened signatures in the future. However, it is crucial for users to understand that this software patch cannot undo the risk associated with private keys that have already generated the requisite number of affected native transactions.
For keys belonging to the compromised group, the ultimate solution involves retiring them from further use. Zilliqa is in the final stages of developing a comprehensive remediation plan designed to safeguard the balances held within associated accounts. The project has pledged to publish separate, detailed instructions specifically for users who have signed native Zilliqa transactions using their Ledger devices. Until these official instructions are disseminated, users are strongly advised against taking independent actions to secure their assets. Instead, they are urged to strictly monitor Zilliqa’s official communication channels for guidance.
In a significant development that aided in the investigation, Zilliqa has publicly credited KuCoin for its assistance. The exchange played a vital role in identifying the root cause within the Ledger app’s nonce generation mechanism, assisting in the recovery of affected private keys by analyzing on-chain data, and confirming the ongoing nature of exploitation activities. While KuCoin’s contribution has been acknowledged, Zilliqa has not officially confirmed whether KuCoin was the specific exchange partner that experienced the initial ZIL theft reported in its initial announcement. This collaboration underscores the importance of industry-wide cooperation in addressing systemic security threats within the blockchain ecosystem. The incident serves as a potent reminder of the continuous need for vigilance, robust security protocols, and transparent communication within the cryptocurrency space.
