A Missing Nonce Secret Turned SecondFi's Cardano Signatures Into Public Key Leaks

Cardano's biggest wallet application wasn't breached in the conventional sense — it was exposed through math. Between June 21 and 23, 2026, outside attackers pulled roughly 16 million ADA (about $2.4 million) from 374 SecondFi wallets, and in response SecondFi shifted 129 million ADA into a third-party custodian as an emergency safeguard. That move made the platform both the party trying to contain the damage and, in effect, a second point where control of funds slipped away.

There was no smart contract exploit here, no bridge manipulation, no phished developer. Instead, an Android build of SecondFi — version 10.0.3 — shipped a broken Ed25519 signing routine whose per-signature nonce, the secret value meant to keep private keys unrecoverable, was calculated purely from data already visible on-chain.

The implication: a single observed signature was enough for anyone to reconstruct a user's private key. Every transaction a wallet had ever broadcast effectively published its owner's secret key. Nothing needed to be hacked — the chain simply had to be read.

Taylor Monahan described the flaw as worse than wallet vulnerabilities from the Bitcoin ecosystem circa 2011. EMURGO characterized the incident as a sophisticated, pre-planned operation involving multiple actors. EMURGO — which identifies itself as a co-founding organization of Cardano and is listed as the developer of record for SecondFi's App Store entry — has committed to reimbursing every affected wallet address.

But no pledge can retroactively unpublish the signatures already sitting on the ledger from before the first drain occurred. If a single omitted line of code can turn a user's transaction history into a disclosure of their private key, it's worth asking who actually controlled that exposure window.

01A Two-Week Head Start

The publicly acknowledged drain window ran from June 21 to 23, but the vulnerability had been live well before that. On June 12, the holder of address addr1qxvnsf03culvvtjjjlxy795ce2egmfxwhm3m6xsseh0ryd9htk2p24jczmadchrrse20hm4teqn7zf95538ls7fpmsvs8yzfma signed an unremarkable transaction moving close to 1 million ADA. Nothing about it looked unusual at the time.

What that user had no way of knowing: SecondFi's Android 10.0.3 release, pushed four days prior on June 8, contained a defective Ed25519 signer that generated its nonce solely from public transaction data. According to the HackMD writeup analyzing the bug, any single transaction signed through that flawed code path gave an outside observer everything needed to derive the private key from chain data alone. The June 12 transaction itself wasn't the loss event — it was the moment the key became recoverable.

By June 21, automated scripts had begun systematically working through the pool of now-exposed addresses. Two separate attacker groups ultimately hit 374 wallets across three distinct waves. One group — labeled Attacker A — struck 171 addresses in two automated batches, while a second group, Attacker B, cleared out 203 more addresses in its own automated sweep. SlowMist founder Cos, who tracked the draining in real time over roughly 30 hours, noted that whoever was behind it appeared to already hold a pre-collected batch of private keys and simply worked through them continuously, starting with larger balances and moving to smaller ones as the hours went on.

SecondFi's first public acknowledgment came on June 22, framed at the time as a security issue touching a limited number of wallets, and the platform was put into maintenance mode. By the next morning, June 23, the company confirmed the root cause sat in its native Cardano web-wallet key-generation code and gave a preliminary loss estimate near 16 million ADA. A fix for wallets that hadn't yet been compromised was confirmed on June 24.

Then came a fourth, separate action: alongside the three drains carried out by outside attackers, SecondFi disclosed it had moved roughly 129 million ADA into an independent third-party custodian, calling it an emergency measure to get remaining funds out of reach before other attackers could take them. An outside accounting firm was brought in to verify those holdings, though the custodian itself was never named, and no return process had been laid out at that point.

One independent confirmation cut through the company messaging: security researcher Charles Guillemet pulled real signatures from Cardano mainnet and successfully rebuilt private keys from a single on-chain signature each time, with the technique holding across every address he tested — no device compromise, no second transaction needed, no specialized tools, just data already public on the chain.

That left an unresolved question SecondFi never fully addressed: one affected user said their seed phrase originated in Daedalus, was later imported into Yoroi, and only became compromised once that app auto-updated to SecondFi — suggesting the exposure applied to any wallet that had signed through the broken code, no matter where its seed phrase was originally generated. The HackMD analysis backs that interpretation.

If a vulnerability arrives buried in a routine app update, goes unnoticed for two weeks, and the eventual response to a cryptographic break is essentially a promise about custody, how much of the underlying trust model was ever real?

