Post-mortem: legacy Schnorr nonce bias

In what follows, G is the fixed generator point of the secp256k1 curve, n is the order of the group it generates, and a private key d has public key P = d·G.

Zilliqa's native scheme computes, for a private key d with public key P, a nonce k and its commitment Q = k·G:

r = SHA256( compress(Q) || compress(P) || message ) mod n
s = k - r*d mod n

The defect fixes the high 64 bits of k at zero, so k < 2^192 for every signature the application produced. Rearranged, each signature is an instance of the Hidden Number Problem: a linear relation in the unknown d whose error term is known to be small. Four or more such relations, assembled into a lattice and reduced, recover d exactly.

Two properties of the scheme made this far more dangerous than the equivalent flaw in ECDSA:

• The challenge value is a hash, not a point coordinate. In ECDSA the challenge derives from the nonce, so nonce reuse produces a duplicate value and is trivially caught by scanners that many chains run as a matter of course. Here it derives from the message instead, so nonce reuse and nonce bias are invisible to duplicate-value scanning. Nothing routine would have caught it.
• The published signature value is indistinguishable from random. Because r*d mod n is uniform, the value s written to the chain carries no visible trace of the bias. There is no per-transaction test for this defect. The only way to determine whether an account is affected is to attempt the key recovery: the detector is the attack. This shaped the entire response, and it is why an address checker had to be built rather than a filter applied.

Because no passive indicator exists, exposure had to be established constructively: an account is affected if and only if its signatures yield a candidate private key d satisfying d*G == P against its on-chain public key. That test is exact, so the resulting population contains no false positives by construction: a listed key regenerates its own public key, and the probability of a spurious match is negligible. During the original reproduction, the probability that the observed nonce bit-length alignment could arise under an incorrect d was approximately 2^-832.

The scan ran across both eras of chain history:

The bulk scan treated as a candidate any account with at least five native signatures in a single era. Four is the true floor, so accounts with exactly four were never tested; annex D records what that costs. Recovered keys were held in memory only, checked against the public key, and discarded. None was ever written to disk.

Assurance. The method was validated against a negative control and against a known-compromised account before any population figure was produced. The strongest independent check came from the late-era recovery described in annex E: of the accounts it identified, 2,158 reproduced keys that had already been recovered by a completely different route, from different columns of different data, which is a stringent confirmation that both the method and the data interpretation are correct.

The theft figure follows from one property of the compromised accounts: the affected application produced only biased nonces. A recovered key makes the nonce of every one of that account's transactions computable, and therefore classifiable as biased or full-width. A full-width nonce from such an account means a different signer, and the only other party holding the key is the attacker.

This is a cryptographic identification rather than a behavioural one. It does not depend on transaction value, timing, destination or clustering, which means it neither misses a quiet theft nor sweeps in a legitimate transfer that happens to look suspicious.

Every transaction of every compromised account was classified this way, across both eras and including failed transactions, producing a 99,121-row dataset from which the 88 non-biased transactions were extracted. Of those, the 66 successful transactions in the 2026 window constitute the published figure.

One figure only. The consolidation wallets also received value from senders proven not to be biased-nonce victims, so their total inflow is larger than the theft. Only the 683,130,969.66 ZIL is proven theft attributable to this defect, and no larger number should be quoted as such.

550,558,587.25 ZIL, about 80.6% of the proven theft, is traced to a single exchange receiving wallet. All 21 cash-out transactions were verified directly against a Zilliqa 2 archive node: every one present, successful and on the canonical chain.

128,999,998.66 ZIL, about 18.9%, cannot be followed. It entered an address with more than 1,400 distinct senders and more than 800 destinations on 20 July. In an account-based ledger, value entering an address with that many contributors becomes indistinguishable from the rest of its balance. This is a limit of the account model, not of effort, and no amount of further analysis will resolve it.

Two points of method, because they change how the figures should be read:

