Two Exits: What Writing an Anti-Scam Yellow Paper Taught Us About Onchain Fraud

We just published the Onchain Anti-Scam Yellow Paper — a bilingual (English/Chinese) systematic manual distilled from Onchain Diary’s research series: 76 articles and a 220-entry glossary. It ships as a free PDF with the LaTeX source on GitHub.

Writing it forced us to compress everything we know about onchain fraud into one structure. This post is about the structure, because the structure is the finding.

Scams are a factory, not a duel

The first thing the compression revealed: users are not facing a scammer. They are facing a supply chain. One crew runs acquisition — hijacked accounts, fake airdrop pages, lookalike domains. A second crew runs collection: drainer kits rented as a service, templated phishing contracts, signature lures. A third runs laundering through mixers and bridges.

This changes what defense means. Seeing through one script accomplishes nothing, because scripts are consumables that the factory replaces weekly. The durable question is: where does value actually leave a wallet?

Two exits

The answer is two. Value leaves a wallet through an approval or through a signature. That’s the entire surface.

Every class in our taxonomy maps onto one of them, or skips the wallet entirely and attacks the person:

• Approval abuse — the standing power of attorney. Unlimited approvals never expire. A grant signed three months ago outlives the protocol that requested it.
• Signature abuse — the rendering gap. Wallets compress what you sign into a few lines; scams live in the gap between “log in” and what the bytes actually say. Permit2 makes it worse: the signature is the approval, and the attacker pays the gas.
• Contract traps — honeypots, rug pulls, hidden mints. The exit here is still an approval or a transaction you make voluntarily, guided by fabricated information.
• Identity fraud — fake support, address poisoning, recovery scams. These attack you, not the wallet, and they harvest the one credential with no legitimate input field: the seed phrase.
• Infrastructure — bridge failures, clipboard malware, hijacked front-ends. Rarer, louder, and mostly mitigated by dispersion and domain habits.

Five classes, two exits, one credential that must never be typed. That is the whole threat model in a sentence.

Forensics is a user skill, not a specialist skill

The paper’s second layer is a forensics primer, and its premise is deliberately provocative: reading a block explorer is a base-rate user skill, like reading a bank statement.

Three abilities carry most of the weight:

1. Read your approvals. The Token Approvals page on any explorer is your exposure surface. Unrecognized unlimited grants get revoked, on a schedule.
2. Trace funds. After an incident, the transaction hash and the receiving address’s trail are your evidence chain. That chain is what exchange compliance desks and police reports act on — it is the only recovery path with a real success rate.
3. Run the four-minute check. Verified source, owner powers, holder concentration, LP lock. It does not catch subtle vulnerabilities. It catches the loud traps, which are most of them.

What we refused to do

We quoted no unverifiable loss figures. Fraud reporting is full of numbers that trace back to press releases, and a paper meant for education cannot carry statistics it cannot stand behind. We also named no individual victims. The paper records patterns — the eligibility-check chain, the fake-support second harvest, the honeypot cycle, the copy-paste poisoning — because patterns transfer and incident details do not.

Where to get it

• English edition (PDF) · 中文版
• Landing page with the full table of contents
• LaTeX source and version history — CC BY-NC-SA 4.0

Version 1.0 covers the taxonomy, forensics, layered defense checklists, four case patterns, and an 18-term core glossary. The companion build log covers why we built it in LaTeX and how the bilingual single-source pipeline works.