The Wallet Did the Stealing. SecondFi Shut Down Forever This Week Because Every Signature Its Users Ever Made Handed Their Private Key to Anyone Reading the Blockchain.
On July 22, 2026, EMURGO announced that SecondFi — the wallet it launched in April as the successor to Yoroi, the lightweight client that had served more than a million Cardano users since 2018 — will never reopen. Not paused for audits, not relaunching under a new name: permanently closed, with the company's remaining role reduced to "a dedicated asset recovery team, tasked solely with returning assets to affected users." The exploit that killed it ran for just two days, June 21 through 23, and drained 16.1 million ADA — roughly $2.4 million at the time — from 374 user wallets, while the SecondFi team raced to sweep another 129 million ADA out of reach of the attackers. Blockchain intelligence firm Groom Lake found the primary attacker's fingerprints consistent with North Korea's Lazarus Group, the operation TRM Labs says accounted for 76% of all crypto hack value in the first four months of 2026. But the attribution is a footnote. The mechanism is the story, and it is the purest demonstration yet of a truth this blog keeps circling: the cryptography is never the thing that fails. The thing that fails is everything wrapped around it.
Here is what broke, stated as plainly as the mathematics allows. When wallet software signs a transaction with Ed25519 — the signature scheme Cardano uses — it must generate a per-signature secret called a nonce, derived from the transaction data combined with secret key material held on the device. That combination is the entire trick: it makes each signature unique and mathematically unrelated to the private key, which is why you can publish signatures to a public blockchain all day without revealing anything. SecondFi's Android update of June 8 shipped a signer that computed the nonce from the public transaction hash alone, omitting the secret ingredient entirely. The result inverted the guarantee. With the nonce computable by anyone, a single published signature becomes a simple algebra problem whose solution is the private key. Security researcher Charles Guillemet demonstrated it publicly — pulling signatures off Cardano's mainnet and reconstructing private keys from nothing but on-chain records. No device was hacked. No server was breached. No user was deceived. The attackers simply read the blockchain, which is to say: the wallet had been quietly publishing its users' keys, one transaction at a time, and calling it self-custody.
Sit with what that means for the victims, because it is a new kind of unfixable. When a backup is photographed, you can move the funds before the thief acts. When a database leaks, you can rotate credentials. But these signatures live on Cardano's permanent, immutable ledger — there is no delete function on a blockchain — so the affected private keys are reconstructible from public data forever. That is why EMURGO's recovery guidance contains a warning most people will find deeply counterintuitive: do not restore your seed phrase into a different wallet. It will not help. The compromised entity is not the app; it is the address itself. Migrating the same keys into the most audited, most reputable wallet on earth changes nothing, because the leak already happened in public and cannot be unpublished. The only exit is total: abandon the address, generate fresh keys in clean software, and move the funds — carefully, since even the rescue transaction broadcasts one more signature that a waiting attacker can race.
If this were one team's blunder, it would be a cautionary tale about unaudited code — and partly it is: an investigation by a competing firm alleges SecondFi swapped Cardano's audited Serialization Library for a third-party signing library no independent auditor had reviewed, which is what security veterans mean by the phrase "rolling your own crypto." Taylor Monahan called the implementation worse than the wallet bugs of Bitcoin's 2011 infancy. But the same day SecondFi announced its closure, Zilliqa disclosed a structurally identical vulnerability that had lived undetected since 2019 — inside the official Zilliqa app for Ledger hardware wallets. A buffer-copy error zeroed the top 64 bits of every signing nonce, weakening it enough that an attacker holding roughly five of a wallet's public on-chain signatures could recover the private key in seconds with lattice mathematics on commodity hardware. KuCoin confirmed it independently recovered real keys from public data during its investigation. Five years, on a hardware wallet's companion app, in a flaw class cryptographers have known since a weak nonce exposed the PlayStation 3 master key in 2010 and drained Android Bitcoin wallets in 2013. Two disclosures, one day, same root cause. This is not an anomaly. It is a class.
The uncomfortable lesson for self-custodians is that "not your keys, not your coins" is a true slogan with a silent dependency. SecondFi's users held their keys. What they could not hold — could not even inspect — was the signing code exercising those keys on their behalf. Self-custody's security model quietly assumes the software between your seed and the chain is computing its cryptography correctly, and that assumption is unverifiable for almost everyone, almost all the time. This blog's running framework is that a secret has a lifecycle: generation, where Ill Bloom's weak randomness struck; storage, where drawers and cameras and wrenches strike; and use, the brief moments the secret does work. The SecondFi flaw is a use-layer failure of the worst kind, because it converted every legitimate, careful, by-the-book use into a disclosure. The victims did not slip once. The software slipped for them, every single time, in public.
Honesty first, as always: threshold custody cannot fix a broken signer. If the software signing your transactions leaks key material into the signature itself, it does not matter how well your seed phrase was generated or how carefully its backup is split — the key escapes through the front door while the backups guard the back. Anyone who tells you their storage product would have saved SecondFi's users is selling something. What the practical defenses actually look like: prefer signing implementations that are audited, open-source, and boring — the battle-tested libraries, the hardware signers running scrutinized firmware — and treat a flashy rebrand or a rushed release cycle as the risk signal it is. Keep long-term holdings in addresses that transact rarely, because both of this week's flaws were fed by signatures, and the wallet that signs once a year publishes one clue while the wallet that signs daily publishes hundreds. And diversify the layers you cannot verify, so that one vendor's mistake is not simultaneously your generator, your signer, and your backup.
But there is a place where this story lands squarely on architecture you control, and it is the same place Ill Bloom landed three weeks ago: the migration. Right now, hundreds of SecondFi victims — and every prudent user of the affected apps — are doing the one thing EMURGO says they must: generating brand-new seeds and moving everything. A migration under pressure is the most exposure-dense moment in the life of a wallet. The new phrase gets scribbled on the nearest paper, photographed "just for now," typed into a second app to double-check — recreating, in one stressed evening, the single complete copy that every storage-layer attack this blog has ever covered depends on. The flaw that forced the migration was unpreventable by the user. The architecture of what comes next is entirely theirs. A new seed, generated on trustworthy hardware, can be encrypted and split under a threshold scheme — say 3-of-5 — so the complete phrase stops existing anywhere the moment the backup is made, and no single share lost in the scramble reveals information-theoretically anything.
seQRets lives at exactly that layer, and the boundary deserves stating plainly: it cannot audit a signing library, patch a nonce, or unpublish a signature — the use layer belongs to your wallet software, and this week that layer failed people who did nothing wrong. What seQRets does is make sure the layers you do control are not waiting to fail next: your encrypted seed phrase, split into QR-encoded threshold shares, distributed across the people and places you choose — no servers, no accounts, no single copy for the next flaw's cleanup crew to catch in the open. This week proved the signature can betray the key. That is precisely one layer too late for storage to save. For everyone now starting over with a fresh seed, it is also the reason the new one should never exist whole again.