Make abuse cost money: attack the unit economics, not the identity

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 thousandRe: CAPTCHAs — Understanding CAPTCHA-Solving Services in an Economic Context (USENIX Security 2010)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.cseweb.ucsd.edu ↗ — 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 (SpamalyticsSpamalytics: An Empirical Analysis of Spam Marketing Conversion (CCS 2008)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.icir.org ↗) — 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.

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-18Field Note · currentZFN-18 — Enforce a quota at ingress on every endpoint — even unabused onesPut a quota on every endpoint and enforce it at ingress from day one — per tenant, principal, IP — even for endpoints nobody abuses yet. Unlimited-by-default means the first runaway client or compromised key is an outage. Return 429 + Retry-After; retrofitting limits is painful.Why it's cited here: 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.Open ZFN-18 → — quotas at ingress: the free, coarse form of the same idea, and what you outgrow when the attacker has enough IPs and keys.
• ZFN-49Field Note · currentZFN-49 — Verify by computation, not lookup; store revocations, not issuancesVerification should be a computation, not a query: HMACs, signatures, hashes, and pass-by-value claims let any node verify locally. When revocation is rarer than issuance, invert the state — keep the few revocations for the lifetime of what they revoke, not a row per grant.Why it's cited here: 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.Open ZFN-49 → — verify the proof of payment by computation over a secret, not by a lookup, so verification stays cheap under flood.
• ZFN-13Field Note · currentZFN-13 — Fail fast and push back: retries, load shedding, and flow controlBuild client retries (backoff, jitter, Retry-After) from day one. Under overload, shed fast and push the failure back to the source to retry — don't retry internally and amplify it. Flow-control everywhere, bound every queue, and don't take more work than you can finish in time.Why it's cited here: 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.Open ZFN-13 → — shed fast and push retry cost back to the caller; the zero-budget version of making an attempt cost something.
• Proof of Transfer — the worked instrument: billing signup abuse by the gigabyte, and where it hurts.
• SpamalyticsSpamalytics: An Empirical Analysis of Spam Marketing Conversion (CCS 2008)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.icir.org ↗ and Re: CAPTCHAsRe: CAPTCHAs — Understanding CAPTCHA-Solving Services in an Economic Context (USENIX Security 2010)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.cseweb.ucsd.edu ↗ — 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.