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 2¹⁹².

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.