T29 · Protocol Security

A Real-World Problem

Your protocol is live. Its contracts passed every T28 check: no reentrancy, clear permission boundaries, correct rounding direction, and timelocked upgrades. The audit report is clean, with no high-severity findings.

A month later, one afternoon, the protocol loses a large sum in minutes.

You inspect the transactions and become more confused:

- No function was called in an unexpected way
- No permission boundary was crossed
- Every line behaved exactly as written
- Each individual transaction was completely valid

In plain language, the attacker borrowed a huge sum, used it to push an exchange price to an absurd level, then traded with your protocol at that price entirely according to its rules. They pocketed the difference, repaid the loan, and finished within one transaction.

They broke into nothing. They simply worked out that the numbers favored them and acted on it.

None of T28's defenses—CEI, access control, invariants—fired, because those defenses stop code from doing what it should not do. Here, the code did exactly what it was designed to do.

So this chapter asks a different question:

How do you defend when the attacker needs no vulnerability, only a profitable calculation?

Thought Experiment

Leave code aside and picture a casino.

The rules at one table are public, fair, and followed perfectly by the house. One game sets its odds from the direction of chips wagered over the last hour. More bets on one side shift the odds.

The rule seems fine until someone arrives with a cart full of chips.

In one minute, they wager half the cart heavily on one side. The table follows its rules and moves the odds to an extreme. Then they wager the other half in the opposite direction at odds they created themselves.

At settlement, they win much more than they spent moving the odds. They pack up and leave.

The casino was not tricked into breaking a rule. Every bet was valid. The failure lay in an unstated assumption:

It assumed the direction of incoming chips represented many independent judgments, not one person's capital.

That assumption holds on most days, because few people control that many chips. It fails as soon as one person can bring enough money at once.

Now replace the casino with your protocol and the cart of chips with money that can be borrowed for one transaction and repaid immediately at almost no cost. Two things become clear:

First, your protocol also hides an assumption that “normally nobody has that much money.” Perhaps nobody can buy out a pool at once, instantly acquire a voting majority, or move a price that far in one block.

Second, crypto turns “obtain enough money at once” from “almost impossible” into “one transaction.”

The thought experiment reduces to a sentence:

Find every “normally nobody can do this” assumption in your protocol. Then assume someone has unlimited money right now and ask again: can they do it?

Your Decision

Your protocol needs a price. Where do you obtain it? This choice largely determines whether the attacker can make the numbers work.

What Happens

Compare the four price methods, focusing on the cost of breaking each one:

The second and third columns give the first conclusion:

A protocol is safe only when the cost to exploit it exceeds the benefit. In crypto, the capital component of that cost can often be borrowed.

This changes the safety calculation. In T28, attackers were limited by their keys and reachable code paths. Here, the constraint is whether the numbers work. The principal field in that calculation can be enormous: within one transaction, a flash loan makes “owning a hundred million” and “owning a hundred” functionally similar.

The second conclusion is the chapter's core action:

To judge a protocol's safety, put yourself in the attacker's position and calculate the trade, rather than searching only for code vulnerabilities.

The formula is simple; filling its terms correctly is hard:

Attack proceeds - attack costs = attacker's net profit

Where:
  Attack costs = capital cost + Gas cost + time cost + risk cost
  Capital cost = flash-loan fee if a flash loan works (very small)
               = opportunity cost of holding the capital otherwise

If the difference is positive, the attack will happen—not merely might happen. Onchain systems are public; people everywhere calculate the same trade, and you only need to miss it once.

Build a Model

Attack-cost checklist: fill every field correctly

This is the chapter's main tool. For any attack idea, fill the table and check the sign of net profit.

Then fill in proceeds:

The most important decision is whether the capital can be borrowed. It can turn a cost of millions in locked-up principal into a small fee, a difference of several orders of magnitude.

There is one test:

If the whole attack fits in one transaction and the borrowed assets can be returned at its end, it can use a flash loan.

If so, assume the attacker can access the sum of what all lending protocols on the chain can lend at that moment. That is a lower bound, not an exaggeration.

Flash loans: erase the principal line

The mechanism matters because it amplifies this entire chapter:

Within one transaction:
  1. Borrow a large amount without collateral
  2. Use it for anything
  3. Repay principal plus fee before the transaction ends

If step 3 fails, the entire transaction reverts as though steps 1 and 2 never happened

The lender is safe: nonpayment rolls everything back. The consequence for protocol security is profound:

Flash loans create no new attack. They lower the threshold for every attack that “needs a lot of money” from owning that money to making the economics work.

A flash loan itself is not a vulnerability; the economic assumptions it amplifies are. The answer is not to “ban flash-loan users”—that is neither feasible nor useful. Build a protocol that never relies on an attacker lacking enough capital.

A direct implication you can turn into a code rule:

Wherever a price, share count, or weight is changed and then used in the same transaction, assume the attacker changed it with borrowed funds.

This should sound familiar: it is T28's “state updated after use” at the economic level. There it was reentrancy; here it is manipulation. The same pattern appears at different layers.

Four economic attack classes, calculated one by one

First: oracle manipulation. The distorted state is a price.

Proceeds = assets extracted from the protocol at the distorted price
Cost = flash-loan fee + Gas ≈ very small
Safety condition = cost to move the price to the target > proceeds available

