Zilliqa has suspended native, non-EVM transactions across its network after engineers uncovered a Zilliqa signature vulnerability that lets an attacker reconstruct a wallet’s private key from as few as five signatures produced by that same key. For anyone holding ZIL outside of exchange custody, this is not a routine bug notice — it changes what counts as a safe response, since the usual instinct to simply move funds to a fresh address does not, by itself, remove the exposure. Traders should understand how the flaw works and why migration needs to be handled carefully before touching any wallet tied to the affected signing path.
What Happened
The issue sits specifically in Schnorr signatures generated for native Zilliqa transactions signed through the Zilliqa Ledger app — it does not touch EVM-compatible transactions on the network, and it does not implicate Ledger’s secure-element hardware or the Schnorr signature scheme itself. Zilliqa’s team has described the flaw as an implementation weakness in how signature data was produced for this specific transaction path, one that appears to have existed for roughly seven years without being caught by prior review.
Once researchers confirmed that a handful of signatures from the same key could be enough to leak the underlying private key, the project moved to pause native transaction processing as a containment step rather than let exposure accumulate while a permanent fix was built. That suspension is a blunt instrument, but it buys time to design a migration process that does not itself become the vector for loss.
What It Means for Traders
The mechanics here matter more than the headline. An attacker who has already collected around five signatures tied to a single key can reportedly rebuild that key in seconds, using nothing more exotic than the signature data already visible on-chain from prior activity. That is a meaningfully lower bar than most cryptographic attacks, and it means the vulnerability window is not theoretical for wallets with any transaction history on the affected path.
This is also why the obvious fix — sending everything to a new wallet — is not automatically safe. Signing that transfer produces one more signature from the same compromised key, potentially the final piece an attacker needs. Anyone holding ZIL through the affected signing method should wait for official migration guidance rather than improvising a move, and should treat any wallet with several prior native transactions as higher risk than one with few or none. The pattern also lines up with what security researchers have been warning about more broadly: signature and key-handling weaknesses are exactly the kind of soft target that a wave of crypto-focused malware campaigns has been built to exploit, since harvesting leaked signature data requires no direct breach of an exchange or custodian.
The Bigger Picture
Zilliqa’s disclosure fits a wider pattern this year of implementation-level flaws surfacing in places that had gone unexamined for years — the code was old, the assumption of safety was inherited rather than tested, and the exposure only became visible once someone looked closely at the signing path itself. It echoes the reasoning behind projects building wallet-level privacy tooling to limit how much on-chain signature and transaction data is exposed for profiling in the first place, since less exposed data means less material for exactly this kind of key-reconstruction attack.
It also reinforces a lesson that keeps repeating across the industry: infrastructure-level failures, not just front-end hacks or social engineering, remain a persistent source of losses, from the fallout tied to the Drift protocol exploit and related USDC litigation to signing bugs like this one. Hardware wallets and secure elements protect a key once it is generated correctly, but they cannot compensate for a flawed signature scheme sitting upstream of them. Non-EVM chains that rely on custom signing implementations, rather than battle-tested EVM tooling, may warrant the same level of scrutiny that Ethereum-adjacent infrastructure has already been through.
For now, the practical takeaway is patience: native Zilliqa transactions remain paused, a fix and migration path are being developed, and traders holding affected wallets are better served waiting for verified guidance than acting on assumptions about what counts as a safe transfer.
This article is informational only and does not constitute financial advice.
