KoinlyticsSecondFi, the Cardano wallet service that stepped in earlier this year to replace EMURGO's Yoroi client, is winding down after attackers drained 16.1 million ADA, roughly $2.4 million, from 374 user wallets across four separate draining events between June 21 and June 23, 2026. The Cardano protocol was untouched. What broke was the signature code inside SecondFi's own software.
Investigators at Beosin traced the losses to a specific implementation error in the way SecondFi generated Ed25519 signatures. The bug is not exotic. It is the single failure mode RFC 8032 was written to prevent, and it turned every native ADA transaction the client ever produced into a public disclosure of the signing key.
How A Nonce Without A Secret Turns Every Signature Into A Key Leak
An Ed25519 signature is a pair of values, commonly written as (R, s). R is a public curve point derived from a per-signature scalar known as the nonce. The s value combines that nonce, the signer's private key, and a hash tied to the message being signed. If an observer knows the message, the signature, and the public key, they still cannot recover the private key, provided one condition holds. The nonce must be unpredictable to anyone who does not hold the secret.
RFC 8032, the specification EdDSA is built on, achieves this by deriving the nonce deterministically from a hash of two inputs. The first input is a secret prefix that comes from expanding the private key. The second input is the message being signed. Because the secret prefix is part of the hash, an outsider watching the transaction cannot reproduce the nonce even though they can see the message. The private key stays hidden.
SecondFi's client-side signing code omitted the secret prefix. The nonce it used was a hash of the transaction body alone. Every input to that hash was public. Anyone reading the Cardano chain could reproduce the exact nonce SecondFi had generated, plug it into the standard EdDSA algebra together with the on-chain signature, and solve for the private key in a single step. Every transaction was, in effect, a signed announcement of the account's private material.
This is why the attackers did not need to phish anyone, break a smart contract, or exploit a bridge. They watched the chain. Any wallet that had ever signed a native ADA transaction with SecondFi's software was harvestable. The four draining events between June 21 and June 23 were not four intrusions. They were four batches of key recovery run against previously exposed accounts.
SecondFi's Ed25519 Mistake Versus RFC 8032 Compliant Derivation
The gap between what SecondFi shipped and what the specification requires is one line of code.
A compliant Ed25519 implementation expands the private key into two halves using SHA-512. The lower half becomes the actual scalar used for the public key. The upper half is the secret prefix that never leaves the signing device. To sign a message M, the implementation computes the nonce r as SHA-512(secret prefix concat M), reduced modulo the curve order. The secret prefix is what keeps r unpredictable to anyone who does not hold it.
SecondFi's implementation computed the nonce as SHA-512(M), or an equivalent hash over only the transaction bytes. The secret prefix was never mixed in. Two things followed automatically. First, the nonce was fully derivable from public data. Second, an attacker with the nonce, the signature, and the public key can rearrange the s equation, s equals r plus H times the secret scalar modulo the curve order, and solve for the secret scalar directly. There is no brute force involved. It is one modular subtraction and one modular multiplication.
Hardware wallet users were not exposed, because their signing was performed inside a device running its own compliant EdDSA. The vulnerability lived entirely in the software client. That also bounds the population at risk to whoever imported keys into SecondFi and signed at least one transaction with them.
What Any Custodial Or Client-Side Wallet Team Should Verify Today
The failure mode SecondFi hit is now the second nonce-derivation bug to publicly break a chain wallet in 24 hours, alongside a parallel disclosure affecting the Zilliqa Ledger app. Teams shipping signing code should audit for the following before assuming they are safe.
Confirm nonce derivation includes the secret half of the expanded key. For Ed25519 that is the upper 32 bytes of SHA-512 over the seed. For Schnorr variants, confirm the auxiliary secret is present in the nonce hash. If your signer can produce a signature without touching the secret material during nonce generation, you have this bug.
Test against the known-answer vectors in RFC 8032. The specification ships explicit test vectors. A correct implementation matches them byte for byte. SecondFi's client would have failed those vectors on day one. Any wallet that does not run them in CI is guessing.
Treat client-side signing code as chain code. Audits historically concentrate on on-chain programs and smart contracts, where a bug can drain a pool. A signing bug in a wallet drains every user who ever touched it, silently, and it is visible to any observer with a full node. The blast radius is larger than most contract bugs.
Assume any signature produced under a buggy nonce scheme is a permanent key compromise. Patching the client does not rehabilitate keys that already signed. Affected users need fresh keys and a supervised migration. SecondFi's own recovery plan reflects this: export tools first, then a recovery portal, with distribution timing still open.
SecondFi has patched the code path and moved 129 million ADA out of reach of the drainers before they could get to it. The team has confirmed it will not resume normal operations. Wallet export tools are scheduled for early August 2026 and a recovery portal is expected later in the month. No date has been set for the return of the 16.1 million ADA already taken.
What Koinlytics tracks: We monitor on-chain drainer patterns, wallet-client incident disclosures, and the recovery timelines that follow. If you held ADA with SecondFi, our alerts surface the export-tool release, the recovery-portal launch, and any wallet client shipping a signing implementation that fails RFC 8032 test vectors, so users can rotate keys before the next incident of this class hits.