How $50M Vanished on Three Signatures — And Why You Should Care
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
An analysis of how the Radiant Capital ($50M) and Bybit ($1.5B) exploits both succeeded via the same attack pattern: signers approved transactions on a poisoned Safe Wallet screen showing different content than the actual calldata their hardware wallets signed. The author, a former fraud detection systems builder for financial institutions, argues that Web3 multi-sig setups copy the appearance of banking-style verification (multiple keys) but lack the substance (multiple independent information channels). Alert systems like Blockaid and Hypernative exist but suffer from alarm fatigue, since most alerts are false positives and signers stop reading them. Proposed fixes include natural-language transaction explanations and an independent second verification channel outside the wallet UI.
Questions this post answers
How did attackers steal $1.5 billion from Bybit using the Safe Wallet interface?
Attackers poisoned the Safe Wallet transaction screen so signers approved calldata different from what displayed on screen, the same blind-signing exploit used against Radiant Capital four months earlier for $50M. This is attributed to the Lazarus Group and shows multi-sig requiring multiple private keys does not guarantee multiple independent sources of transaction verification. Track emerging crypto exploit patterns like this on daily.dev before they hit your protocol.
Why do security alert systems like Blockaid and Hypernative fail to stop signers from approving malicious transactions?
Alert fatigue causes signers to stop reading warnings because most alerts are false positives. In one credit card fraud detection system, out of every 100 alerts operators reviewed, only 4 were real fraud, so within three months operators assumed alerts were always false positives and stopped checking them, letting real threats slip through. Developers designing fraud or risk alerting can compare tooling approaches on daily.dev to avoid alert fatigue.
What security fix would prevent Safe Wallet UI poisoning attacks like the one used against Radiant Capital?
An independent second verification channel outside the working wallet UI, plus plain-language transaction explanations instead of generic risk alerts. Rather than a flashing 'RISK LEVEL: HIGH' warning, a message like 'this looks like a supply cap update but actually transfers ownership to an unverified contract deployed 14 days ago' gives signers something a human can actually act on. Protocol founders evaluating multi-sig threat models can follow security writeups like this on daily.dev.