Safeguard
Incident Analysis•

Mt Gox timeline: what happened and what defenders learn

A dated Mt Gox timeline from 2010 to 2024 and the controls it points to: reserve checks, hot wallet limits, account hygiene and honest incident updates.

Safeguard Security Team
5 min read

Mt Gox was a bitcoin exchange that launched in July 2010, was hacked in 2011, halted withdrawals in February 2014 and filed for bankruptcy that month. Its collapse points to four defender lessons: reconcile holdings against reality, limit hot wallet exposure, harden privileged accounts, and communicate plainly during an incident.

What is the Mt Gox timeline?

The dates below come from the public record summarized on Wikipedia. Some details are contested, and they are marked where they are.

  • 18 July 2010: Mt Gox launches as a bitcoin exchange.
  • March 2011: Mark Karpelès buys the site from its founder, Jed McCaleb.
  • June 2011: Users report stolen bitcoins and the user database leaks, including hashed passwords. On 19 June, an attacker uses a compromised auditor account to trigger a sell-off that briefly drops the price to one cent.
  • October 2011: About 2,609 BTC are sent to invalid addresses and are effectively lost.
  • April 2013: The exchange handles over 70 percent of worldwide bitcoin trades.
  • 2013: Dollar withdrawals are suspended in June, a payment-processor dispute occurs, US authorities seize funds from a subsidiary account, and customers report withdrawal delays of weeks to months by November.
  • 7 February 2014: All bitcoin withdrawals are halted. Three days later the exchange blames transaction malleability.
  • 24 February 2014: Trading stops and the site goes offline. A leaked document claims 744,408 BTC were lost.
  • 28 February 2014: Mt Gox files for Japanese civil rehabilitation. It files for US bankruptcy protection on 9 March.
  • 20 March 2014: The company finds 199,999.99 BTC in an old wallet, which lowers the reported loss from about 850,000 to about 650,000 BTC.
  • April 2014: The rebuild plan is dropped and a Tokyo court is asked to liquidate.
  • April 2015: The firm WizSec concludes that most or all of the missing coins were stolen from the hot wallet starting in late 2011.
  • March 2019: Karpelès is convicted of falsifying data to inflate holdings and is acquitted of other charges.
  • 2021 to 2024: Creditors approve a rehabilitation plan, and the repayment deadline is extended to 31 October 2024.

Why did the loss go unseen for so long?

Public accounts disagree on cause. The exchange blamed malleability, an analysis firm blamed long-running theft, and a court found falsified records. We will not pick between them. What the timeline does show is a gap of about two years between the first signs of theft in the analysis and the day withdrawals stopped.

A gap like that usually means nobody was comparing what the books said with what the wallets held, on a schedule, with someone independent doing the comparing.

What should defenders take from it?

Reconcile on a schedule. Any system that holds value for others needs a routine check that records match reality. For software teams the equivalent is comparing your inventory of dependencies, images and credentials against what is actually deployed.

Keep little in the hot path. The WizSec finding is about a hot wallet. The general idea applies to any always-online secret: a deploy token or cloud key with broad rights is a hot wallet. Scope it, rotate it and alert on use.

Treat audit and admin accounts as crown jewels. The 2011 sell-off ran through a compromised auditor account. Privileged read and review roles need the same multi-factor and monitoring as write roles.

Say what you know. The 2014 statements shifted from "fully resumed" withdrawals in 2013 to a malleability explanation to closure. Customers and regulators lose trust faster from changing stories than from bad news. Publish what is confirmed, what is not, and when the next update comes.

What to do

  1. List every credential or key that can move money or data without a second approval, and cap each one.
  2. Schedule an independent reconciliation of inventory against production, monthly at minimum.
  3. Put audit, finance and admin roles behind hardware-backed MFA and alert on unusual use.
  4. Write an incident communications template now, with a rule that every statement is labeled confirmed or unconfirmed.
  5. Run dependency and secret scans in CI so a quiet weakness shows up as a ticket and not as a surprise. A free in-browser dependency scan is available at gold.safeguard.sh/scan.

Quick check

How many bitcoin did Mt Gox lose?

Figures changed over time. A leaked document in February 2014 claimed 744,408 BTC, and after a wallet holding 199,999.99 BTC was found in March 2014 the reported loss fell to about 650,000 BTC.

Was transaction malleability the real cause?

Mt Gox said so in February 2014. In April 2015 WizSec concluded that most or all of the missing coins were taken from the hot wallet beginning in late 2011. Treat the cause as disputed.

Sources

  • Mt. Gox, Wikipedia, fetched 18 October 2026. We did not find a primary trustee document to confirm every figure, so check the cited references there before quoting amounts.

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.