Why crypto exchanges fail: a decade of breach patterns from Mt. Gox to Bybit

The single longest-running storyline in cryptocurrency history is "the exchange that lost user funds." It is older than DeFi, older than Ethereum, older than Bitcoin's first real bull run. Mt. Gox in 2014 was the first nine-figure case; Bybit in 2025, at $1.46 billion, is the largest. Between them, the catalogue runs through Coincheck ($530M), FTX, KuCoin, Poly Network, Bitfinex, WazirX, and dozens more. Total losses to exchange breaches alone are well into ten figures, and the pace has, if anything, accelerated.

A naive reading would conclude that exchanges are just badly run. The catalogue tells a more structural story: exchanges fail in four distinct ways, and the four ways have stayed consistent over a decade, even as the technical context has changed completely. The trade-offs that drive each failure mode are intrinsic to running a custodial venue. The lessons from Mt. Gox are not historical curiosities; they recur in 2025.

Pattern 1: hot-wallet theft

The original pattern. The exchange holds some portion of customer funds in a "hot" wallet — keys live on internet-connected machines so that withdrawals can be processed automatically — and an attacker compromises one of those machines.

Mt. Gox is the template. Russian national Alexander Vinnik has been credited with extracting roughly 850,000 BTC over the course of years, starting as early as 2011, primarily through a compromised wallet.dat file from Mt. Gox's hot-wallet infrastructure. The losses were not noticed in real time because Mt. Gox's reconciliation between user balances (in the database) and actual chain balances (on Bitcoin) was sufficiently sloppy that a constant drain looked like ordinary operations expenses. When the exchange finally suspended withdrawals in February 2014, it was found that essentially all customer Bitcoin was gone.

The pattern has recurred at every scale since: Bitfinex 2016 ($72M), Coincheck ($530M), Bitrue, Phemex, DMM Bitcoin ($305M), Indodax, BtcTurk, Lykke. The technical sophistication has varied — Coincheck stored hundreds of millions of dollars in NEM on a single hot wallet — but the pattern is constant: a service that needs to be reachable from the internet to function gets compromised through one of the many vectors that affect internet-reachable services.

The mitigation is partial and well-understood. Keep the hot wallet small (a few percent of float); rebalance from cold storage frequently and asynchronously; isolate the hot-wallet machine; monitor for anomalous withdrawal patterns and pause automatically. Every major exchange today does some version of this. The losses continue because the gap between "best practice" and "actually implemented" is wider than press releases suggest, and because the size of the hot wallet has grown along with the exchange. A 2% hot wallet at a $50B exchange is $1B, which is still a target worth attacking.

Pattern 2: cold-storage / multi-sig compromise

This is the second category, and the one that has produced the largest single losses. The exchange's cold storage — the deep keys that should only be touched for periodic large reconciliations — gets compromised, usually through an attack on the signing process rather than the keys themselves.

Bybit 2025 is the modern reference. The exchange used Safe{Wallet} (Gnosis Safe) for cold-wallet custody, with hardware wallets at multiple geographically separated signers. The cryptography was sound, the multi-sig was sound, the hardware wallets were sound. The attacker compromised the Safe{Wallet} web interface — specifically, the JavaScript served from a Safe-controlled S3 bucket — and replaced the transaction-signing payload that the signers reviewed. Every signer saw a benign-looking routine transfer; every signer signed a malicious upgrade to the contract that controlled the cold wallet. The attacker then drained 401,000 ETH ($1.46B) in a single transaction.

The lesson is that the trust boundary of cold custody is the entire signing pipeline, not just the keys. This includes:

• The machines used to compose transactions.
• The wallets/UIs that signers use to review them.
• The third-party services (custody UIs, smart-contract front-ends) that translate "human intent" into "bytes to sign."

WazirX was a similar shape at the multi-sig-provider level (Liminal), losing $230M. Heco bridge / HTX was structurally a custody compromise that drained $260M from accounts the exchange managed. Stake.com lost $41M in 2023 to what is widely attributed to Lazarus and is, structurally, a custody-key compromise.

The defensive escalation is to blind-sign protection: hardware wallets that fully decode the transaction they're being asked to sign, and refuse to sign if they can't parse it. This works against the Bybit attack (a signer would have seen "upgrade contract to 0xabc..." instead of "transfer 0.01 ETH"), but it requires every contract the exchange interacts with to be on the hardware wallet's known-decoder list. The longer the contract universe gets, the more often blind-signing becomes the operational path of least resistance, and the more often it gets exploited.

