OAK — OnChain Attack Knowledge

Worked example · 2026-06

SecondFi — predictable web-wallet key generation drains Cardano (ADA) wallets — Cardano — 2026-06-23

Loss
Confirmed ~16M ADA (~$2.4M at ~$0.15/ADA); total exposure up to ~129M ADA (~$19–20M). Independent reporting puts confirmed theft at ~16 million ADA across ~178 wallets; SecondFi's own statement framed it as ~16M ADA across 374 addresses from "3 distinct draining events" by external actors. SlowMist (Yu Xian / "Cos") estimated potential losses exceeding $20M, possibly involving ~129 million ADA and other tokens, because the root cause makes every wallet generated by the affected software iteration potentially compromised, including those not yet drained. A separate ~129M ADA flow that SecondFi described as an emergency "rescue" to a third-party custodian is disputed (see Disposition).
OAK Techniques observed
OAK-T11.004 (Insufficient-Entropy Key Generation — primary, confirmed mechanism: SecondFi attributed the breach to its native Cardano web-wallet generation software, which produced private keys with predictable randomness; this collapses the key search space so an attacker can derive keys for the whole generated cohort and sweep them, independent of which wallet software a user later restores into. This is the same structural class as the Profanity/Wintermute EVM cohort, here in a non-EVM, wallet-provider-software form. See techniques/T11.004-insufficient-entropy-key-generation.md). Disputed-disposition lenses (NOT a confirmed classification): if the ~129M "rescue" flow proves operator-controlled rather than a verifiable independent custodian, the disposition is adjacent to OAK-T5.007 (custodial soft-rug / exit-or-rescue-as-single-coordinated-sweep), OAK-T11.010 (off-chain counterparty / custodian risk), and OAK-T6.007 (trust-substrate shift — a self-custody product reframed mid-incident as a claim-to-a-custodian); the unverified "qualified third-party custodian" claim is the concern OAK-T11.005.002 (fake-custodian) exists to capture. On-chain, a cohort-wide sweep of predictable-key wallets by an attacker is indistinguishable from a sweep of the same wallets to a "rescue" address — which is exactly why the disposition cannot be settled from flow shape alone.
Attribution
pseudonymous. No named entity. SlowMist's Cos tracked suspected attacker addresses (transfers cascading from larger to smaller amounts over hours, consistent with a batch of compromised keys); community trackers tagged the ~129M-receiving address (addr1q8g8c…7vuz99, created 2026-06-22 17:34 UTC) as an exploiter ("William-qa"), while SecondFi characterised the same flow as a custodial rescue. Entity attribution is unresolved and the rescue-vs-theft question is open as of 2026-06-24.
Key teaching point
When a wallet provider's own key-generation software is the root cause, the compromised population is the entire generated cohort — and "do nothing, wait for us" is the wrong guidance. The load-bearing T11.004 lesson applies directly: predictable-RNG keys remain drainable until the funds are moved to a freshly, properly generated key, so the only protective action for a holder is generate a brand-new wallet (new seed) with a different, audited generator and move funds immediately — which matches the "move assets to new wallets immediately / generate new keys with a different provider" guidance independent outlets reported SecondFi also issued. The narrower public message the maintainer-supplied posts emphasised — "DO NOT restore your recovery phrase into a new Cardano wallet" — is technically correct only in the literal sense that restoring the same predictable phrase elsewhere does not help (the key is still derivable); it is not a reason to leave funds in place. The accompanying "do nothing until official steps / submit a claim" framing is the part defenders and users should treat with skepticism: for a weak-entropy cohort, inaction is the failure mode (the half-life-of-known-vulnerability tail), and a "rescue to a custodian" that cannot be independently verified on-chain is not a substitute for the holder controlling a clean key.

Status: developing / partially disputed (as of 2026-06-24). Figures, the affected-address count, and especially the disposition of the large ~129M ADA flow are operator-self-reported and/or contested by on-chain analysts at the time of writing. This entry documents the mechanism (confirmed multi-source) and flags the disposition (disputed) as contested metadata, per OAK's neutral-framing convention. Revise as forensic confirmation lands.

Summary

SecondFi is a Cardano (ADA) web-wallet/platform (reported by Crypto Briefing to be an April-2026 rebrand of a prior "Yoroi"-branded web wallet — single-source, noted but not relied upon). On 2026-06-23 it disclosed a security incident, suspended services / entered maintenance mode, and traced the root cause to its native Cardano web-wallet generation software, which generated private keys with insufficient/predictable randomness. That defect makes every key produced by the affected software iteration derivable by an attacker, so the exposed population is the full generated cohort rather than a handful of phished users.

