In late June, SecondFi — the Cardano wallet that grew out of Yoroi — made headlines across the ecosystem. No smart contract was drained. No private keys were stolen off a device. There wasn’t even a phishing campaign. The attackers simply read the blockchain. Within three days, roughly 16 million ADA (about $2.4 million at the time) vanished from 374 wallets, and the team urgently moved another ~129 million ADA to a third-party custodian as a rescue measure.

The most telling part was the official warning: “Do not restore your recovery phrase into another Cardano wallet.” Normally wallets are only switched after a seed leak. Why the opposite advice this time?

Because this time, the wound was in the signature.

A signature that got wounded

Cardano uses Ed25519 signatures. To understand what went wrong, first look at how a signature is produced:

flowchart TB
    A[Transaction hash M] --> C
    B[Secret key material kR<br/>must stay secret] --> C
    C["nonce r = SHA-512(kR || M)<br/>secret and unpredictable"] --> D[Signing]
    E[Private key] --> D
    D --> F[Signature → permanently on-chain]

A signature is protected by a per-signature secret — in Ed25519 it’s the nonce r, and it must be both secret and unpredictable. In a correct implementation, r is derived from the secret key material combined with the transaction hash, so no outsider can compute r and work the private key back out of a public signature.

SecondFi’s Android build (the 10.0.3 update from June 8) made a fatal mistake: it derived r from the public transaction hash alone, dropping the secret key material entirely:

flowchart TB
    A[Public transaction hash M] --> C["nonce r = SHA-512(M)<br/>publicly computable!"]
    C --> D[Signature → permanently on-chain]
    D --> G[Anyone can recover the private key]

The math made it a certainty: if an address had ever signed one transaction on-chain, anyone could compute the nonce from the public data and then recover its private key. No phone compromise, no second signature needed — just public blockchain data. A security researcher demonstrated rebuilding private keys live from mainnet signatures, and the community compared it to the worst of the early-2010s Bitcoin wallet failures.

And signatures stay on-chain forever. There is no delete button. Once a key is exposed, it’s exposed permanently.

Why randomness is so important

You might think: this isn’t a randomness problem, it’s a code bug. Right — but this class of bug is fatal precisely because cryptography demands unpredictability.

Both Ed25519 and the far more common ECDSA (used by Bitcoin and Ethereum) rest their signing security on a per-signature secret that no one else can predict:

• ECDSA uses a random number k. If k leaks, the private key d can be solved directly; if k is reused twice, two signatures can be combined to solve for d.
• Ed25519 derives r deterministically, but the derivation must mix in secret material. Omit it, and r is effectively public.

This isn’t theory. Sony’s PS3 had its signing key exposed in 2010 because k was hardcoded to a constant. In 2013, a batch of Android wallets had private keys derived out of weak system randomness. SecondFi is a new casualty on the same front — this time the problem wasn’t even weak randomness, it was that the secret material never participated at all.

Nor is this an isolated case. On the very day SecondFi announced its permanent closure, Zilliqa disclosed a structurally identical nonce vulnerability in its Ledger app: a buffer-copy error in the signing routine zeroed out the top 64 bits of every nonce, slashing the entropy so far that an attacker could reconstruct a private key from about five on-chain signatures. One bug needed a single signature, the other five, but the essence is the same — when nonce entropy fails, the private key is lost.

In one sentence: a signature’s private key lives or dies on that single unpredictable value. Anything that makes it public or computable hands the key over.

Why cold wallets survived

The most important detail of this incident: users on hardware wallets (cold wallets) were essentially unaffected. SecondFi implemented signing inside its own app, while hardware wallets run a completely separate signing path — the private key, nonce derivation and signing math all happen inside the device’s secure chip, with audited randomness and implementations.

Look at the software-wallet side and the risks line up:

• Uncontrollable randomness. A wallet runs on a general-purpose OS; once the system RNG is polluted or tampered with, signatures can no longer be trusted.
• Signing libraries can be swapped. SecondFi bypassed the ecosystem’s audited open-source signing library for a custom, unaudited implementation — that’s where the bomb was planted. A bad signing routine can slip into a software update with users none the wiser.
• Keys and randomness sit on the same connected device. Compromise the device, and it’s all over.

Long-term holders: don’t trust software-wallet randomness

For anyone planning to hold crypto long term, my advice is blunt: don’t trust the randomness of any software wallet, and don’t let signing happen on a connected device.

Keys generated in hardware, signatures made in hardware, transactions confirmed one by one on the device’s screen — that’s where the “moment of signing” should happen. A cold wallet is the closest ordinary users can get to being their own last line of defense.

The SecondFi incident had no complex attack chain — it was one missing line that kept the secret out of the nonce. And that kind of “missing line” is exactly what’s hardest to guard against in the randomness and signing implementations of software wallets.

Article Link: