How DeFi exploits work: a field guide to a decade of losses

Decentralized finance has lost north of $15 billion since 2020. It hasn't lost it to a single bug, or a single category of bug, or even a single category of adversary. It has lost it the way every complex system loses things: in a handful of repeating patterns that everyone in the industry can name, but few protocols actually defend against until after they've been hit.

This guide is a walk through those patterns. Every category below is illustrated with at least one breach you can look up in our Ledger — not because the catalogue is exhaustive, but because the recurrences are the point. The same six or seven failure modes account for the overwhelming majority of value lost, and almost every new exploit looks like an old one wearing different clothes.

If you're shipping a smart contract this quarter, this is the reading list that should already be on your wall.

1. Reentrancy

Reentrancy is the original DeFi vulnerability. It's the bug that drained 3.6M ETH from The DAO in 2016, forked Ethereum into ETH and Ethereum Classic, and still managed to drain $25M from Cream Finance in 2021, tens of millions from Sturdy Finance, and (in its read-only variant) hit lending markets through 2023 and beyond.

The mechanic is deceptively simple. A contract makes an external call before updating its own state. The contract being called — controlled by the attacker — calls back into the original contract while the first invocation's state is mid-flight. Withdraw functions that decrement a balance after sending tokens are the classical victim. The attacker calls withdraw, receives funds, and during the receive callback calls withdraw again. The original contract still thinks the attacker is owed the full balance. The cycle repeats until the vault is empty.

