One laptop, $6.3 billion: what the Binance hack teaches small teams

On 29 October Binance lost about $6.3 billion in a few hours. It is the largest crypto theft on record, roughly four times the Bybit hack of February 2025. I am writing this on 30 October, a day later, so treat every number below as provisional. The totals have already moved once, and Binance has promised a full technical post-mortem it has not published yet.

I am not a crypto person and this is not a post about crypto. It is about something I deal with on every project: who and what can reach the place where the money is.

What we know so far

These are the facts as reported on 30 October, with who said them:

The cause, according to Binance. Its initial investigation suggests the attacker made unauthorised transactions after getting into an engineer's compromised laptop. That is Binance's own account; the details are in the post-mortem it has not released.
The speed. According to the blockchain analysts at TRM Labs, money left Binance hot wallets on ten different blockchains, most of it in about twenty minutes from 20:05 UTC. The preparation started at least 36 hours earlier.
The method, per TRM. The attacker had signatures ready in advance and fired them in one burst. On Ethereum, one transaction carried 50 pre-signed authorisations so that one of them would be valid at the moment of use.
Who did it. TRM says, with high confidence, that it was TraderTraitor, a North Korean unit the FBI also blamed for the Bybit hack. Binance has not confirmed this.
The damage control. Binance suspended deposits and withdrawals and says it will cover all losses. Stablecoin issuers froze a large share of the stolen funds within hours: Tether and Circle alone froze around $2.6 billion, per TRM.

The attack was not on the blockchain

The blockchain did what it was told. What failed, by Binance's account, was a laptop: one person's machine that could reach a system able to sign withdrawals.

That is the part that scales down to a five-person business. Nobody is going to spend 36 hours staging an attack on your shop. But the shape is the same at every size: somewhere there is a machine, an account or a key that can touch the money or the customer data, and the question is how many people's laptops sit one step away from it.

Ask it about your own setup:

Which laptops can log in to the production server, or deploy to it?
Which ones hold an API key for your payment provider, and is it the key that can do everything?
If one of those laptops were stolen tonight, what could the thief do before you noticed?

Limit what any single key can do

What makes this theft so large is not that something was compromised. It is how much that one compromise could do: wallets on ten chains, emptied in minutes.

The small-scale version of that lesson is plain:

Give every key the least it needs. Payment providers let you create restricted keys: a key that can create a checkout but cannot issue refunds or read every customer. Use those instead of the master secret key.
Separate keys per place. Your test environment gets test-mode keys. Your laptop gets none of the live ones if it does not need them.
Keep secrets out of the code. A key committed to a repository is a key on every machine that ever cloned it.
Make the dangerous actions slower than the safe ones. Refunds over an amount, payouts to a new bank account, a new admin user: those deserve a second step, a limit or a delay. An attacker relies on doing everything at once.

None of this would have stopped a team prepared to stage an attack for a day and a half. It makes the damage from an ordinary stolen laptop or a leaked key much smaller, and those are the incidents small businesses actually have.

Twenty minutes is faster than anyone reads email

Most of the money moved in about twenty minutes. What clawed a large part back was speed on the other side: issuers freezing stablecoins within hours.

You will not have a security team on call. You can still decide, before anything happens, how you would find out:

An alert when someone logs in to the server from somewhere new, or when a new admin user appears.
A notification on every payout and every refund, not only on sales.
Somewhere written down, in one place, how to revoke each key in a hurry. In the middle of an incident is the wrong time to look for the button.

"We will cover all losses" is not your plan

Binance can absorb a loss of this size. Almost nobody else can. For a small business the realistic plan is not to cover the loss but to keep it small and to be able to start again:

Backups that live somewhere other than the server they back up, and that you have actually restored once.
The ability to rotate every key in an afternoon.
Payment providers that hold the card data, so a compromised server never had it in the first place.

What this means if you are hiring

When you ask someone to build something that takes money or holds customer data, the quality of the code is only half the question. The other half is access: where the keys live, what each one can do, who can deploy, and how you would find out something is wrong.

Ask whoever builds it which keys exist, what each one is allowed to do, and what happens the day one of them leaks. A good answer is specific and a little boring.

If you want a project built with that kind of care, try the indicative quote check or tell me what you need.

Sources, as of 30 October 2026: TRM Labs analysis, Al Jazeera on Binance's statements, TechCrunch. Figures and attribution may change once Binance publishes its post-mortem.