Blockchain, Honestly · Chapter 4 of 6
How it actually gets stolen
Almost none of it is clever cryptography. The recurring pattern is a stolen key, a manipulated input, or a bridge.
If you read only the headlines you would think blockchains get broken by mathematicians. They do not. Look at where the money actually went and three patterns cover most of it, none of them exotic.
1. The key, not the chain
A private key is the whole of your authority. There is no password reset, no fraud desk, and no reversal — that is the same irreversibility from chapter 1, seen from the losing side. So attackers go for the key, or for whoever holds it.
Bybit, February 2025 — about $1.5 billion, the largest crypto theft on record
The attacker compromised a developer machine at Safe{Wallet}, a third-party provider, and pushed malicious code into the web interface Bybit's signers used.
The signers saw a normal transaction on screen and approved it. They were signing something else.
The chain worked perfectly. Every signature was valid. Nothing was hacked in the sense people mean. This is a supply-chain compromise of the same kind you would meet in any software estate — and the irreversibility that is sold as a feature is precisely what made it unrecoverable.
Ronin in 2022 (about $600 million) was the same shape — enough validator keys were obtained to authorise withdrawals. Again: no contract bug.
2. The oracle problem
A common variant is the flash loan attack. Because a blockchain transaction either fully succeeds or fully unwinds, you can borrow an enormous sum with no collateral provided you repay it inside the same transaction. Attackers borrow, use the size to shove a thin market's price, let a contract reading that price act on the distorted number, and repay — all in one block. No individual step is a bug. The composition is.
3. Bridges
A bridge moves value between chains. Since a coin cannot literally leave its chain, the standard design locks the real asset in a contract on one side and issues a claim token on the other. That lock-up contract becomes a single enormous pot with a small set of signers, and bridges have consequently been among the most reliably robbed things in the industry.
What this means for audits
Roughly 70% of major 2025 exploits hit contracts that had already been audited.
That is not a claim that audits are worthless — they catch real defects, and code without one is worse. It is a claim about scope. An audit reads the contract. It does not read your signers' laptops, your oracle's market depth, or the fifth protocol someone will compose yours with next year.
Treat an audit badge the way you would treat a passing unit-test suite: necessary evidence about one layer, and no evidence at all about the layers where the money actually left.
The defensive practices are consequently unglamorous and mostly familiar: multi-signature approval with signers on separate hardware, so one compromised machine is not sufficient; timelocks on privileged actions, so an upgrade or a withdrawal is announced hours before it can execute and humans can react; aggregated oracles with several independent sources and a deviation threshold; and circuit breakers that cap what can move in a window.
Two engineering habits are specific to this environment and worth naming. Checks-effects-interactions means updating your own state before calling any external contract — because that call can call you back before it returns, and re-entrancy is the classic exploit of that gap. And fuzzing (the Solidity toolkit Foundry's forge test does this) throws thousands of generated inputs at a property you assert must always hold, which finds the arithmetic edge cases that hand-written tests are exactly as blind to as the developer was.
Check yourself