List Your Assumptions Before Attackers Do (Threat Modeling)

Why this matters

An attacker doesn't break your code; they break your assumptions. The threat model is the explicit list of assumptions you're making — about who's calling your contracts, what they know, what they can afford to spend, what they can collude with. Skip this and you ship a protocol that's secure 'under unstated assumptions' — which means insecure as soon as someone notices.

Demo

A useful threat model has three layers: (1) Who is the adversary — single actor, miner, MEV bot, regulator? (2) What can they afford — flash loan? 51% stake? Censorship? (3) What do they win by deviating from the protocol — money? Information? Power over a vote?

Try it yourself

1. Pick a protocol (e.g. a lending market). List its top 3 adversaries by category: end-user (sybil attacks), miner (reorg/MEV), oracle operator (price feed manipulation).
2. For each, list what they can afford to spend on an attack. A retail attacker has $10k. A miner has block production. An oracle operator has API access.
3. Match adversary × resource × payoff. Where the payoff exceeds the cost, you have an open attack surface. This is the prioritisation question every protocol author must answer.

References

• OWASP — Threat Modeling
• Trail of Bits — Building Secure Contracts