The standard mitigations are old enough to vote: the checks-effects-interactions pattern, reentrancy guards (OpenZeppelin's ReentrancyGuard is one line), and avoiding low-level call to untrusted addresses when state hasn't been committed. The reason reentrancy keeps showing up is not that defenders don't know the pattern — it's that protocols compose with each other, and a "safe" function in your contract can become unsafe when called inside a hook fired by an external integration. Read-only reentrancy, which Sturdy used to lose $800K, exploits exactly this: a view function reports stale state during a callback, and a downstream contract uses that stale view to make a real decision.

The lesson is structural: reentrancy is not a bug to patch in your own code. It's a property of the integration graph. Every external call is a potential reentry point, and every public view function might be queried by a contract that's mid-callback into yours.

2. Oracle manipulation

If reentrancy is the original DeFi bug, oracle manipulation is the one that scales. Almost every protocol that touches an asset price depends on an oracle, and almost every oracle has at least one configuration in which an attacker can move the price they will be paid.

The 2020s catalogue is long. bZx — the first widely-publicised flash-loan-driven oracle attack — lost $980K in February 2020 by manipulating the price of sUSD on a thin Kyber pool. Mango Markets lost $114M when an attacker spiked the MNGO/USDC price on a low-liquidity venue and used the inflated collateral value to drain the protocol. Cream Finance, August 2021 lost $130M after a yUSD oracle could be moved with a flash-loaned position. Inverse Finance lost $15.6M by transacting in a single private mempool bundle that bypassed TWAP protections.

The class of attack splits into two families. The first is spot-price manipulation: the oracle reads a single block's price from a venue an attacker can move. The fix here is well-understood — use a TWAP that averages over enough blocks that manipulation becomes prohibitively expensive, or use multiple independent oracles and reject reads that diverge. The second family is liquidity-rebalancing manipulation: the oracle is technically a TWAP, or a multi-source aggregate, but the attacker can move the underlying pool enough that the aggregate also moves. This is what BonqDAO suffered when $1K of TRB tokens were enough to report an absurd WALBT price to the protocol's Tellor oracle and mint $120M of stablecoin.

The defensive insight is that price oracles are bridges between markets and contracts — and like all bridges, the question is not how you read them, but how you handle the read when it disagrees with reality. Circuit breakers on price velocity, hard caps on per-block borrow growth, and rejection of price reads from pools below a liquidity threshold are all forms of saying "we don't trust this number." Protocols that trust their oracle absolutely are paying for the trust the first time they shouldn't have.

3. Flash loans (and the death of capital as a defense)

A flash loan lets anyone borrow millions of dollars for one block, with no collateral, as long as they repay within the same transaction. It is, by far, the single biggest amplifier of every other vulnerability on this list.

The flash loan itself is not the bug. The bug is whatever the borrowed capital lets the attacker do. Beanstalk Farms is the canonical case: a $1 billion flash loan let an attacker buy enough of the protocol's BEAN-3CRV LP tokens to pass a governance proposal that drained the treasury — net theft, $182M. Euler Finance used flash loans to recursively inflate a debt position until a faulty self-liquidation check let the attacker walk away with $197M. PancakeBunny, Cream Finance, Harvest Finance, Eralend, BetterBank — every flash-loan headline in this archive is a story about a different underlying bug that flash loans made profitable to exploit.

The historical defense against most exploits was that you needed capital to attack big protocols. That defense is gone. The right mental model is: assume every attacker has $500M to spend for one block. If your governance is takeover-able with that much, your governance is broken. If your oracle moves with that much, your oracle is broken. If your invariants don't hold under a one-block borrow-and-return, your invariants are broken.

4. Bridge exploits

Cross-chain bridges have lost more money in absolute terms than any other category in DeFi history. The big four — Ronin ($625M), Poly Network ($611M), BNB Bridge ($586M), Wormhole ($326M) — alone account for north of $2 billion lost.

Bridges fail in three structurally distinct ways. First, signer compromise: the bridge is secured by an N-of-M multisig, and an attacker compromises enough signers to mint freely. Ronin lost five out of nine signers; Harmony lost two out of five. These are reducible to operations problems, not protocol problems — the contract did what it was supposed to do, but the keys it trusted were no longer trustworthy. Second, message-verification bugs: the bridge accepts a forged proof. Wormhole accepted an unsigned guardian payload because a verify_signatures call wasn't actually verified. Nomad accepted any message after an initialization mistake set the trusted root to zero, leading to the only crowd-sourced bridge drain in history. Third, mint/burn invariant breaks: the source chain didn't burn what the destination chain minted, usually due to a logic bug in the message handler. Qubit, Multichain, and the Heco bridge all fit here.

The hard truth about bridges is that they centralize the trust they're supposed to distribute. Whatever the front-end says, every bridge is ultimately a multisig or a single-validator-set protocol holding the canonical assets. The math of "your asset on chain B is only as secure as the weakest signer or message-verification step in the path from A to B" is unyielding. The protocols that have lost the most have usually been the ones whose users were least aware of how much trust they had implicitly accepted.

5. Governance attacks

Governance attacks are reentrancy for tokens. The mechanic: an attacker accumulates enough voting power to pass a malicious proposal that drains the treasury, mints arbitrary tokens, or hands ownership to themselves.

Beanstalk was the most expensive, at $182M. Compound lost $80M+ when an over-payable Proposal 62 accidentally created an infinite-COMP distribution; it wasn't malicious, but the governance system passed it. Tornado Cash was a $1M loss in dollar terms but a complete loss of protocol control — the attacker passed a proposal that made them the sole governance authority over the entire system. Audius was a $1.1M drain that exploited an initializer bug to mint enough AUDIO to pass a proposal.

The defenses are not protocol-cryptographic but socio-economic. Timelocks that delay every governance action by long enough for the community to notice and respond. Quorum thresholds expressed as percentages of circulating supply, not deposited supply. Limits on what governance can do in a single proposal — a proposal that can spend the entire treasury is, mechanically, a proposal that will spend the entire treasury the moment it can be passed. And critically: assume flash loans exist. If a $200M flash loan can pass your quorum, your quorum is functionally zero.

6. Private-key compromise

This is the category that the catalogue keeps growing, year over year, faster than any other. It's also the category that smart-contract auditors cannot help with.

The pattern: a protocol's admin key, deployer key, or signer key is compromised — usually through social engineering, malware on a developer machine, or a supply-chain attack on a build pipeline — and the attacker uses that key to upgrade contracts, drain treasuries, or move funds out of custody. Radiant Capital lost $53M after macOS malware hit three of the eleven multi-sig signers; the Gnosis Safe UI showed clean transactions while the hardware wallets quietly signed a malicious upgrade. Atomic Wallet lost $100M to what is widely attributed to Lazarus. The WazirX exchange lost $230M through a Liminal multisig compromise. Bybit lost $1.46 billion — the single largest cryptocurrency theft in history — when malicious JavaScript replaced the Safe{Wallet} signing interface mid-transaction.

The Bybit incident is the right case study for where the industry is right now: the cryptography held, the multi-sig held, the hardware wallets held. The attacker compromised the signing UI. Every signer saw the transaction they expected to see; the wallet signed something different. The lesson is that the trust boundary of a contract isn't the contract — it's the surface area of every machine, every tool, and every UI used to interact with it. Protocols that don't blind-sign-protect their upgrade paths, that don't have an out-of-band confirmation channel for any privileged action, and that don't enforce strict separation between development and signing environments will keep adding to this list.

7. Rug pulls and exit scams

The least technically interesting and the most numerically common category. A protocol's deployer or operator absconds with user funds — usually via a hidden admin function, an upgradeable proxy left unguarded, or a token contract with a mint backdoor.

The Squid Game token era produced hundreds of these; the catalogue includes DeFiLabs, Kokomo Finance, Merlin DEX, Swaprum, and many more. Some are clearly malicious from day one; some appear to be legitimate projects whose operators broke under pressure. From the user's perspective, the distinction rarely matters: the money is gone.

The mitigations are not protocol-level. They are operational signals: timelocked admin functions, renounced ownership, audited deployer key custody, and the willingness of the team to attach their real-world identities to the project. None of these are dispositive — DAO Maker had all of them and still got drained via an unprotected initializer — but every absence is a signal.

What ties it together

The seven categories above account for the great majority of value lost in this catalogue. The interesting thing is that none of them require novel cryptography to attack, and none of them require novel cryptography to defend against. They are all, in different forms, the same lesson: trust boundaries in DeFi are easy to mistake and hard to verify, and the worst losses come from systems that defended one boundary while leaving another exposed.

If you ship contracts, the productive reading order from here is probably to pick the category that's most relevant to your protocol and walk through the breaches we have catalogued for it. The detail in each post-mortem is, in our experience, worth more than any abstract checklist. Start with the largest losses on record, or browse by attack vector — the patterns will repeat themselves quickly enough that the recurrence becomes the most important thing you notice.