---
id: 53
title: "Make abuse cost money: attack the unit economics, not the identity"
kind: note
status: current
date: 2026-08-10
authors:
  - "Theo Zourzouvillys"
tags: [security, abuse, fraud, economics, product]
references:
  - id: spamalytics
    title: "Spamalytics: An Empirical Analysis of Spam Marketing Conversion (CCS 2008)"
    url: https://www.icir.org/christian/publications/2008-ccs-spamalytics.pdf
    abstract: "Infiltrated a live spam botnet to measure the actual conversion rate of spam end-to-end — on the order of one sale per twelve million messages. The canonical demonstration that abuse at scale is a business with a measurable, and therefore attackable, cost structure."
  - id: recaptchas
    title: "Re: CAPTCHAs — Understanding CAPTCHA-Solving Services in an Economic Context (USENIX Security 2010)"
    url: https://cseweb.ucsd.edu/~mmotoyam/usec10-recaptchas.pdf
    abstract: "Measured the market for human CAPTCHA-solving labour: price, throughput, accuracy and elasticity. Established that a CAPTCHA is not a barrier but a price — and a price of roughly a tenth of a cent per solve, which almost no abuse model is sensitive to."
summary: "Abuse at scale is a business with a P&L. Detection is an arms race you eventually lose, because the attacker gets unlimited free queries against your classifier. Instead find the metered input they can't substitute away from, and inflate it — per attempt, dialled by risk."
supersedes: null
superseded_by: null
aliases: []
crossrefs:
  ZFN-18: "The free, coarse version of the same instinct: a quota caps how fast abuse can arrive without charging for it. Reach for an economic control when the attacker has enough identities and addresses that per-key and per-IP quotas stop binding."
  ZFN-49: "Why proof that a cost was paid should be a computation over a server-held secret rather than a row you look up — the check has to be cheap for you and unforgeable for them, at signup-flood volumes."
  ZFN-13: "The degenerate case at zero budget: when you can't price an attempt, at least make it fail fast and push the cost of retrying back onto the caller instead of absorbing it."
---

## TL;DR

**Stop trying to work out *who* is attacking you and start working out *what it costs them*.** Abuse
at scale — signup floods, trial farming, free-tier mining, referral fraud, scraped-account
harvesting — is a business. It has a revenue per successful account and a cost per attempt, and it
runs only while the first exceeds the second. Every detection control you build is a classifier your
attacker can probe for free, with instant feedback, as many times as they like. A **cost** is not a
classifier. There is no decision boundary to find and nothing to solve; there is only something to
pay.

So: model their P&L, find the input they buy from a market at a metered price and cannot substitute
away from, and make your flow consume a lot of it — **on every attempt, not every success**, and
**dialled by risk** rather than switched on and off. Then check, honestly, that the same cost is
near-zero for your worst-off legitimate user. If it isn't, you haven't built a defence; you've built
a tax on your own funnel.

## Context

The industry's default anti-abuse posture is identification. Fingerprint the device, score the
behaviour, reputation-check the IP, challenge the suspicious ones. It is a reasonable instinct and it
has quietly stopped working, for a structural reason rather than an implementation one.

Every identification control is a classifier sitting on the far side of an API the attacker controls
the input to. That gives them the ideal conditions for defeating it: unlimited queries, zero cost per
query, an immediate and unambiguous signal about whether they passed, and full control of the
features being measured. Under those conditions the boundary always gets found. The only question is
how many weeks it takes, and the answer keeps shrinking as the tooling commoditises.

Meanwhile every input the identification stack depends on has been turned into a purchasable good.
IP reputation used to be load-bearing; residential proxy networks now retail a genuine consumer IP,
on a genuine consumer ISP, in whatever country you like. Device fingerprints are spoofed by
off-the-shelf anti-detect browsers. Human verification is [priced by the
thousand](ref:recaptchas) — a CAPTCHA has not been a barrier for fifteen years, it has been a
line item costing a fraction of a cent. Phone numbers, aged accounts, and KYC'd identities all have
market prices and are all cheaper than you assume.

That commoditisation is usually read as bad news. It is also the opening. A market price is a
*number*, and a number can be attacked directly. The work that established this is old and still the
clearest framing available: measuring a spam campaign end-to-end found a conversion rate around one
sale per twelve million messages ([Spamalytics](ref:spamalytics)) — an operation that only exists
because the marginal cost of a message rounds to zero. Move that cost and the business closes,
without ever having identified a single sender.

## Recommendation

**Find the line item in the attacker's cost structure that they cannot avoid, and inflate it.**

- **Write down their P&L before you write any code.** Three numbers: revenue per successful account,
  end-to-end success rate through the controls you already have, and cost per attempt today. If you
  can't fill those in, you are guessing about whether anything you build works. And note what the
  output metric actually is — not "attacks blocked" but **cost per delivered account**. "We blocked
  four million bots" is unfalsifiable and tells you nothing about whether the operation is still
  profitable. "Their cost per working account went from $0.004 to $1.30" is a business statement you
  can defend and act on.

