Zilliqa points to hardware wallet flaw discarding entropy to expose crypto keys, enabling 683M ZIL theft

Four biased signatures could reveal a private key; the wider scan counted only accounts with at least five.

Zilliqa says a Ledger bug exposed 6,772 accounts and led to 683.13 million ZIL in proven theft.

A recent Zilliqa Ledger bug exposed at least 6,772 accounts, according to the post-mortem, and enabled the theft of 683,130,969.66 ZIL across 66 successful attack-window transactions. The disclosure turned an earlier unquantified security flaw into a measured loss and exposure record while, as of the same date, legacy transactions remained paused and holders faced an undated migration to Zilliqa EVM.

The figures measure different parts of the incident. Zilliqa separates 51 drained accounts from the 6,772 accounts whose private keys were shown to be exposed. The post-mortem leaves the number of affected people unquantified.

The exposed-account total is a floor. The 683.13 million ZIL total is exact for the compromised accounts currently known, according to the post-mortem, and it could rise if investigators prove that additional compromised accounts produced theft transactions.

Why four signatures matter

Zilliqa said the application generated 40 random bytes but copied the wrong 32 bytes into its signing buffer, retaining eight bytes of zero padding and discarding eight bytes of entropy. That forced the high 64 bits of every affected nonce to zero.

Four or more biased signatures produced by the legacy Ledger application for the same account could then allow an attacker to reconstruct its private key from public blockchain data in seconds on ordinary hardware, according to Zilliqa. Already-published signatures cannot be withdrawn, so correcting the application can protect new keys but cannot repair keys already exposed.

The bulk scan behind the published count required at least five native signatures in a single signer era. The mathematical exposure floor is four biased signatures. Accounts with exactly four signatures were therefore absent from the bulk population count. Zilliqa's live per-address checker uses tighter parameters and reports four-signature cases, while re-running the wider scan under those parameters remains outstanding.

The Daily Brief The signal, before the noise. Start your day with the crypto stories moving markets, decoded by CryptoSlate’s editors. One email. Everything that matters. Email address Join free Free to join. Unsubscribe any time. Whoops, looks like there was a problem. Please try again. You’re on the list. Your next Daily Brief is on its way.

Zilliqa's historical reconstruction dated the first proven theft to March 4. KuCoin reported anomalous outgoing transactions from one of its cold wallets on July 19, roughly four and a half months later. On July 20, the attacker's last transaction came at 09:19:09 UTC, and Zilliqa disabled legacy transactions around 12:59 UTC.

The post-mortem also split responsibility among the companies. Zilliqa said it wrote the original affected application implementation, while the flaw survived years of maintenance under Ledger without either party finding it. KuCoin's report exposed the active incident.

The Zilliqa Ledger bug is limited to the application's legacy, non-EVM signing path. Zilliqa EVM activity, recovery phrases, assets held on other blockchains through the same device, and listed software-wallet signing paths are outside the disclosed scope.

Zilliqa's Aug. 20 status update said recovery would use migration of every legacy holder to Zilliqa EVM, with the legacy side retired. It had not announced a migration-tool launch date because timing still depended on an external security audit, review of its findings and any required remediation. Asset tracing and exchange coordination were continuing.