Chapter 24 · Why Crypto Keeps Facing Attacks and Total Losses

A Real-World Problem

Three people lose their money in the same year.

The first deposits stablecoins into lending. Price manipulation creates bad debt and deposits are reduced proportionally, despite correct user behavior.

The second earns fixed returns on a platform. Withdrawals stop; bankruptcy follows three months later. The coins become a claim in a creditor queue.

The third finds a wallet emptied without losing keys, revealing a recovery phrase, or visiting a fake site. An old approval pointed to a contract later replaced by the site.

All say Crypto is unsafe.

True but unhelpful: defenses against one do not prevent the others. The first needs oracle analysis, the second custody-versus-credit understanding, and the third approval review.

This chapter provides a classification system. Named risks with questions and checks turn vague insecurity into action.

It consolidates risk lessons from Part A's first four stages.

Thought Experiment

You become a warehouse security chief.

Before patrolling, list every route through which goods enter or leave.

You find:

• Front door, governed by posted rules.
• Valuation scale, determining collateral and release decisions.
• Rear transport route, linking claims to goods held elsewhere.
• Administrator keys, bypassing normal rules.
• Owner meetings, able to rewrite rules.
• Floor capacity, affected by borrowed inventory and leverage.
• Exit width, limiting simultaneous withdrawals.
• External key custodian, whose reliability matters.
• Your own counting, requiring operational care.

Nine possible loss routes already improve on a vague safety question.

Next connect routes and ask whether one failure triggers another.

A manipulated scale undervalues goods; rules permit cheap removal; sales clog exits; normal users cannot withdraw; a deficit remains; emergency owners change rules; meeting eligibility becomes another risk.

One chain, five routes, one incident.

Real incidents usually propagate from one failed door into others.

Your Decision

How do you write a project's risk section?

What Happens

The course's shared Unified Risk Model continues into capstones:

Three points.

First, classification rather than exhaustive prediction. Categories aim to be distinct and cover most incidents. A risk outside them is worth recording.

Second, inspection questions do the work. Each should produce a verifiable answer about audits, authority, or prices. Risk management becomes investigation rather than intuition.

Third, categories often occur together.

A recurring chain:

Classify each step:

Individually manageable can become collectively catastrophic.

Compare a single failure with a compound incident:

A checklist is step one; connecting its categories is step two.

Build a Model

Code, economics, and people

Group the ten categories by the layer in which they arise:

The easiest layer to inspect is not necessarily where losses concentrate. Shallow oracle sources may be valid code but poor economic design. Perfect execution can drain a protocol.

Chapter 16's warning follows because code is only one layer.

Five routes for money to leave

Remember routes rather than dozens of incident names:

The fifth is entirely on your side. No protocol breach is required: an old unlimited, persistent allowance can target an upgradeable contract. This route may account for enormous personal losses and is one you can close yourself.

Risk is not additive

Chapter 17 said returns add and risks multiply. More precisely, risks are also correlated.

Three protocols each have a hypothetical 97% annual incident-free probability:

If independent: 0.97 × 0.97 × 0.97 = 91.3%

Shared oracles, collateral, or bridges mean one incident can affect all layers, invalidating independence.

List dependencies and find overlaps:

Overlap undermines apparent diversification, generalizing Chapter 18.

Turn categories into records

Each category gets a concrete answer:

Category: Oracle Risk
Question: Where does price come from, and can it be manipulated?
Finding: Sources A and B, median and 30-minute time weighting
Source: Official section X and contract 0x… verified in an explorer
Conclusion: Single-pool manipulation is harder; both sources can fail under stress
Uncertainty: Stale-feed fallback not found → unassessed

Six lines each, ten records. The final line is essential:

Quality depends on honest unassessed items, not checklist length.

All-green reports often mean inadequate investigation. The Analysis Toolkit combines this with the eighteen questions and Project Canvas.

What It Is Called

Hands-on

User deposits → protocol pool → ? → ? → attacker address → ?

AI Lab

Review [incident name and approximate date].

1. Timeline: timezone, event, transaction hash or block, and source.
2. Attack path: contract/function, effect, and why design allowed it.
3. Classify triggered / not triggered / unknown for:
Smart Contract / Liquidity / Oracle / Bridge / Custody /
Counterparty / Governance / Leverage / Token / Operational
Give public evidence for each.
4. Loss amount, valuation date, and final bearer.
5. Separate sourced facts, analogous-case inferences, and unavailable facts.

Mark uncertainty unavailable. Never invent plausible hashes, addresses, or numbers.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check