Case Studies: Lessons From Major Exploits

The history of DeFi exploits is the most concentrated source of audit-relevant knowledge available. Every major loss has at least one — usually several — lessons that translate directly into checks that should appear in audit checklists. Many of the lessons are duplicates; the same bug class (re-entrancy, oracle manipulation, signature replay) appears across years and protocols, often after the bug class was supposedly "well understood."

This section walks through a curated set of major exploits, organized chronologically and grouped by lesson. Each case follows the same format:

  1. Timeline — when, what, how much.
  2. Root cause — the single point of failure (or the smallest set of failures) that enabled the exploit.
  3. Exploit path — the attacker's transaction(s), at the level of detail useful for an auditor.
  4. What an audit should have caught — the specific check that, applied beforehand, would have surfaced the bug.
  5. Lessons — the generalizable principle.

The intention is not exhaustive coverage. The intention is to expose enough variety that an auditor approaching a new protocol has a mental library of "this resembles X" patterns.

Selection Criteria

The cases here are chosen for one or more of:

  • Historical magnitude (DAO, Ronin, Wormhole, Poly Network).
  • Bug class significance (Parity multisig, bZx, Curve re-entrancy).
  • Audit-detectability (cases where the bug was, in retrospect, clearly visible in code).
  • Compositional / cross-protocol lessons (Nomad, Multichain, Mixin).

Not included: cases where the root cause was off-chain operational compromise that left no on-chain signature an auditor could plausibly have flagged (KuCoin hack, certain CEX losses). These matter but are out of audit scope.

How to Use This Section

Read the cases. Then, before any new audit, glance back at the lessons list (or maintain your own annotated list) and ask: does this codebase have any of these patterns? The exploits are not random; they fall into a small number of categories, and once you've internalized the categories, recognition becomes fast.

The cases are listed in order:

A meta-lesson runs through all of these: bugs that lose user funds are almost always the bugs the team didn't think to look for. The job of the auditor is to look for them anyway.