How a Nonce Became Public

Every implementation in the Ed25519 signature family relies on a per-signature secret called a nonce, and that nonce has exactly one requirement: it must stay secret and be unpredictable. Cardano's variant, extended Ed25519, builds the nonce from the transaction body hash combined with a private 32-byte value called kR — unique to each wallet and never exposed publicly. Determinism in the calculation protects against weak random number generation, while the secrecy of kR is what keeps the resulting nonce impossible to guess from chain data alone. Both properties are required; losing either one breaks the scheme.

SecondFi's Android 10.0.3 build simply left kR out of the calculation. Analysis of the decompiled Hermes bundle pulled from the shipped APK showed the signing function computing the nonce as SHA-512(M), with M being nothing more than the public transaction body hash. The secret argument that actually carries the full 64-byte extended key — including kR — only gets used later, at the challenge-computation stage, well after the nonce has already been fixed. kR simply never appears in the part of the code responsible for generating the nonce, and everything downstream follows from that omission.

A signature takes the form (R, s), where s = r + k · kL mod L, with k derived from values already visible in the signature itself. When the nonce is generated correctly, that equation contains two unknowns and can't be solved from a single observed signature. But once the nonce becomes a public function of the transaction body hash, r can be computed by anyone, which immediately isolates kL — the private key. Traditional nonce-reuse attacks typically require two signatures to pull this off. This particular flaw only needed one, meaning every single transaction ever signed through the broken code amounts to a permanent, public exposure of the underlying key.

Notably, the shipped app skipped the standard, publicly audited Yoroi and Cardano Serialization Library stack — which correctly folds kR into the hash alongside the message — in favor of a proprietary implementation. Hardware wallet signing runs through an entirely different code path and was not affected.

A competing forensic writeup from Tibane Labs, a rival wallet developer, offered additional detail. Tibane attributes the broken signer to EMURGO's own in-house SDK, published under the package @stashers.io/trantor, and pins the bug specifically to the adapter layer that supplies key material to the signer — rather than to the cryptographic library itself. That's a narrower diagnosis than earlier accounts that pointed more broadly at the bundled signer as a whole. EMURGO has not issued a public response to Tibane's analysis, and that report should be read as a competing forensic theory rather than an agreed-upon conclusion.

Taylor Monahan later added a correction, disputing the idea that only a wallet's first or default address (index 0) carried risk. Her point: any key that signed even one SecondFi transaction during June 2026 is exposed, regardless of whether that address was the default one or whether the key originated inside SecondFi at all.

When the only party capable of reviewing the code was also the one that shipped it — because the implementation was proprietary — what was the audit process actually protecting?

Two Groups, Three Waves

The two attacker groups operated independently of one another, working through the pool of exposed addresses across three separate waves between June 21 and 23. Attacker A cleared 171 wallets in two automated batches, funneling the proceeds through three collection addresses and a shared fee/change address. Attacker B, in a separate coordinated operation, swept 203 wallets.

Combined, external attackers took roughly 16 million ADA from 374 addresses — around $2.4 million at ADA's price at the time, hovering near a five-year low of about $0.146.

Attacker A's collection wallets were identified as: addr1q9j7f598x988unr4zhjulft205jqnn9ewgwkhes5smf2sr6jsw98nm4qq38jw9epe587twavuhuhj5d8r92rjvmyjlzs9lqc3x, addr1q9wudkfeelzwev427yvapkmqexmet8q4vl303m7a4eerwtvt6rq00zyuqzeuw759vgqtdky0gyxnqx27n8q4k6h79yhsqelma8, and Addr1q82jlp2u0ezv2hsf6f40fkrv49hd72yv442nmrr5qeultpqamepaykp3m564hnd4zp75wxxds2j6d3ywvc8prhf2kcxqn6nql3.

Its central fee/change address was addr1q8acx4h5a38x6ekpsp0x7aelw6mflt78khmz8lz75rtnqvn07w88zx2e89tgzqr3x0mecngqlg87kq9surhk48hj79mqcezfa8, with a stake key of Stake1u9hl8rn3r9vnj45pqpcn8auuf5q05rltqzcwpmm2nme0zasf40ymg.

Attacker B's collection wallet — which still held approximately 4,020,468 ADA and has been flagged for active monitoring — is addr1q8m5wdncq7rwum73r5cyyr82qx2xjem5k4ehapl3wy36aaerj829vasl3amtcwshgvnn6a25dr850tfw6qaj420d2szsslkku6, with stake key stake1uy3er4zkwc0c7a4u8gt5xfeaw42x3n6845hdqwe248k4gpgdq4da5.

