# 00 — Threat model

Before we describe a single attack, we want to be precise about who we think the attacker is and what the attacker is willing to spend.

## The adversary we model

We model an adversary who is **rational, capitalised, and patient**.

*Rational* means the adversary acts to maximise expected profit, not to vandalise. We do not model attacks whose goal is destruction without payoff; those are real, but they are easier to defend against and they make for less interesting case studies.

*Capitalised* means the adversary has working capital in the millions of USD-equivalent and uninterrupted access to a flash-loan provider. We do not assume they have *infinite* capital; the difference matters for chapter 30, where the cost of borrow becomes the reason an attack does or does not pencil.

*Patient* means the adversary is willing to wait. They will execute a single transaction now if the numbers are good. They will set up a position three days in advance and harvest it on a specific clock tick. They will run a small, slow grinder for a month if the expected profit beats their working-capital cost. The fuzzer's `fuzz` command (chapter 70) is the patience modelled in code.

## What the adversary cannot do

We do not model:

* attackers who control the validator set;
* attackers who control the oracle's price-publisher keys;
* attackers who can break the cryptographic primitives.

These are out of scope because if any of them are true, the protocol is already compromised in ways the fuzzer cannot help with.

## What the protocol is responsible for

The fuzzer's findings are bounded by what the protocol *can* enforce. A protocol that depends on a Pyth feed cannot guarantee freshness beyond what Pyth's `publish_time` allows. A protocol that runs in the same block as Jupiter cannot guarantee its swap will not be sandwiched.

Our position on this is consistent throughout the book: a finding is something the protocol could have prevented. If the only fix is *use a different oracle* or *do not deploy on a public chain*, we say so plainly and we move on.

## What we mean by "broken"

An invariant is broken when the protocol ends a transaction in a state that the protocol's authors did not intend. The fuzzer evaluates two flavours:

| invariant        | meaning                                                                                                           |
| ---------------- | ----------------------------------------------------------------------------------------------------------------- |
| **conservation** | the sum of relevant balances is unchanged across a benign sequence                                                |
| **monotonicity** | a value that should only move in one direction (a vault's principal, a lender's debt) does not move the other way |

When the fuzzer reports a breach, it is one of these two. Everything else — slippage, MEV, gas, governance grief — is downstream of one of these two breaking somewhere.

## How we score severity

Severities are bucketed by USD-equivalent profit because that is the language the adversary speaks.

| severity     | profit per attack |
| ------------ | ----------------- |
| **CRITICAL** | over $1,000       |
| **HIGH**     | $100 – $1,000     |
| **MEDIUM**   | $10 – $100        |
| **LOW**      | under $10         |

These are inputs to triage, not absolute thresholds. A CRITICAL finding on a $50,000 protocol is existential; the same finding on a $2B protocol is a Tuesday. We always quote USD numbers; we let the consumer of the report apply their own TVL multiplier.

The next chapter is the first case study. From here, we leave the threat model in the background and let the cases speak.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://economicfuzz.gitbook.io/economicfuzz-docs/00-threat-model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.