Confirmed theft is reported at 16M ADA ($2.4M) across ~178 wallets (independent reporting) / 374 addresses (SecondFi's own count), executed as several draining events by external actor(s). SlowMist placed total potential exposure above $20M (up to ~129M ADA) on the reasoning that un-drained predictable-key wallets remain vulnerable.

Separately, SecondFi stated it triggered emergency "rescue" measures securing ~129M ADA to an independent third-party custodian and engaged an external accounting firm to verify the holdings, directing affected users to submit claims at support.secondfi.io and to not restore their recovery phrase into another Cardano wallet. On-chain trackers and SlowMist associated the large flows with attacker-linked addresses, and community members publicly questioned whether the "custodian" address is in fact an exploiter. The rescue-vs-theft disposition of the ~129M flow is unresolved at the time of writing.

Timeline (UTC)

When Event OAK ref
Pre-2026-06 SecondFi's native Cardano web-wallet generation software produces user keys with predictable randomness (standing latent cohort) (standing T11.004 surface)
2026-06-22 17:34 Address addr1q8g8c…7vuz99 (later the ~129M-ADA recipient; disputed rescue-custodian vs attacker) is created —
2026-06-22 → 06-23 External actor(s) derive keys and drain wallets; transfers cascade from larger to smaller amounts over hours (SlowMist/Cos) T11.004
2026-06-23 SecondFi discloses the incident, suspends services, attributes root cause to its web-wallet key-generation software; says it rolled out a patch for unaffected wallets (operator response)
2026-06-23 → 06-24 SecondFi states ~129M ADA was "rescued" to a third-party custodian; advises users to not restore recovery phrases and to submit claims at support.secondfi.io; independent outlets report SecondFi also urged moving assets to new wallets / new keys (disputed disposition)
2026-06-24 Community trackers + SlowMist link the ~129M flow to attacker-tagged addresses; rescue-vs-theft remains contested; "hacker still actively draining" reports T11.004 (active cohort tail)

Public references

Discussion

SecondFi is OAK's first non-EVM, wallet-provider-software anchor for T11.004 (Insufficient-Entropy Key Generation). The existing v0.x anchors are EVM/Profanity vanity-generator cases (Wintermute institutional scale; the Profanity cohort tail); SecondFi extends the class to a Cardano consumer wallet provider whose own generation software shipped predictable randomness — the same cryptographic failure mode at the moment of key creation, at population scale, with no on-chain or runtime signal until disclosure. The two load-bearing T11.004 properties recur cleanly here: (1) the compromised population is computable from the affected software iteration rather than per-victim, so SlowMist's "every wallet may be compromised, including un-drained ones" framing is the expected cohort-enumeration signal, not alarmism; and (2) the half-life-of-known-vulnerability-after-disclosure is the operative risk — un-rotated keys keep getting drained, which is why "do nothing and wait for official steps" is precisely the wrong user-side posture and immediate rotation to a cleanly generated key is the only protective action a holder can take unilaterally.

The element that makes this case worth preserving beyond a routine T11.004 entry is the disposition dispute. SecondFi describes a ~129M ADA "emergency rescue" to a "qualified third-party custodian," and instructs affected users to take no self-custody action and instead submit claims. On-chain analysts (SlowMist) and community trackers instead associate the large flows with attacker-linked addresses. OAK's neutral-framing convention is the right tool here: the mechanism (predictable key generation) is what makes this an attack and is multi-source confirmed; the disposition (rescued / attacker-controlled / laundered) is contested metadata that does not change the classification. It is worth recording explicitly that, for a weak-entropy cohort, an attacker sweeping every derivable key into one address and a custodian sweeping the same wallets "for safekeeping" are on-chain indistinguishable by flow shape; settling rescue-vs-theft requires independent verification of who controls the recipient address (the accounting-firm attestation SecondFi says is underway, corroborated against the addresses SlowMist is tracking), not inference from the sweep pattern alone. Until that lands, the prudent defender reading is that an unverifiable "custodian" claim is not protection, and the maturity-appropriate attribution is pseudonymous.

If forensic confirmation later establishes the ~129M flow as operator-controlled and the "rescue/claim" process as a value-capture mechanism, this example should be re-mapped to add T5.007 / T11.010 as a co-primary disposition classification (custodial soft-rug / off-chain counterparty), with T11.004 remaining the root-cause mechanism. If it is confirmed as a genuine white-hat-style rescue, the disposition note stands as documented and the example remains a clean T11.004 wallet-provider-software anchor. Either resolution is consistent with the entry as written; the entry's job at v0.x is to record the confirmed mechanism and the open disposition honestly rather than to pre-judge the contested flow.

Techniques demonstrated (5)