KoinlyticsZilliqa halted all native, non-EVM transactions on July 21, 2026 after confirming that every released version of its Ledger app, going back to 2019, generated cryptographic signatures with a defect that lets an attacker recover the signer's private key from as few as five on-chain signatures. This is not a smart-contract bug, not a validator bug, not a bridge exploit. It is a client-side signing bug in the wallet code, and it has been silently leaking entropy for close to seven years.
What actually broke
Zilliqa native transactions are signed with a Schnorr scheme. Every Schnorr signature requires a fresh, uniformly random ephemeral nonce, usually called k. The security of the entire scheme depends on k being unpredictable and unrelated between signatures. If k is biased, reused, or partially known, the private key is no longer safe.
The Zilliqa Ledger app was generating that ephemeral nonce with the highest 64 bits fixed at zero. In other words, instead of drawing k uniformly from a 256-bit space, it was drawing from a 192-bit space and pinning 64 zero bits on top. Every native ZIL signature produced by a Ledger device since 2019 carries this defect.
A 64-bit reduction of the nonce space is not a rounding issue. It is a catastrophic loss of entropy in the one value that must be perfectly random for Schnorr to be secure. The attack surface it opens is not brute force. It is a lattice attack.
The Hidden Number Problem and the lattice attack
When part of the ephemeral nonce k is known or fixed, recovering the private key becomes an instance of the Hidden Number Problem, a well studied problem in cryptanalysis first formalized by Boneh and Venkatesan in 1996. The setup is simple to state. For each signature, the attacker knows the public data, meaning the message and the signature components, and knows that some bits of the nonce are fixed. The private key is the unknown that ties all of those signatures together.
Each signature gives the attacker one noisy linear equation modulo the curve order, where the noise is bounded because the top bits of k are known. Collect enough of these equations and the private key sits inside a lattice as an unusually short vector. Standard lattice reduction algorithms, LLL and BKZ, find that short vector in seconds on a laptop.
For 64 known bits per signature on a 256-bit curve, published results on ECDSA and Schnorr variants show that around five signatures are sufficient to solve the lattice reliably. That is the threshold Zilliqa has publicly acknowledged. Any Zilliqa address that has broadcast five or more native transactions signed by a Ledger device between 2019 and 2026 must be treated as an address whose private key an attacker can reconstruct from public chain data alone.
Timeline and scope
On-chain behavior consistent with active exploitation was observed on July 19, 2026. The root cause in the Ledger app was confirmed on July 21, and native, non-EVM transactions were halted the same day as a protective measure. A corrected build of the Ledger app has been prepared, but the fix only prevents future leaks. It cannot retroactively protect a key whose signatures are already sitting on chain.
The scope is narrow but sharp. EVM transactions on Zilliqa are unaffected, because they are signed through a different path. Non-Ledger SDKs and hot wallets are unaffected, because the defect lives in the Ledger app code, not in the protocol itself. What is affected is every native ZIL address that a Ledger user has ever signed a native transfer, stake, or delegation from. Upbit has already flagged ZIL as a cautionary asset while the situation is contained.
What a Zilliqa Ledger user should do right now
Treat any Zilliqa address that a Ledger has signed five or more native transactions from as compromised, whether or not funds have moved yet. The order of operations matters, because signing anything from the old address to try to rescue funds is itself the risk.
First, generate a completely fresh Zilliqa address on a device or seed that has never been used for native ZIL signing with a vulnerable Ledger app build. Second, wait until the fixed Ledger app is officially released and installed. Third, from the fixed app, sweep funds from the exposed address to the new fresh address in a single transaction if possible. Do not stake, do not delegate, do not interact with contracts from the exposed address for any reason other than the sweep. Every additional signature from a still-vulnerable device adds another equation to an attacker's lattice.
Do not reuse the exposed address afterward. Even if funds are moved out cleanly, the private key remains recoverable from historical signatures, and any deposit sent back to that address is effectively a deposit to whoever solves the lattice first.
What Koinlytics tracks: Koinlytics monitors client-side cryptographic incidents across the wallets, hardware devices, and signing libraries used by the assets in your portfolio, and flags exposure at the address level when a signing defect like this one is disclosed. When a nonce-generation bug turns a cold-storage assumption into a public-chain key leak, portfolio hygiene stops being about balances and starts being about which addresses ever touched the vulnerable code path.