• The wallets that received the funds are exchange infrastructure, not attacker storage. This was tested rather than assumed: the receiving wallet has years of pre-incident history, tens of thousands of distinct counterparties, and depositor and withdrawer sets that barely overlap. Attacker control of it is excluded.
• We are not naming venues in this document. Attribution of specific wallets to specific exchanges is being handled directly with those exchanges, where it can be confirmed or disclaimed by the only parties with the records to do so. Every attribution available to us rests on a single report whose basis has not been disclosed, or on an explorer's label. Publishing either as fact would not meet the standard the rest of this document is held to.

What no chain analysis can produce is the attacker's identity. The account credited inside an exchange is off-chain, exists only in that exchange's ledger, and is resolvable only by the exchange, from the specific transfers we have supplied.

Four limits are known. Each can only cause the investigation to understate the incident, never to overstate it.

• The signature floor, and the scan's candidate rule. An account with three or fewer biased signatures cannot be attacked, and equally cannot be tested: it is absent from the count for the same reason it is safe. But the bulk scan only considered accounts with five or more signatures in a single era, while the true floor is four. Accounts with exactly four biased signatures were therefore never candidates and are missing from the population figure, even though their keys are recoverable. The per-address checker reports them correctly; the bulk scan never saw them.
• A finer search finds more. The per-address checker, which uses tighter signature windows and no scan cap, recovered a key that the bulk scan had missed. The population figure of 6,760 is therefore understated by an unknown amount, and re-running the bulk scan under the checker's parameters is outstanding work.
• The historical archive is incomplete. Some early-era transactions that are visible in public explorers were never ingested into the archive the scan reads. This still blocks key recovery for nine of the twelve accounts that were provably drained.
• The chain-wide search for further collection wallets is open. It has not been closed out. What has been done is an adversarial check of the existing conclusion: 7,173 inflows to known attacker addresses, 742 candidate collection wallets, and 2,162 accounts never previously scanned were all re-examined, and found zero missed theft transactions and no fourth collection wallet. That is strong evidence the picture is complete; it is not proof.

Against these, one figure is not a floor but an exact accounting: the 683,130,969.66 ZIL is the complete set of attacker-signed transactions from the accounts we know to be compromised. If the compromised population grows, the theft figure can grow with it.

We would rather publish a number that can only move upward than an estimate that could move either way.

Two independent defects in Zilliqa's own historical data archive materially slowed the identification of affected accounts. Both are being reported for repair, and both are worth publishing, because between them they are the reason the exposed population grew from 4,610 accounts to 6,760.

Corrupted signature columns in the late Zilliqa 1 era. About 40% of legacy signature history was ingested through a path that mangled the signature, public key and sender-address columns: none of the stored public keys even carried a valid compressed-point prefix. No parser can read a valid signature out of corrupted bytes, so 60,819 candidate accounts were silently unscannable, and the gap was initially misread as a coverage limitation of the scanning tool. The genuine signature values survived intact in two different columns of the same table. Recovering from those columns identified 4,308 further biased accounts, of which 2,150 were new and 2,158 confirmed keys already known.

Incomplete ingestion of the early era. Separately, some early transactions visible in public explorers are absent from the archive entirely. Where an account's history is split across both problems, too few of its signatures are retrievable for the lattice to run. This is what blocks nine of the twelve provably-drained accounts. It is a data-availability gap, not a limitation of the method: a complete archive would recover all twelve.

The practical lesson is that an incident response can be bounded by the integrity of your own historical data long before it is bounded by cryptography, and that the failure mode is quiet. Both defects presented as "the scan does not cover this", which is exactly what a tooling limitation looks like.

Every figure in this document derives from public chain data and is reproducible from the incident datasets held in the private forensic workspace. The theft figure and its breakdown are regenerated by a single command against the transaction proof list. The exposed-account population is regenerated by re-running detection against the two chain archives.