Defenses combine the pricing approaches from “Your Decision.” Raise the price-movement cost with deep liquidity, time-weighting, and genuinely independent sources.

Second: governance attack. The distorted state is voting power.

Proceeds = funds a malicious proposal can transfer
Cost = cost of borrowing a voting majority + cost of waiting through a timelock
Safety condition = borrowing votes + waiting costs more than the proposal can take

The key variables are whether votes can be borrowed and whether execution is timelocked. If governance tokens can be flash-loaned and votes execute immediately, an attacker can borrow votes, pass and execute a proposal, and repay in one transaction. Two controls matter: snapshot voting power before the proposal so newly borrowed votes do not count, and require a timelock before critical proposals execute so the community can react. This is the technical answer to Chapter 24's question, “Can one vote transfer the treasury?”

Third: liquidity attack. The distorted state is a pool's composition.

Proceeds = value extracted from the distorted pool or collateral bought cheaply after a bad liquidation
Cost = temporary control of large capital + Gas
Safety condition = reverse cost of restoring the pool > value extracted

The first-depositor problem in T28 is a special case. More generally, capital temporarily shifts price or weight in a thin pool and triggers protocol logic that depends on it.

Fourth: incentive attack. The distorted state is the contribution the protocol believes it saw.

Proceeds = subsidies, rewards, or airdrops claimed
Cost = creating fake contributions (often tiny)
Safety condition = cost to fake one contribution > reward for one contribution

This class may not look like an attack, but it is pervasive: wash trading for fee rebates, self-trading to climb rankings, and creating ten thousand addresses for an airdrop (a Sybil attack). Its arithmetic is simple: if pretending to be a valid user costs less than that user's reward, someone will pretend at scale. The drained paymaster in T27 belongs to this class.

A complete cost calculation

Apply the method to the opening scenario. Suppose your protocol values collateral using a pool's instantaneous price.

Attack idea:
  1. Flash-borrow a large amount of base asset
  2. Push the collateral price up in that pool
  3. Borrow far more than the collateral's real value from your protocol
  4. Move the pool price back (recovering some capital naturally)
  5. Repay the flash loan and keep the excess borrowed assets

Calculate costs:
  Capital = Can this fit in one transaction? Yes → tiny flash-loan fee
  Gas     = One complex transaction, material but far below proceeds
  Time    = One atomic transaction; no cost of holding capital across blocks
  Risk    = The transaction either succeeds or fully reverts; risk ≈ 0

Calculate proceeds:
  = (inflated collateral price - true collateral price) × borrowable amount
  = positive, often much greater than the costs above

Conclusion: positive net profit → this attack will occur

Now change one defense and recalculate: replace the instantaneous price with a sufficiently long time-weighted price.

Step 2 changes: to lift the time-weighted price, the attacker must hold the
                elevated price across multiple blocks.
  Capital = flash loan no longer works (must cross blocks)
          → opportunity cost of a large principal
  Time    = multiple blocks; arbitrageurs trade against the deviation
  Risk    = rises from ≈ 0 to real risk of arbitrage and front-running

Conclusion: cost jumps from “fee” to “large principal + time + risk,”
            often above proceeds → attack no longer pays

No code vulnerability was fixed. You changed one cost term from “borrowable” to “not borrowable.” That is a core technique of protocol security: make the route expensive enough, rather than merely closing one entrance.

System view: inherit the risks of your dependencies

Your protocol rarely stands alone. It uses another pool for prices, accepts assets from a bridge, or deposits funds into another protocol to earn yield.

You inherit each dependency's economic assumptions. Economic attacks thrive at these seams:

• Is your collateral a wrapped asset from a bridge? Its real value depends on that bridge remaining sound (T26).
• Does your yield come from depositing users' funds into another protocol? Its economic assumptions become yours.
• Does liquidation depend on liquidators making a profit? During violent markets it may stop paying them to act (T22 treated liquidation speed as a safety boundary).

The last protocol-safety step is therefore a dependency graph. Ask the same question for every external node:

If its economic assumptions fail, what happens on my side, and can I isolate the damage?

That graph is the skeleton of the threat model in the next chapter.

What It Is Called

Hands-on

- Nobody can buy out or overwhelm this pool at once
- The price cannot move that far in one block
- Nobody can acquire a voting majority instantly
- The first deposit will not be 1 wei
- Liquidation will always pay liquidators enough to act
- Nobody will create accounts at scale merely to claim rewards

Gas:  estimate transaction complexity times a conservatively high Gas price
Time: count required blocks and transactions
Risk: atomic transaction ≈ 0; for multiple steps, estimate failure,
      front-running, and reverse-arbitrage probabilities

Net profit = proceeds - costs

AI Lab

Step one:
Here is my protocol, including contracts, price sources, governance, rewards,
and external protocols it depends on.
Act as an attacker using capital but no code vulnerability.
List at least six ideas. For each, specify:
- What you borrow, what you do, and in what order
- Which of my economic assumptions you exploit

Step two:
For each idea, fill out capital (can a flash loan work?), Gas, time, risk,
and maximum proceeds. Explicitly decide whether the entire attack fits in
one transaction and repays the loan.

Step three:
Propose a defense for each. Distinguish a defense that blocks one specific
route from one that removes the economic assumption being exploited.
If it only blocks a route, explain which variable the attacker can change.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check