Threat modeling a protocol

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.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain what a threat model is and why it has to be written down.

2. Why it works (the mechanism)

Walk me through threat-modelling a stablecoin: who attacks, what they can do, what they win.

3. Advanced — application & what's next

Design a threat model for a cross-chain bridge. Explain how the threat model differs from a single-chain protocol's, and which assumptions you can no longer make.

References

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