Two different loss figures circulated publicly and measured different things: SecondFi's own 16 million ADA figure reflected only confirmed drains executed by external attackers, while SlowMist's Cos, tracking broader attacker wallet flows, put likely total losses above $20 million — including more than 129 million ADA plus additional tokens.

That 129 million ADA figure refers to the separate emergency sweep: SecondFi moved that amount to an independent third-party custodian, describing the action as containment meant to keep the funds out of reach of further attackers.

The underlying logic was sound as far as it went: since private keys were publicly derivable from on-chain data, any additional actor with the same data could, in principle, have drained still more wallets. Moving the funds into custody cut off that opportunity — but it didn't fix the actual problem. Once a private key can be reconstructed from chain data, both its original owner and anyone who observed the relevant signature possess equal signing authority over that address. SecondFi's sweep relocated the ADA — it did not restore sole control over the compromised keys themselves.

The secondary risk stayed active: with attackers reportedly watching the mempool, any subsequent transaction from a still-compromised address — including staking reward withdrawals — risked being front-run before it even confirmed. SecondFi's guidance on this point was direct: restoring an affected seed phrase into a different wallet simply recreates the same exposed addresses, because the flaw lives in the signing process, not the wallet interface. As of the June 26 recovery update, the roughly four million ADA sitting in Attacker B's flagged wallet had not moved.

When a compromised key leaves its original holder and any attacker who happened to read the chain with identical signing authority, what does "recovery" even describe?

Containment Isn't Control

SecondFi shifted into containment mode, but containment and control are not the same thing. Users were instructed not to restore their seed phrases elsewhere, not to withdraw staking rewards, and not to move funds on their own — because any action taken from a compromised address risked exposing the same key all over again. That guidance was accurate. It was also essentially the only option left once the platform had lost the ability to protect its users through cryptography alone.

The 129 million ADA custodial sweep may have prevented further drains, but it could not hand back genuine control. Once signatures sitting on-chain can be used to rebuild private keys, moving assets into custody functions less like a repair and more like a pause — the platform could relocate the funds, but it could not erase the signatures that had already made them vulnerable. The chain, in other words, behaved exactly as designed; the design itself was simply unsafe. A defective signer turned everyday wallet use into a key leak, and from that point forward, who actually held the ADA became a matter of institutional trust rather than cryptographic certainty.

EMURGO has committed to returning the funds and stood up a restoration fund, and an outside accounting firm is verifying the custodial holdings — but all of that amounts to administrative process layered on top of a problem that process alone can't fix.

By June 29, the shape of that process had come into clearer focus. SecondFi confirmed EMURGO had funded a dedicated Asset Recovery Wallet to reimburse addresses drained by the external attackers. For the separate 129 million ADA moved during the emergency sweep, SecondFi said it was in ongoing talks with IntersectMBO about an appropriate custody arrangement to hold the funds securely before eventually returning them to users. The custodian's identity remained undisclosed a week into the incident — a question that was still open at that point.

If the remedy for a cryptographic failure is ultimately a pledge backed by an accounting firm, whose interests is that arrangement actually serving?

02A Contrast: Volo on Sui

Roughly two months before SecondFi's drain window, the Sui-based protocol Volo dealt with a comparable scenario: a compromised private key, no broken code involved, and $3.5 million leaving three vaults before any outside researcher had even flagged the activity. Volo caught and disclosed it themselves within hours, coordinated quickly with ecosystem partners, intercepted an attempted WBTC bridge transfer, and recovered $3.44 million within days. The treasury absorbed a net loss of just $60,000, with nothing passed on to users.

Both incidents ultimately trace back to compromised keys rather than broken contracts, but the responses diverged sharply — Volo moved quickly and recovered nearly everything, while SecondFi's remediation was still unfolding well after the fact.

SecondFi's recovery timeline, published June 26, estimated funds could start being returned within roughly two weeks. By June 29, that estimate had already slipped: the company acknowledged the on-chain recovery mechanism was proving more complicated than expected and could take longer than the original two-week window. A tool letting users check whether their own wallet was affected was promised for early the following week. The custodian still hadn't been named publicly, and no commit history has been released that would explain how the broken nonce logic made it into production in the first place.

If one missing secret input can turn every signature a wallet produces into a public disclosure of its private key, what should users actually be trusting the next time an app calls itself self-custodial?