Pattern 3: internal fraud and insolvency

The third pattern is the one where the exchange itself is the adversary. Customer funds are not stolen by an outsider — they are spent, lent, or invested by the operator in ways the operator does not have permission to undertake, and when the resulting position blows up, the funds are gone.

FTX is the canonical case in size: an estimated $8B shortfall, with customer assets having been used to backstop Alameda Research positions for at least months and possibly years. QuadrigaCX is the canonical case in absurdity: founder Gerald Cotten died (the circumstances of which remain disputed) and the only person with access to the cold wallets — which were later found to be largely empty — was gone. Cryptopia and Mt. Gox, with the benefit of hindsight, also had operational practices indistinguishable from insolvency-by-design.

This pattern is the one DeFi was, in part, invented to address. The promise of non-custodial protocols is precisely that the operator cannot spend user funds without on-chain consent. But the catalog of exchange failures shows that the vast majority of crypto users continue to hold the majority of their assets on centralized venues — and that the rate of centralized failures has not meaningfully slowed since FTX.

Mitigations here are not technical, they are structural and regulatory: proof of reserves, third-party custody, mandatory reconciliation between liabilities and assets, segregated customer assets, real-time auditability. The industry's adoption of these mechanisms has been slow and inconsistent; the venues that operate them most rigorously are exactly the venues that have not appeared in this archive.

Pattern 4: signing-UI and supply-chain attacks (the modern frontier)

The fourth pattern is the newest, and the one that has produced the largest absolute losses of the 2020s. The exchange's hot wallets are hard. The cold wallets are hard. The signers use hardware. The auditors have signed off. The attacker compromises a tool in the chain.

The Bybit attack is the headline case — Safe{Wallet}'s build pipeline was the actual attack surface — but the same pattern shows up in several places. Stake.com is suspected to have involved a similar UI-replacement attack. Atomic Wallet — though technically a wallet rather than an exchange — lost $100M to what investigations suggest was a build-pipeline compromise that injected malicious code into the released binary.

The structural problem is that exchanges depend on dozens of third-party tools to operate. Multi-sig front-ends, hardware-wallet firmware, custody-provider SDKs, dependency trees in NPM, container images from upstream registries. Every one of these is a possible point of supply-chain compromise, and the cost to the attacker of compromising one of them — and waiting for the exchange to interact with it — is dramatically lower than the cost of attacking the exchange directly.

The defensive direction here is dispiriting because it asks the exchange to take responsibility for the security of every tool in its stack. The practical advice is narrower:

• Pin everything. Hardware-wallet firmware versions, custody-tool versions, RPC endpoints. Reject the auto-update path.
• Out-of-band confirmation. Any privileged transaction has a human-in-the-loop verification on a second device, ideally over a different network and a different vendor.
• Decompose privileged actions. A single transaction that can move $1B is, by construction, a transaction that will move $1B the moment a tool is compromised. Per-counterparty limits, time-locked upgrades, and circuit breakers on outflow velocity all reduce blast radius.

What it means for users

The aggregate picture is unflattering. More than $5 billion has been lost to centralized exchange breaches in the timespan this archive covers, and the rate of new incidents has not declined. The 2025 figure alone — driven by Bybit but supplemented by Phemex, BtcTurk, Nobitex, and others — exceeds the entire annual total for any year before 2022.

The actionable user-side conclusions have not changed in a decade:

• Self-custody for any amount you can afford to take responsibility for. Hardware wallets handle this case adequately for most users; the operational discipline they require is real but learnable.
• Diversify across exchanges for amounts that need exchange custody. The cost is some operational friction; the benefit is that a single exchange failure is not a total loss.
• Withdraw from any exchange that pauses withdrawals. Every exchange in this archive that ultimately failed paused withdrawals first. The pause is not "we're sorting it out" — historically, it has been the strongest possible leading indicator that the funds are gone.

The thing the archive shows most clearly is that the patterns are stable. Mt. Gox in 2014 and Bybit in 2025 are the same kind of incident in the same kind of way, separated by eleven years of technological progress that has not changed the underlying shape of the problem. If you're operating an exchange, the recurrence is the warning. If you're using one, the recurrence is the reason to limit how much you trust any single one.

Browse the full archive of exchange incidents for the detailed post-mortems. The patterns repeat.