KoinlyticsBetween July 21 and July 22, 2026, two independent wallet infrastructure providers on two different chains disclosed the same class of cryptographic bug. Zilliqa's official Ledger app had shipped Schnorr signatures with the top 64 bits of every nonce hard-coded to zero, from the first release in 2019 through the version live in July 2026. SecondFi, a Cardano-native wallet, had derived Ed25519 nonces from the public transaction hash and never mixed the secret key into that derivation. Between June 21 and June 23, 374 SecondFi wallets were drained for 16.1M ADA, roughly 2.4M dollars. Native ZIL transactions from Ledger devices were halted on July 21 pending a fix.
Neither of these bugs is a smart contract bug. Neither involves a bridge, an oracle, a governance takeover, or an admin key. Both sit in the signing code on the user side of the wallet, in a routine that a smart-contract audit historically does not read. That is the interesting part of the story, and it is the part the wire headlines are missing.
What a signature nonce is, and why breaking it leaks the private key
Every modern signature scheme used in crypto (ECDSA, Schnorr, EdDSA) works by combining the signer's private key with a fresh per-message secret number called a nonce. The nonce is not a password. It is a single-use random-looking value that gets folded into the math so that two things happen at once: the resulting signature can be verified with the public key, and the signature does not reveal the private key.
The security of the whole scheme depends on that nonce being unpredictable to anyone but the signer, and never reused. If the nonce is fixed across signatures, an attacker can solve a small linear equation and recover the private key from two signatures. If the nonce is partially known, for example if the top 64 bits are always zero, the attacker has a harder but still solvable problem called the Hidden Number Problem. A handful of signatures plus a lattice reduction step (LLL, BKZ) recovers the key. Five to a few dozen signatures is a common threshold in the academic literature. If the nonce is derived from the public message with no secret input, then anyone with the message and the signature can literally recompute the nonce and read the key straight off the signature equation.
The correct recipes are boring and well published. RFC 8032 tells you exactly how to build an Ed25519 nonce: hash the secret key material together with the message. RFC 6979 gives the deterministic recipe for ECDSA and Schnorr: hash the private key with the message under HMAC. When a wallet implementer improvises here instead of following the RFC line by line, the failure mode is not that the signature is a bit weaker. The failure mode is that every signature ever produced by that code is a public advertisement of the private key.
Zilliqa and SecondFi, side by side
Zilliqa's Ledger app used Schnorr signatures. The nonce was constructed with the top 64 bits fixed at zero and only the lower bits sampled. That is enough leakage to make the Hidden Number Problem tractable. Anyone who could observe five or more signatures from the same address on the public chain, which is trivially anyone, could in principle run a lattice attack and recover the key. The bug was present in every released version of the app from 2019 through July 2026. The immediate mitigation was to halt native ZIL signing on Ledger and route users through the EVM-compatible path while a corrected build is prepared.
SecondFi's Cardano wallet used Ed25519. The nonce derivation took the transaction hash as input, which is fine, but omitted the secret key from the hash, which is the entire point of the RFC 8032 construction. Every signature the wallet had ever produced silently leaked enough entropy to solve the signature equation for the private key. Between June 21 and June 23, an attacker did exactly that and drained 374 wallets for 16.1M ADA. Beosin's post-incident investigation traced the root cause to the nonce derivation code, and the wallet operator has announced it will wind down.
Two chains. Two signature schemes. Two independent teams. Same failure class: broken nonce generation on the client side, leaking private keys through data that is already public.
This is not a new bug. It keeps coming back.
In 2010, Sony's PlayStation 3 was broken because the firmware signing code used a constant ECDSA nonce. Two signatures were enough to recover the master signing key, and the console's chain of trust collapsed. In 2013, a batch of Java-based Android Bitcoin wallets lost funds because Java's SecureRandom on Android was seeded weakly, so ECDSA nonces collided across signatures. The same class of bug resurfaces every few years in a new implementation, because implementing a signature nonce is deceptively subtle and the failure mode is invisible until keys start moving.
The pattern is consistent. The underlying math is a solved problem, the RFCs are decades old, and the bug lives entirely in the code that turns those RFCs into a shipping wallet. That code is where Zilliqa and SecondFi both failed.
What a standard audit does not cover
A conventional smart-contract audit reads on-chain code: the token contract, the router, the vault, the governance module. It does not typically read the wallet's local signing binary, does not verify that a released Ledger app matches the source it claims to match, and does not run deterministic test vectors against the nonce derivation to check for structural leakage. There is no ecosystem-wide practice of enforcing the RFC 6979 or RFC 8032 test-vector suites against released wallet builds, and no standard practice of publishing lattice-attack resistance parameters for a given signer.
That is the gap. As on-chain contract quality has improved, attackers have moved down the stack. In 2026 the top DeFi attack vector by incident count is compromised keys, and client-side signing bugs are emerging as a distinct third category alongside key compromise and oracle takeovers. Zilliqa and SecondFi are both examples of that third category.
What to ask your signer
Whether you use a hardware wallet, a browser extension, a mobile wallet, or a custodian, the useful questions are narrow. Is nonce derivation deterministic per RFC 6979 or RFC 8032, and can you point me at the exact function in your published source? Do you run the RFC test vectors in CI and publish the result? Is the released binary reproducible from that source? Has the signing code specifically, not just the on-chain contracts it interacts with, been audited by someone competent in lattice cryptanalysis? Have you published a same-key signature count threshold below which you consider a lattice attack infeasible, and what is that number?
A signer that cannot answer those questions is not necessarily broken. It just cannot prove it is not. Zilliqa's Ledger app and SecondFi's Cardano wallet could not have answered them convincingly either.
What Koinlytics tracks: We treat client-side signing bugs as a separate incident category from smart contract exploits and from operational key compromise. Every disclosure in this class gets tagged with the signature scheme, the specific nonce failure mode, the number of affected signatures required for key recovery, and the on-chain drain size where applicable. Our 90-day watchlist covers every wallet and hardware signer that has not published deterministic-nonce test vectors against its released build.