- **Charge on the attempt, not on the success.** This is the highest-leverage choice in the whole
  design and the one most often got backwards, because "only charge the bad ones" sounds like the
  considerate thing to do. Their success rate is your multiplier: if the cost lands on every
  attempt — including the ones your other controls kill, the retries, the resends, the abandoned
  ones — then a 5% end-to-end success rate makes their true cost **twenty times** the sticker price.
  Charging only on success throws that multiplier away and hands them free reconnaissance besides.

- **Target something they buy, not something they own.** Good targets are metered inputs purchased
  from a market: proxy bandwidth, phone numbers, SMS receipts, verified identities, card BINs, aged
  accounts, real human attention. Bad targets are resources they already hold in surplus: CPU cycles,
  memory, IP addresses, time, patience. This is precisely why classical proof-of-work is a weak abuse
  control — compute is the attacker's *cheapest* input and, on a five-year-old phone with a failing
  battery, the honest user's dearest. The mechanism is fine; the asymmetry points the wrong way.

- **Verify the asymmetry, don't assume it.** For every candidate control, compute the cost twice:
  once for the attacker, once for your **worst-off** legitimate user — slowest connection, cheapest
  device, most constrained data plan, not the median. If the two numbers are within an order of
  magnitude of each other, the control is not a defence. Same mechanism, different populations,
  opposite verdicts: metered bandwidth is free on a flat-rate home connection and an invoice on a
  per-gigabyte proxy; a hash puzzle is trivial on rented compute and painful on a budget handset.

- **Build a dial, not a gate.** Binary challenges are either too weak to bite or too punishing to
  ship, and you get to pick exactly once. A continuous cost lets you charge nothing to a returning
  device with clean history and a great deal to a fresh client with every marker lit. The goal isn't
  that everyone pays — it's that the price is a monotonic function of risk and the attacker sits at
  the wrong end of it by construction.

- **Follow the money out, not just in.** The cheapest control frequently isn't at signup at all. It's
  a hold on the payout, a maturation window on the referral credit, a clawback period on whatever
  they actually came to extract. **Reversibility beats detection**: you don't have to decide correctly
  at t=0 if you can still take it back at t=7 days. Everything they steal that you can un-steal is
  revenue they cannot book, and it costs you nothing in false positives.

- **Instrument the price for yourself; don't publish it to them.** You want the threshold visible in
  your own telemetry and invisible from the outside. A control that announces exactly where the cost
  steps up is a control they will sit just underneath.

The concrete instrument I'd reach for first against signup floods is **proof of transfer** — require
the client to actually move a large block of unforgeable bytes, which is free-but-slow on a home
connection and a per-gigabyte bill behind a residential proxy. I've written that up separately, with
the enforcement details and the places it hurts, in [Proof of
Transfer](/blog/2026-08-proof-of-transfer/).

## Consequences

**Easier:**

- **The control doesn't rot.** A classifier degrades from the moment the attacker starts adapting; a
  price only moves when the underlying market moves, which is slower, and visible to you in advance.
- **You never have to be right about who anyone is.** No false-positive ban to appeal, no identity
  claim to adjudicate, no model to retrain, no ethnically-skewed behavioural signal to defend.
- **It works against attackers you've never seen.** There is no signature you can have failed to
  collect, which makes it one of the few controls that is any good on day one of a novel campaign.
- **It composes with everything else.** Economic pressure doesn't replace the detection stack; it
  raises the floor under it, so detection only has to catch what remains profitable.

**Harder:**

- **You have to actually know their economics.** That means threat intel, mystery-shopping the tools
  they buy, and instrumentation most teams don't have. A price set without those numbers is a guess
  wearing a spreadsheet.
- **The collateral lands on your most marginal users** — the slowest link, the oldest device, the
  metered plan, the person who can least absorb friction. That is a distributional decision, it is
  yours, and it does not get to hide inside an implementation detail. Always ship an alternative path.
- **You usually pay part of the cost too.** Bandwidth, SMS, compute, held funds, support load. Model
  your own side of the ledger as carefully as theirs, or you'll win the argument and lose the margin.
- **It does nothing against high-value targeted fraud.** If one account is worth four figures to a
  laundering operation, there is no price both meaningful to them and tolerable to your users.
  Economic pressure is a volume-abuse tool; keep the detection stack for everything else.
- **Costs denominated in currency drag in the whole apparatus** — payments, tax, refunds, chargebacks,
  regulators, and a permanent objection from growth. Where you can, charge in a *resource* rather than
  in money: it lands on the attacker's invoice all the same, without landing on yours.

## References

- [ZFN-18](/zfn/18-enforce-quotas-at-ingress/) — quotas at ingress: the free, coarse form of the same
  idea, and what you outgrow when the attacker has enough IPs and keys.
- [ZFN-49](/zfn/49-verify-by-computation-not-lookup/) — verify the proof of payment by computation
  over a secret, not by a lookup, so verification stays cheap under flood.
- [ZFN-13](/zfn/13-load-shedding-and-flow-control/) — shed fast and push retry cost back to the
  caller; the zero-budget version of making an attempt cost something.
- [Proof of Transfer](/blog/2026-08-proof-of-transfer/) — the worked instrument:
  billing signup abuse by the gigabyte, and where it hurts.
- [Spamalytics](ref:spamalytics) and [Re: CAPTCHAs](ref:recaptchas) — the measurement work that
  established abuse as an economic system rather than a technical one.

## Changelog

- **2026-08-10**: First published as a Field Note.