Zilliqa has suspended native transactions after discovering that roughly five affected signatures from the same private key may provide enough information to reconstruct that key, creating a recovery problem that an ordinary transfer cannot safely solve.
The vulnerability is confined to Schnorr signatures generated for native, non-EVM transactions through the Zilliqa Ledger app, according to the network’s security disclosure. Zilliqa said every version of the app released between 2019 and 2026 contained the flaw.
Zilliqa said it detected on-chain activity consistent with active exploitation on July 19 and confirmed the root cause on July 21. The disclosure did not identify affected addresses or quantify any losses.
Public signatures can expose the private key
The flaw occurred while the Ledger app generated the ephemeral nonce required for each native Zilliqa signature. The signing routine generated 40 bytes of randomness and reduced the result modulo the secp256k1 curve order, but then copied the wrong 32-byte range into the nonce buffer.
That operation retained eight zero-padding bytes while discarding eight bytes of actual entropy, fixing the nonce’s highest 64 bits at zero and leaving each value below 2192.
Zilliqa said an attacker can combine approximately five affected signatures produced by the same private key and use lattice-reduction techniques to reconstruct that key within seconds on commodity hardware.
Any account that has broadcast approximately five or more native transactions signed through the Zilliqa Ledger app should therefore be considered compromised, according to Zilliqa. The weakened signatures remain permanently available on-chain, so updating the app cannot remove the information already exposed. Affected private keys must ultimately be retired.
Zilliqa credited KuCoin with reporting the incident and helping confirm the vulnerability. According to the disclosure, the exchange recovered affected private keys using publicly available signatures and assisted in tracing the problem to the app’s nonce-generation code.
A normal rescue transfer could be front-run
Moving assets to a new address once native transactions resume carries another risk. An attacker who has already reconstructed the private key can also sign a valid transaction and attempt to front-run the legitimate holder’s transfer.
This leaves Zilliqa balancing two requirements before reopening native activity: allowing legitimate users to migrate their assets while preventing attackers with the same signing authority from winning the transaction race.
The network said it was finalizing a coordinated remediation plan and advised anyone who has signed native Zilliqa transactions with a Ledger device to await official instructions before taking action.
Zilliqa suspended native, non-EVM transactions as a protective measure after identifying the vulnerability. The project said the pause halted further draining of affected accounts.
At publication time, Zilliqa had not announced a reopening date or published its final migration procedure through its official channels.
A corrected version of the Ledger app is being prepared in coordination with Ledger and will restore full-width nonce generation. The update can prevent future signatures from exposing the same information, but it cannot secure keys compromised by signatures already recorded on-chain. Zilliqa said release details would be announced separately.
EVM and official SDK signing paths are unaffected
The disclosure does not describe a compromise of Ledger hardware generally. Zilliqa attributed the vulnerability to its Ledger app’s implementation of native transaction signing.
Zilliqa said EVM transactions are unaffected. The nonce-generation paths used by its official zilliqa-js, gozilliqa-sdk, and pyzil software development kits also fall outside the disclosed vulnerability.
