DEV Community: Bryan MARTIN

We got scraped, so we built a free Ethereum scam API

Bryan MARTIN — Mon, 29 Jun 2026 15:06:30 +0000

By Bryan Martin - founder of RektRadar. Ethereum scam-detection infrastructure since 2024. GitHub - LinkedIn.

A few weeks ago a single machine on Alibaba Cloud (autonomous system AS45102) found our public /v1 endpoints and decided to take everything. Over three sessions it fired 1,911 requests, most of them automated fuzzing: random hex strings where a contract address should be, malformed query params, the usual "let's see what this thing returns" sweep. Our per-IP rate limiter answered 96% of those calls with HTTP 429. Fewer than 1 in 20 got data back.

The easy move is to block the IP and move on. We did block it. But the incident made an obvious point: people clearly want programmatic access to our scam data, and until now the only "API" was whatever public endpoints they reverse-engineered from the app. So we did the other thing too. We documented the surface, put real rate limits and tiers behind it, and shipped it as a proper free API.

This post is the data behind that decision: what the scraper actually did, what the dataset it was reaching for contains, and how the free tier is designed so that abuse like this stays cheap to absorb while honest developers get a useful amount of access for nothing.

Dataset snapshot

Snapshot: 2026-06-29, 13:44 UTC. Counts are straight SELECTs against our token_analysis table on the production database. No estimates.

N_total analyzed Ethereum tokens: 103,954
N flagged scam (risk_score >= 70): 60,328 (58.0%)
N high-confidence (risk_score >= 90): 3,611
Analyzed in the last 7 days: 3,529, of which 2,870 (81.3%) scored as scams

Two numbers stand out. First, 58% of every token we have ever fully scored is a scam by our 70-or-above threshold. Second, on fresh launches the rate is far worse: 81% of the tokens analyzed in the past week crossed the scam line. New ERC-20s on Ethereum skew overwhelmingly toward fraud, and that skew is exactly what the free API exposes to anyone who wants to check an address before they touch it.

The scraper that started this

Here is what 1,911 calls from one IP looks like in aggregate:

Metric	Value
Total requests	1,911
Distinct sessions	3
HTTP 429 (rate-limited)	~96%
Successful data responses	~4%
Source	one IP, Alibaba Cloud AS45102

The pattern was not a careful integration. It was a fuzzer: garbage in the address slot, repeated hammering of the same feed endpoints, no backoff when the 429s started. That is the signature of someone trying to scrape a dataset wholesale rather than look up a token they actually care about.

The rate limiter held. But "the limiter held" is not a product. A developer who genuinely wants our risk score for one contract should not have to guess at undocumented endpoints and get throttled alongside a fuzzer. So the limits got formalized into tiers, and the endpoints got a docs page at rektradar.io/developers.

The tiers: anonymous, free key, paid

Three levels of access, and you can start at the bottom with nothing:

Access	Rate	Monthly quota	Data freshness
Anonymous (no key)	10 req/min	best-effort	feeds delayed ~10 min, token lookups real-time
Free key (one email)	40 req/min	10,000 calls	feeds delayed ~10 min, token lookups real-time
Paid (from 19.99/mo)	up to 300 req/min	50k to 1M	real-time everywhere

Anonymous is deliberately strict at 10 requests per minute: enough to look up the token you are about to ape into, nowhere near enough to mirror our database. That is the level the scraper was hitting, and 10 req/min is why 96% of its calls bounced.

A free email-verified key lifts you to 40 req/min and 10,000 calls per month. That is a real allowance, not a teaser. It comfortably covers a Telegram bot for a small group, a personal dashboard, or a hobby project that checks every new pair in a feed.

The delay is the paywall

We thought hard about how to keep a free tier genuinely useful without giving away the part that costs us the most to produce: real-time intelligence. The answer is freshness, not feature-gating.

Targeted token lookups are real-time for everyone. GET /v1/token/:address and /v1/token/:address/full return the current score and flags with no delay, on anonymous and free keys alike. If you have a specific contract in hand, you get the live verdict.
The activity feeds are delayed on free. GET /v1/rugs, /v1/recent, and /v1/trends run roughly 10 minutes behind on anonymous and free access. You can build a "recent scams" or "fresh rugs" view for free; you just see it 10 minutes after a paid key does.
Paid removes the delay everywhere, adds WebSocket streams and signed webhooks, and pushes the monthly quota from 50,000 up to 1,000,000 calls.

The logic is simple. The value of a rug-pull alert decays by the minute. Charging for the 10 minutes that matter is honest pricing, and it means the free tier is never crippled, only slightly behind.

Passwordless: a key in one email

Getting a key takes one field. You enter an email at app.rektradar.io/api-key, we send a magic link, you click it, the key appears. No password to create, no card to enter, no sales call. The whole point is that the friction of getting a key should be lower than the friction of writing a scraper, so people use the front door.

Anti-abuse that does not punish developers

The scraper incident shaped the abuse controls, and the design rule was: stop wholesale mirroring without adding friction for a normal integrator.

Per-IP key-creation cap of 3 keys per day. You cannot spin up a hundred free keys from one box to multiply your quota. One developer, a handful of keys, is fine; a key farm is not.
Disposable-email block. Throwaway inbox domains are rejected at signup, so the "one email = 10,000 calls" math cannot be gamed with an infinite supply of burner addresses.
Optional per-key IP allowlist, tier-scaled. You can pin a key to the IPs that are allowed to use it. If a key leaks, it is useless from anywhere you did not authorize. Higher tiers get more allowlist entries.

None of these touch the happy path. A developer who signs up with a real email and calls from their server never sees any of it. They exist to make the scraper's economics worse, not the integrator's.

What you can actually query

The free API exposes the same dataset the scraper was reaching for, the 103,954 analyzed tokens in the snapshot above, through a small set of documented endpoints:

GET /v1/token/:address returns a 0-100 risk score and the on-chain red-flag list (honeypot simulation result, ownership state, liquidity, deployer reputation, and more).
GET /v1/token/:address/full adds liquidity and holder distribution.
GET /v1/rugs?since=14d lists recent rug pulls.
GET /v1/recent is the live analysis feed.
GET /v1/deployers/top is the leaderboard of the wallets that ship the most scams.
GET /v1/stats returns the platform-wide counters (tokens scanned, scams detected, deployers mapped).

There is also an official TypeScript SDK if you would rather not write the HTTP plumbing yourself. With a free key, every one of those is callable today.

Limits of our data

Scorer-conditional, not isolated truth. "58% are scams" means 58% of tokens scored 70-or-above on our multi-signal scale. That is our classifier's judgment, not a court verdict. The threshold is a product choice; move it and the percentage moves.
Selection bias in what gets analyzed. A contract enters token_analysis only when our mempool-watcher or factory-watcher sees it deploy with enough liquidity to matter. Tokens launched through obscure paths, or with no real pool, are under-represented. The dataset describes the tradeable long tail of Ethereum, not literally every contract.
A moving target. The 81% scam rate on last-week launches is a 7-day window ending 2026-06-29. Scam techniques drift, campaigns spike and fade, and these numbers will read differently next month. Treat them as a snapshot, not a constant.
Rate-limit counts are approximate. The 1,911 calls and 96% 429 figures come from our nginx access logs for one source IP across three observed sessions. Session boundaries are inferred from gaps in activity, so "3 sessions" is a reasonable grouping, not a hard count.

TL;DR

A single Alibaba Cloud IP fuzzed our public API 1,911 times across 3 sessions; 96% were rate-limited (HTTP 429).
Instead of only blocking it, we shipped a documented free Ethereum scam-detection API over the same dataset: 103,954 analyzed tokens, 60,328 (58%) flagged scam.
Three tiers: anonymous 10 req/min (no signup), free key 40 req/min + 10,000 calls/month (one email, magic link, no card), paid real-time from 19.99/mo.
The delay is the paywall: targeted token lookups are real-time for everyone; activity feeds run ~10 min behind on free and live on paid.
Anti-abuse (3 keys/IP/day, disposable-email block, optional IP allowlist) targets scrapers, not developers.

Get a free key at rektradar.io/developers and you can query the score, flags, and deployer history for any Ethereum contract in one request, no signup required to start.

JaredFromSubway's bot lost $7.5M to fake tokens. We had already flagged them.

Bryan MARTIN — Mon, 22 Jun 2026 14:29:33 +0000

One of the most profitable MEV bots on Ethereum - the one trading as jaredfromsubway.eth - just lost around $7.5M. And the interesting part is how.

It wasn't a contract exploit. No reentrancy, no bug in a DeFi protocol. It wasn't phishing either - no human signed anything. The bot approved its own robbery, because its automation was tricked into thinking it was about to feast on a juicy MEV opportunity.

We traced the whole thing on-chain. And then we noticed something: our own scanner had already flagged the bait tokens as fakes - up to a full day before the money moved.

How the trap works

ERC-20 has a two-step spend model. To let a contract move your tokens you first call approve(spender, amount), which creates an allowance. The spender can then call transferFrom(you, dest, amount) up to that allowance - and the allowance persists until it is used up or revoked. To save gas, bots and routers often approve type(uint256).max: an infinite, standing blank cheque.

That is the whole attack surface. The sequence:

The attacker deploys fake wrapper tokens (fWETH, fUSDC, fUSDT) and fake pools engineered to look like a juicy arbitrage.
To trade that "opportunity", the bot's own logic approves attacker-controlled helper contracts as spenders of its real WETH, USDC and USDT.
On the early transactions the attacker consumes those approvals immediately - everything looks profitable, nothing trips an alarm.
On later transactions the bot grants approvals that are never consumed or revoked - they sit there, dormant, as standing spend power.
Once enough allowances are stacked, the attacker calls transferFrom and pulls the real assets straight out of the bot.

The bot did exactly what it was built to do. Its strength - aggressive, automated profit-chasing that approves whatever a trade needs - became the hole.

What the chain shows

We pulled the transfers with our own RPC nodes and Etherscan. The receiving wallet is 0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0.

A funded, purpose-built account. It was first funded on Jun 7 with ~19.9 ETH from a throwaway wallet (0xe8b7e6...478703, two transactions of lifetime). It is also an EIP-7702 delegated account: its code points to a smart-account implementation at 0x63c0...ae32b, so a single signed action can run a batched, contract-like routine - convenient when you need to harvest many approvals and fire the drain cleanly.

The drain. Moving directly from the bot contract (0x1f2f10...df387) to the attacker, on Jun 20 between 18:49 and 18:56 UTC, we count:

Asset	Pulled directly from the bot
USDT	2,035,760
USDC	2,870,573
WETH	1,474.58

Routed through real infrastructure - the Uniswap V4 PoolManager and CoW Protocol's settlement contract - to swap the fakes for the real reserves.

The bait. The attacker's fake tokens are exactly what the reports described, plus a few extras:

fWETH  0x6bea01ec24cd029b1ed0898ab30c8f620c8e8c4e   "Wrapped Ether"
fUSDC  0xd370f4e528d83f9941ff2803685552660af7c238   "USD Coin"
fUSDT  0x86070300d54c335717f87dcb11c6515c9a27688e   "Tether USD"
fCAP   0xf2ae7acf310812fb33451610a97020ef961f0521

(homoglyph spoofs of ETH described in the original post.)

The part we did not expect

Impersonation tokens are our bread and butter. We score every new ERC-20 that hits mainnet on 100+ on-chain signals. So we checked the bait against our own API - and the bot was interacting with tokens we had already scored as high-risk fakes, before the drain:

Bait token	RektRadar verdict	Scored at	vs. the drain
fWETH	70/100 - `impersonates_major_token`	Jun 19, 17:38	~25h earlier
fUSDC	70/100 - `impersonates_major_token`	Jun 20, 00:38	~18h earlier
fUSDT	70/100 - `impersonates_major_token`	Jun 20, 00:48	~18h earlier

The flags that fired are exactly the ones you'd want: name_mimics_known_token, impersonates_major_token, deploys_scam_bytecode, mass_deployer, multi_flag_rug_setup. A token literally named "Wrapped Ether" with symbol fWETH, unverified, from a mass deployer pushing known scam bytecode, is not a subtle case.

To be clear: a risk score doesn't reach into a bot and stop it from signing. The bot's flaw was its own approval logic. But the bait was not invisible - it was an off-the-shelf impersonation pattern that an independent scanner had already caught and labelled. The information needed to refuse the interaction existed, on-chain, in advance.

The takeaways

Revoke approvals, and never approve infinity. A standing type(uint256).max allowance to an unknown spender is a blank cheque that survives until someone cashes it. Approve exact amounts, or use scoped/expiring approvals (Permit2-style).
"Is this the real WETH?" is a question, not an assumption. Most of the loss rode on the bot treating fWETH/fUSDC/fUSDT as the assets they impersonate. Impersonation is one of the oldest scam-token patterns on Ethereum, and it is machine-checkable.
Automation needs the same guardrails as humans. A bot making millions still has to ask whether the token in front of it is a fake. That check is a single API call.

We run that check on every new token on Ethereum. You can run it on any contract at rektradar.io, or wire it into your own bot via the API.

All addresses and amounts above are verifiable on-chain. The ~$7.5M net figure is from public reporting; the per-asset amounts are the transfers we traced directly from the bot contract to the attacker.

Add rug-pull protection to your Ethereum bot in 5 lines

Bryan MARTIN — Wed, 17 Jun 2026 08:57:31 +0000

If your bot, wallet or launchpad touches freshly deployed ERC-20s, every one of them is a coin flip: honeypot, hidden mint, unlocked LP, or a deployer who has already rugged ten tokens this week. You can reimplement honeypot simulation and bytecode analysis yourself, or you can ask an API.

Here is the whole thing.

5 lines

npm install @mik3fly-lab/rektradar-sdk

import { RektRadar } from "@mik3fly-lab/rektradar-sdk";

const rr = new RektRadar({ apiKey: process.env.REKTRADAR_KEY });

const verdict = await rr.token("0xTOKEN");
if (verdict.score >= 70) return; // high risk: skip the trade

verdict.score is 0-100 and verdict.flags is a list of machine-readable red flags (hidden_mint, lp_not_locked, ownership_not_renounced, ...). Targeted lookups like this are real-time for everyone. No key? It still runs, anonymously, on the free tier.

No signup to try it

The base URL is https://api.rektradar.io. Anonymous calls work:

curl https://api.rektradar.io/v1/token/0xTOKEN

A key (free or paid) lifts the rate limit and removes the delay on the live feed.

The interesting part: the real-time flow

A verdict that arrives 10 minutes late is worthless, so the live activity flow is the real product: new high-risk deploys (so you avoid them before you buy) and rug events the moment liquidity is pulled. On a free key the flow is delayed about 10 minutes; on a paid key it is real-time. Every response carries dataDelaySeconds (0 = real-time, 600 = delayed).

Poll the REST feed:

const { rugs, dataDelaySeconds } = await rr.rugs({ since: "24h" });

Or subscribe to the push stream and act the moment liquidity is pulled:

import { connectStream } from "@mik3fly-lab/rektradar-sdk";
import WebSocket from "ws";

connectStream({
  apiKey: process.env.REKTRADAR_KEY,
  events: ["new_token", "imminent_rug", "rug"],
  WebSocket,
  onMessage: (e) => {
    if (e.type === "imminent_rug") getOut(e.data.token); // pending rug, before it mines
    if (e.type === "rug") notifyHolders(e.data);
  },
});

Prefer server-side push? Register an HTTPS endpoint and RektRadar POSTs signed events to it:

import { verifyWebhook } from "@mik3fly-lab/rektradar-sdk";

const ok = verifyWebhook(rawBody, req.header("X-RektRadar-Signature") ?? "", SECRET);
if (!ok) return res.sendStatus(401);

What it is (and is not)

Basic honeypot checks are commodity - several providers give them away free. The edge here is the proprietary intel on top: the deployer graph (who deployed, funded by whom), reused drainer-kit bytecode clusters, rug forensics, and the real-time new-deploy and rug feed.

REST + WebSocket + signed webhooks
Official TypeScript SDK (zero runtime deps, isomorphic)
OpenAPI 3.1 reference: https://api.rektradar.io/v1/docs
Docs: https://rektradar.io/developers/

Free to start. Wire the five lines into your buy path and stop trading into honeypots.

Build an Ethereum rug-pull alert bot in 20 lines

Bryan MARTIN — Tue, 16 Jun 2026 11:55:32 +0000

A rug is a race, and dashboards lose it. By the time you alt-tab to a scanner, paste the address, and read the verdict, the liquidity is already in the deployer's wallet. The only thing that keeps up with a rug is another process - something that watches the chain for you and pings the instant a pool dies or a fresh high-risk contract deploys.

That is what the RektRadar API is for. It is live now: the same pipeline behind the web app - honeypot simulation, bytecode signatures, deployer graphs, liquidity and mempool analysis - exposed as a REST endpoint, a WebSocket stream, and signed webhooks, with an official TypeScript SDK on npm.

This post builds a working rug-pull alert bot in about 20 lines. First the one-call check, then the live stream, then how to wire it to Discord, Telegram, or your own trading bot.

The shape of the API

Three surfaces, one mental model:

REST - ask about one token, get a verdict. GET /v1/token/<address> returns a 0-100 risk score and the on-chain flags behind it. Targeted lookups are real-time for everyone.
Stream - subscribe to the firehose. A WebSocket pushes every new deploy, every completed analysis, every rug, as it happens.
Webhooks - same events, delivered to an HTTPS endpoint you own, HMAC-signed so you can trust them.

There is one rule that shapes the whole thing: real-time is the paywall. Everything is free, but the live flow (the stream and the rug feed) arrives on a ~10 minute delay on a free key and in real time on a paid one. A rug alert that is 10 minutes late is worthless to a trader, so that is exactly where the value - and the price - sits. Targeted /v1/token lookups are real-time for everybody. Every flow response carries an X-Data-Delay-Seconds header so you always know what you are looking at.

Get a key

Grab one from your account - no credit card for the free tier: app.rektradar.io/account#api-keys. Pass it as a Bearer token (or the X-API-Key header). No key at all still works - you just get anonymous, delayed access.

The one-call check

Before the bot, the simplest thing the API does: score a single contract. Here is a real honeypot, live on mainnet:

curl -H "Authorization: Bearer rr_live_xxx" \
  https://app.rektradar.io/v1/token/0x682d9d317a077305d36c1fcc9821734046d4de2b

{
  "address": "0x682d9d317a077305d36c1fcc9821734046d4de2b",
  "score": 80,
  "flags": ["honeypot", "hidden_owner", "low_liquidity", "buy_failed", "sell_failed", "scam_factory_name"],
  "name": "BABY ASTEROID",
  "symbol": "BASTEROID",
  "analyzed_at": "2026-05-27T16:31:46.062Z"
}

Same call through the SDK:

npm install @mik3fly-lab/rektradar-sdk

import { RektRadar } from "@mik3fly-lab/rektradar-sdk";

const rr = new RektRadar({ apiKey: process.env.REKTRADAR_KEY });

const v = await rr.token("0x682d9d317a077305d36c1fcc9821734046d4de2b");
if (v.score >= 70) console.warn("high risk", v.flags);

That is the on-demand half: you have an address, you want a verdict. The interesting half is not asking - it is being told.

The bot

Here is the whole thing. It opens the live stream, listens for two kinds of event - a token that just scored high-risk, and a pool that just got rugged - and fires an alert. About 20 lines:

import { connectStream } from "@mik3fly-lab/rektradar-sdk";
import WebSocket from "ws";

connectStream({
  apiKey: process.env.REKTRADAR_KEY,   // paid key = live; omit it and events arrive ~10 min late
  events: ["token_scored", "rug"],
  WebSocket,                            // Node needs the 'ws' package; browsers use the built-in
  onOpen: () => console.log("watching Ethereum for rugs and high-risk deploys..."),
  onMessage: (e) => {
    if (e.type === "rug") {
      alert(`RUG: ${e.data.symbol ?? e.data.address} - liquidity pulled`);
    } else if (e.type === "token_scored" && e.data.score >= 70) {
      alert(`HIGH RISK (${e.data.score}/100): ${e.data.symbol} - ${e.data.flags?.join(", ")}`);
    }
  },
});

function alert(line) {
  console.log(new Date().toISOString(), line);
  // swap this for a Discord/Telegram webhook, a phone push, or a halt on your trading bot
}

Run it with a paid key and the alerts land in real time - roughly 10-12 events a minute across the whole chain, the moment they happen. Run it with no key, or a free one, and the exact same alerts arrive on a ~10 minute delay, which is fine for a research log and useless for front-running a rug. That difference is the entire pricing model in one apiKey field.

The alert() function is the part you make yours. A fetch to a Discord webhook. A Telegram sendMessage. A push notification. Or, if you run an auto-trading bot, a hard stop that refuses to buy anything the stream just flagged.

No always-on process? Use webhooks

If you would rather not babysit a long-lived WebSocket, register an HTTPS endpoint and RektRadar will POST the same events to it. Every delivery is HMAC-SHA256 signed, and the SDK verifies it for you:

import { verifyWebhook } from "@mik3fly-lab/rektradar-sdk";

app.post("/rektradar", express.raw({ type: "application/json" }), (req, res) => {
  const sig = req.header("X-RektRadar-Signature") ?? "";
  if (!verifyWebhook(req.body.toString(), sig, process.env.HOOK_SECRET)) {
    return res.sendStatus(401); // reject anything we did not sign
  }
  const { event, data } = JSON.parse(req.body.toString());
  if (event === "rug.detected" || event === "token.high_risk") notify(data);
  res.sendStatus(200);
});

Same events, no open socket - perfect for a serverless function.

Plans and limits

API access is included in every plan. The free tier is genuinely useful for research, dashboards, and backtesting; the paid tiers buy you real time and headroom.

Plan	Price /mo	Data	Quota	Rate	WS conns	Webhooks
Free	0	~10 min delayed	10k	10/min	1	1
Basic	19.99	real-time	50k	30/min	3	5
Premium	49.99	real-time + forensics	250k	120/min	10	20
Pro	99	real-time + SLA	1M	300/min	30	100

Full endpoint reference, the event catalogue, and the SDK source are on the docs: rektradar.io/developers.

The data was always there - 100+ flags across seven analyzers, scoring thousands of Ethereum tokens a day. Now you can build on it. Ship the bot, point alert() at your channel, and let the chain wake you up instead of the other way around.

The contract is clean - for now: catching crypto scams that survive launch-time checks

Bryan MARTIN — Mon, 15 Jun 2026 15:36:11 +0000

Most token scam detectors, including the one I work on, share one implicit assumption: the contract you analyze at launch is the contract people will trade. Read the source, simulate a buy and a sell, cluster the deployer, score it, done.

That is a snapshot. And a snapshot is exactly what a patient scammer plays against. Two token designs pass every launch-time check and then turn hostile later. This is how they work, and the two on-chain techniques we shipped this week to catch them.

Design 1: the delayed honeypot

A honeypot is a token you can buy but cannot sell. The classic version is non-sellable from block one, so a buy-then-sell simulation catches it instantly.

The patient version is sellable at launch. Early buyers sell fine, the chart looks healthy, the token earns a clean verdict from every checker that judged it at T0. Then, days later, the operator flips a switch:

a timed blacklist that rejects transfers after a block height or timestamp,
a setTrading(false) / pause() kill switch pulled once liquidity has accumulated,
a fee setter cranked to 100% on sells.

From that moment it is a honeypot. But the only verdict on record is the clean one from launch day. The detection ran once, at the worst possible time to run it.

Fix: re-simulate at J7

We keep post-launch snapshots of every token at J0, J7 and J30 (originally to catch slow rugs: volume collapse, late LP burns). The new piece re-runs the full buy/sell honeypot simulation at J7, but only for tokens that were genuinely sellable at J0. A clean-to-honeypot flip is the signal:

// Only for tokens sellable + tradable at J0 - a clean->honeypot flip is the point.
// Bounded per run because it is RPC-heavy.
const eligible = !j0.risk_flags.some((f) => J0_SKIP_RESIM_FLAGS.has(f));
if (rpc && eligible && resims < resimLimit) {
  const isNowHoneypot = await detectLateHoneypot(rpc, tokenAddress);
  if (isNowHoneypot) flags.push("late_honeypot"); // +40 risk at J7
}

One rule we hold to: an RPC hiccup never fabricates a late_honeypot. A failed re-simulation returns "not a honeypot" rather than inventing one. Better to miss a flip than cry wolf on a healthy token.

Design 2: the proxy whose implementation is the payload

A proxy is a thin contract that holds storage and forwards every call via delegatecall to a separate implementation contract that holds the logic. Completely legitimate, extremely common (every upgradeable token uses it). That is exactly why it is good cover.

The trick: you analyze the proxy address. Its bytecode is tiny - "delegatecall to whatever address is in this storage slot." Nothing to flag. The source, if verified, is boilerplate. Clean. Meanwhile the blacklist, the mint, the drain live in the implementation the proxy points to, which nobody looked at - and which an admin can swap in one transaction. The proxy address never changes, so explorers keep showing the same "contract."

So we taught the analyzer to follow the delegatecall.

Resolving the implementation on-chain

You do not need verified source to find the implementation. The proxy standards store the address in well-known storage slots. We read them in order:

// EIP-1967: slot = keccak256("eip1967.proxy.implementation") - 1
let implementation = await readSlotAddress(rpc, address, EIP1967_IMPL_SLOT);

// Beacon proxy: the beacon contract holds the address.
if (!implementation) {
  const beacon = await readSlotAddress(rpc, address, EIP1967_BEACON_SLOT);
  if (beacon) implementation = await callImplementation(rpc, beacon);
}
// then the OpenZeppelin legacy slot, then EIP-1822 / UUPS PROXIABLE.

Then we run the same bytecode analysis we run on any deployed contract against the implementation: function selectors, dangerous opcodes, and a known-scam-factory hash match. If the implementation is byte-identical to a known mass-scam template, the token gets proxy_implementation_known_scam - a clean-looking proxy delegating to a confirmed scam.

Two more signals fall out for free:

proxy_implementation_missing - the proxy points at an address with no code. A loaded trap: deploy malicious logic there (or repoint the proxy) once liquidity has piled up.
mutable_proxy_admin - the EIP-1967 admin slot holds a live address that can swap the implementation at will. A rug switch in plain sight.

One nuance worth stating, because it is a common false-positive trap: an empty admin slot does not mean immutable. UUPS proxies keep the upgrade authority inside the implementation, not the admin slot. So we only raise mutable_proxy_admin on a populated slot, and never claim immutability from an empty one.

The common thread: stop trusting the snapshot

Both detections come from the same shift. A launch-time verdict answers "is this a scam right now?" The questions that actually protect a buyer are "will it still be safe next week?" and "is the code I'm reading the code that will run?"

The delayed honeypot attacks the time axis: clean now, hostile later. Answer: re-judge at J7.
The proxy attacks the indirection axis: clean here, hostile one delegatecall away. Answer: follow the pointer.

Cost stays bounded: the honeypot re-sim only runs on J0-sellable tokens and is capped per cycle; the proxy resolution only fires when the bytecode actually contains a DELEGATECALL opcode, so the millions of non-proxy tokens pay nothing.

If you build anything that judges smart contracts: a clean verdict at launch is a statement about launch, not a promise about next week. Treat it that way.

Full write-up with more detail on the RektRadar blog.

$35M in 4 months: how much ETH Uniswap V2 scam pairs drained

Bryan MARTIN — Thu, 11 Jun 2026 13:09:34 +0000

By Bryan Martin - founder of RektRadar. Ethereum scam-detection infrastructure since 2024. GitHub - LinkedIn.

"How much money do these scams actually steal?" is the question we get most, and most answers out there are extrapolations. We decided to answer it the hard way: by summing every swap, every liquidity mint and every liquidity burn on every Uniswap V2 pair our infrastructure has watched since it went live.

The result: in 4.5 months, buyers collectively lost a net 16,830 ETH (~$35M at the period's average price) inside V2 pairs whose token our scoring pipeline flags as a scam. Ruggers have already extracted 8,257 ETH (~$17M) of it through liquidity pulls. And the single most uncomfortable number: 71% of all Uniswap V2 pair launches we observed were scam pairs.

This is not a model and not a projection. It is SQL over our own event log.

Dataset snapshot

Snapshot: 2026-06-11. Source: RektRadar's events table (29.1M decoded on-chain events captured live since 2026-02-01 by our factory and mempool watchers) joined with token_analysis (93,691 tokens fully scored by the 9-dimension pipeline).

N_total: 20,452 distinct Uniswap V2 pairs created between 2026-02-01 and 2026-06-11
N_filtered: 14,601 pairs (71.4%) pairing WETH with a token scoring >= 70 on our risk scale
Events aggregated on those pairs: 2,770,692 swaps + 46,625 mints + 44,354 burns (deduplicated)
Key metric: 16,830 ETH net buyer losses, 8,257 ETH net extracted by liquidity pulls

The headline numbers

Metric	ETH (WETH)	USD at period avg (~$2,105)
WETH spent buying scam tokens	221,062	$465M
WETH recovered selling them back	204,232	$430M
Net buyer losses	16,830	~$35.4M
Gross buyer losses (losing pools only)	23,207	~$48.9M
WETH seeded by deployers (mints)	16,123	$33.9M
WETH pulled out via burns	24,380	$51.3M
Net extracted by ruggers	8,257	~$17.4M

ETH traded between $1,569 and $2,421 over the window, averaging ~$2,105. At today's price (~$1,661) the net buyer loss is "only" $27.9M, which says more about ETH than about the scammers.

Where the money sits: a pool is a closed box

A Uniswap V2 pair only has four doors for WETH: swaps in, swaps out, liquidity mints, liquidity burns. That makes the accounting honest. Per pool:

Net buyer losses = WETH in via buys - WETH out via sells. This is what traders collectively left inside.
Net extracted = WETH burned - WETH minted. This is what liquidity providers (on a scam pair, the scammer) walked away with beyond their initial seed.

The two numbers bracket the theft. Buyers left 16,830 ETH in the boxes; ruggers have already carried 8,257 ETH out the liquidity-removal door; roughly 8,573 ETH is still sitting inside flagged pairs or left through paths we do not attribute (scammer self-dumps count as ordinary sells in our sums, so the real victim losses are higher, not lower).

The long tail: the median rug steals 0.21 ETH

13,247 of the flagged pairs had at least one swap. 9,295 of them (70%) ended net-negative for buyers. But the median net loss per pool is just 0.21 ETH (~$440).

The Ethereum scam economy is not a few heists. It is an industrial long tail of micro-rugs: deploy a token for pennies, seed 0.5 ETH of liquidity, catch a handful of snipers and tourists, pull, repeat. Our serial scammer wallet anatomy post shows the same pattern from the deployer side; this is what it adds up to on the victim side.

The top 10 pools account for roughly half of all net inflows. Concentration at the top, industrial volume at the bottom.

The biggest drains

Token	Risk score	Net buyer inflow (ETH)	Liquidity pulled?
$ZAYU	80	2,900	not yet
$KNX	85	1,745	not yet
ETHX	80	999	not yet
RISE	80	648	not yet
DU	85	581	not yet
OPNTR	70	419	yes - 412 ETH out
CCLS	80	333	yes - 330 ETH out

The "not yet" rows are the chilling part. The largest flagged pairs still hold their liquidity: thousands of ETH of buyer money sitting in tokens our pipeline scores 80+, one transaction away from extraction. OPNTR and CCLS show what that transaction looks like: when the pull comes, it takes essentially everything.

Why we excluded Uniswap V3 (and you should distrust V3 "stolen" stats)

We ran the same aggregation on 3,869 flagged V3 pools and got numbers that violate conservation: 487,266 WETH burned out of pools that only ever received 315,582 via mints and 2,299 net via swaps. Impossible - unless WETH enters pools through untracked direct transfers, which is exactly what liquidity-cycling and wash-trading setups do.

Two tokens (uPEG and ASTEROID) account for 72% of that fake volume, with hundreds of thousands of ETH churned in and out as LP positions. None of it is victim money. Any "X million stolen" figure built naively on V3 burn events will be inflated by an order of magnitude. Scams launch on V2; V3 is where volume-faking lives.

Methodology

Scam set: tokens with risk_score >= 70 in token_analysis (42,796 of 93,691 analyzed - the threshold and pipeline are detailed in our 78k-token breakdown).
Pool set: V2 pair_created events where one side is canonical WETH and the other side is in the scam set.
Aggregation: per pool, sum the WETH legs of swap (amountIn/amountOut), mint and burn events, deduplicated on (tx_hash, log_index) because our pipeline writes both pending and confirmed states.
Totals: net figures sum all pools; gross figures sum only pools where the per-pool net is positive (so winners do not mask losers).

The full analysis (SQL included) lives in our infra repo, and the aggregate is now exposed live: the same numbers power the "all time" counter on rektradar.io and refresh every 6 hours.

Limits of our data

Scorer-conditional totals. "Scam pair" means "paired with a token our multi-flag scorer puts at 70+". False positives inflate the totals; false negatives (scams we scored under 70) deflate them. Our precision/recall audit suggests the two do not cancel neatly.
Net != victim losses. Scammer self-dumps are indistinguishable from ordinary sells in pool-level sums, so net buyer losses understate what real victims lost. Winning snipers also capture part of the flow: not all of it ends in scammer wallets.
Sampling window and scope. 2026-02-01 to 2026-06-11, Ethereum mainnet, Uniswap V2 WETH pairs only. No V3/V4 (see above), no stablecoin-quoted pairs, no other DEXes, no L2s. The true ecosystem-wide figure is strictly larger.
Still-live pools can move. ZAYU-style pairs holding thousands of ETH may still rug (raising extraction) or, rarely, turn out legitimate (lowering losses). The 6-hourly recompute will track it.

TL;DR

71% of the 20,452 Uniswap V2 pairs launched since February pair WETH with a token we flag as a scam (risk >= 70)
Buyers net-lost 16,830 ETH (~$35M at period prices) inside those pairs; gross losses on losing pools: 23,207 ETH
Ruggers already extracted 8,257 ETH (~$17M) via liquidity pulls; ~8,500 ETH of buyer money still sits in flagged pairs
The median rug nets just 0.21 ETH - it is an industrial long tail, not a few heists
V3 burn-based "stolen" stats are inflated by LP churn and wash trading; we measured and excluded it

Try the free scan, no signup, no card - the 14,601 pairs in this post were all flagged automatically before most of them had their first victim.

What I shipped in one Claude Code session: a real-time mempool rug-detector pipeline

Bryan MARTIN — Wed, 10 Jun 2026 19:29:12 +0000

I run RektRadar, a real-time scam-token detector for Ethereum. This is an honest build-log of one session with Claude Code (the Fable model) where I went from "our scam detection misses a few things" to four new detection signals shipped and a three-repo real-time alert pipeline live in production. Every PR linked below is public.

Not "the AI did everything magically". The interesting part is the division of labor: where an agent is genuinely strong, where I had to steer, and the one moment it was about to do something dumb and I stopped it.

The setup

RektRadar is ~7 repos: a mempool watcher, a contract analyzer (7 sub-analyzers), a graph crawler, a Telegram bot, an Astro marketing site, a Vue app, and the Ansible infra. Node/TypeScript throughout, real test suites (the contract analyzer alone has ~7,000 tests).

I started the session with a list of detection gaps a security discussion had surfaced, and worked down it.

1. The headline: catching a rug in the mempool, before it mines

A rug is usually a single transaction: removeLiquidity, setFee to a confiscatory tax, setBlacklist, pause, mint. Between broadcast and inclusion it sits in the public mempool for seconds. We already stream pending txs for sandwich detection, so the move was to watch those same txs for a rug action against a token we already flagged as high-risk.

The design Claude landed on, mirroring the existing DeployWatcher pattern in the repo:

export function classifyPrivilegedCall(
  tx: PrivilegedTxLike,
  byToken: Map<string, WatchEntry>,
): PrivilegedAlert | null {
  const selector = (tx.data ?? "0x").slice(0, 10).toLowerCase();

  // liquidity removal goes through the router, but the token is in the calldata
  if (LIQUIDITY_REMOVAL_SELECTORS[selector]) {
    const token = decodeRemovedLiquidityToken(tx.data);
    const entry = token ? byToken.get(token) : undefined;
    return entry ? { kind: "liquidity_removal_pending", ...entry } : null;
  }
  // owner functions (setFee/blacklist/pause/mint...) are called on the token itself
  const entry = byToken.get((tx.to ?? "").toLowerCase());
  ...
}

A pure classifier + an injected watcher that refreshes the high-risk token set every few minutes. That split mattered: the classifier got 19 unit tests with zero mocks, while the I/O stayed in the watcher. This is the thing agents are quietly good at - given a clean existing pattern, they reproduce its shape rather than inventing a new one.

This is where it gets cross-service. The detection lives in the mempool watcher; the alert needs to reach a Telegram channel. So the session built a three-repo pipeline:

a Postgres privileged_alerts hand-off table (infra migration),
the mempool watcher writing detected alerts to it (idempotent on tx hash),
the Telegram bot polling unposted rows and posting an "imminent rug" message, stamping posted_at so each fires once.

Decoupled producer/consumer, each with its own tests. All three merged and deployed in the same session.

2. Where I had to keep it honest

The ABI verification. The lock-quality signal needed to read a liquidity lock's unlock date to flag "lock expires in 3 days". That means reading the UNCX locker contract on-chain. Claude wanted to write the read against the documented tokenLocks(lpToken, index) ABI. I made it verify the struct against the live contract first - we pulled a real locked token off the locker's global index and decoded an actual unlockDate before trusting the field order. On a security tool, a misread field that emits a false "this is safe" is worse than no signal. The agent will happily write plausible code; the human has to insist on grounding it.

The sybil false-positive. The sybil-holder signal clusters top holders by their funding source - dozens of fresh wallets funded by one address is fake demand. The trap: a cohort that all withdrew from the same exchange is normal. Without a CEX exclusion list this would false-positive on half of crypto. We pulled the 64-address exchange set from the graph-crawler service and excluded it. This is the kind of domain constraint that does not show up in the code, only in the consequences - exactly what you need a human in the loop for.

The "don't push" moment. At one point I asked Claude to open a PR, then immediately realized I wanted to review the branch more first. It had already opened it. It converted it to draft within seconds of my "wait", then closed it cleanly when I confirmed. Cheap recovery, but a reminder that "open a PR" is an outward action you want a beat of confirmation on.

3. What actually shipped

Four new signals, all live:

Mempool imminent-rug warning (the pipeline above)
Sybil-funded holders - funding-graph clustering with CEX exclusion
Lock quality - partial lock + verified-on-chain expiring lock
Phishing-bait - URL / claim-channel in the token's on-chain name

Plus the supporting work: the signal documentation catalogue went from 55 to 105 pages (every flag the analyzers raise now has a page explaining it), and a UI palette/spacing refresh on the app.

~18 PRs across 7 repos, all merged through the normal CI + review pipeline, all with tests. The mempool watcher suite is at 2,496 tests, the contract analyzer at ~7,089, the Telegram bot at 114.

The honest scorecard

What the agent was strong at:

Pattern matching the codebase. New code looked like the surrounding code - same logger shape, same port/adapter split, same test style.
Test discipline. Every behavior change came with tests, and it iterated on real failures (a couple of mocked-config tests broke when I added a new export; it found and fixed them).
Cross-service plumbing. Holding the shape of a producer/consumer pipeline across three repos without losing the thread.

What needed me:

Grounding claims in reality (verify the ABI live, don't trust the docs).
Domain constraints that only show as false positives (the CEX exclusion).
Outward actions (the PR I didn't want pushed yet).

The summary I'd give: it is a very fast, very literal pair-programmer that is excellent at the "how" once you are clear on the "what" - and a security tool is exactly the place where you still own the "what".

You can paste any Ethereum token address into the free detector at rektradar.io and watch these signals run live. If you want the product-side writeup of the signals themselves, that's on the blog.

We thought we caught every scam token. A dev.to post showed us a blind spot.

Bryan MARTIN — Tue, 09 Jun 2026 16:30:53 +0000

We run a real-time scam-token detector for Ethereum. It analyzes new ERC-20s, simulates buys and sells to catch honeypots, clusters deployers and funders, and scores everything live. After four months and ~93,000 analyzed contracts, we were fairly sure our funnel saw everything that mattered.

Then @sanjeevkkansal published evm-deploy-watch, an MIT-licensed week-long study of every new contract on Ethereum. It is a genuinely good piece of work, and it did two things for us. First, it independently validated our core thesis. Second, it pointed a flashlight straight at a blind spot we did not know we had.

This is the gap, measured, and how we closed it.

The thesis we already shared

The deploy-watch author's central finding is that deploy-time heuristics beat lagging public blacklists. Reading source code, deployer history, and bytecode the moment a contract is created catches scams days before they show up on a blocklist. The study reported essentially zero overlap with ScamSniffer's feed - the contracts it flagged were not (yet) on anyone's list.

That is exactly the bet our pipeline is built on, so it was great to see it confirmed by someone with a completely independent dataset and methodology. The article's "future next steps" section reads almost like our changelog: buy/sell simulation, CREATE2 / factory clustering, deployer-funder graphs, multi-signal scoring. We already run those in production. More on that at the end, because the honest part of this post is the thing we were not doing.

The blind spot: our funnel is DEX-triggered

Here is the architectural assumption that bit us.

Our ingestion is driven by liquidity. A factory-watcher service reacts to Uniswap V2/V3/V4 pool creation events. When a token opens a pool, it enters the funnel and gets the full analysis: source regex, bytecode clustering, a real buy-then-sell simulation, deployer graph, scoring. This is the right trigger for the scams we care most about, because a rug or a honeypot needs a pool. You cannot trap a buyer who cannot buy.

But there is an entire family of fraud that never creates a pool, because it never intends for anyone to trade it.

FlashUSDT / fake-Tether: a scam with no on-chain victim

The "FlashUSDT" or "proof-of-funds" family works entirely off-chain. The mechanics:

An operator deploys an ERC-20 whose name() returns Tether USD, symbol() returns USDT, and decimals() returns 6. Anyone can do this. Nothing on-chain stops you from naming your token whatever you want.
They send a large balance of this token to a wallet, or show you a wallet that holds it. Your wallet UI and most explorers read the metadata and display it as 250,000 USDT.
They give you a reason the "funds" need to move: an OTC deal, an escrow proof, a job signing bonus, a "liquidity bot" demo.
You send something genuinely valuable in return - real USDT, ETH, goods, a token approval.
The fake balance was always worth zero. There is no pool, no price, no trade. The whole con is the spoofed metadata plus social engineering.

Because these tokens never touch a DEX, simulation-based detection never sees them. There is nothing to simulate. They are invisible to anything that waits for a Uniswap pair - including, it turned out, us.

The gap, quantified

Numbers, because "we have a blind spot" is a feeling and "we capture 0.5% of this family" is a bug report.

Our database held 15 FlashUSDT-named tokens across four months (2026-02-12 to 06-08), out of 93,000 analyzed.
The deploy-watch study observed roughly ~192 per week of this family in its window (134 FlashUSDT + 58 FlashUSDTLiquidityBot).
So we were capturing on the order of ~0.5% of it.
The two contracts the article dissects in detail were simply not in our database at all.

This is not a scoring miss. It is a coverage miss: the contracts never entered the funnel, so there was nothing to score. You cannot rank what you never ingest.

Closing it: ingest every deploy, not every pool

The fix is conceptually simple - watch contract creations, not pool creations - and the engineering is mostly about keeping the volume bounded.

We already run a mempool-watcher that streams pending transactions. A contract creation is just a transaction with to === null. So the cheapest place to hook this in is right there in the mempool loop:

// main-loop.ts - a contract creation is a tx with no recipient
if (tx.to === null && adapters.deployWatcher) {
  adapters.deployWatcher.onDeploy({ from: tx.from, nonce: tx.nonce, hash: tx.hash });
}

The deploy watcher predicts the contract address from the sender and nonce, waits for the deploy to mine, reads two metadata fields, and only then decides whether the contract is worth a full analysis:

import { Contract, JsonRpcProvider, getCreateAddress } from "ethers";

const ERC20_MIN_ABI = [
  "function name() view returns (string)",
  "function symbol() view returns (string)",
];

onDeploy(tx: DeployTx): void {
  let address: string;
  try {
    address = getCreateAddress({ from: tx.from, nonce: tx.nonce }).toLowerCase();
  } catch {
    return; // CREATE2 / malformed - out of scope for v1
  }
  if (seen.has(address)) return;  // dedupe; bounded Set, cleared at 50k
  seen.add(address);

  setTimeout(async () => {
    const code = await provider.getCode(address);
    if (!code || code === "0x") return; // reverted or not mined yet

    const c = new Contract(address, ERC20_MIN_ABI, provider);
    const [name, symbol] = await Promise.all([
      c.name().catch(() => ""),
      c.symbol().catch(() => ""),
    ]);

    if (isImpersonation(String(name), String(symbol), address)) {
      await opts.enqueue(address); // -> analysis_queue -> contract-analyzer
    }
  }, delayMs); // ~45s: deploys are seen pending, read metadata after they mine
}

A few deliberate choices in there:

Metadata-only triage. At this stage we make exactly two eth_calls: name() and symbol(). No simulation, no source fetch, no graph. The study counted ~1,200 top-level deploys per day. Two reads each, against our own Nethermind node, is nothing. The expensive analysis only runs for the handful that actually spoof a major token.
Predict-then-confirm. getCreateAddress(from, nonce) gives us the deterministic address for a plain CREATE deploy, so we can start watching it the moment the tx is pending and read its code once it mines.
A seen Set, bounded. Deploys can appear multiple times across mempool snapshots; the set dedupes and self-clears at 50k entries so it never leaks memory. Re-checking a stale address is harmless.
CREATE2 is out of scope for v1. Factory-deployed contracts whose address depends on a salt are not covered by getCreateAddress. We flagged this as a known limitation rather than pretending otherwise - it is a real future item.

The check that defeats the whole family

The actual detection is almost anticlimactic, and that is the point. A token is its address, not its name. The real USDT lives at exactly one contract. Anything claiming to be USDT at any other address is, by definition, not USDT.

So the signal is: name or symbol matches a major token, and the address is not the canonical one.

const CANONICAL_TOKENS: Record<string, { address: string; name: string }> = {
  USDT:   { address: "0xdac17f958d2ee523a2206206994597c13d831ec7", name: "tether usd" },
  USDC:   { address: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", name: "usd coin" },
  WETH:   { address: "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", name: "wrapped ether" },
  DAI:    { address: "0x6b175474e89094c44da98b954eedeac495271d0f", name: "dai stablecoin" },
  WBTC:   { address: "0x2260fac5e5542a773aa44fbcfedf7c193bc2c599", name: "wrapped btc" },
  // ... FRAX, LUSD, BUSD, stETH, wstETH
};

export function isImpersonation(name: string, symbol: string, address: string): boolean {
  const addr = (address || "").toLowerCase();
  const sym = (symbol || "").toUpperCase().trim();
  const nm = (name || "").toLowerCase().trim();
  for (const [canonSym, info] of Object.entries(CANONICAL_TOKENS)) {
    const matches = sym === canonSym || (nm.length > 0 && nm === info.name);
    if (matches && addr !== info.address) return true;
  }
  return false;
}

The pitfalls hide in that tiny function:

The allowlist is the safety rail, and it has to be exact. If you get one canonical address wrong, you either miss a whole family or, worse, you flag the real USDT as a scam. Every address is stored lowercased and compared lowercased so EIP-55 checksums never cause a false negative.
Exact match, not fuzzy. We compare symbol === "USDT", not symbol.includes("USDT"). Fuzzy matching would light up every legitimate bridged or wrapped variant (USDT.e, axlUSDC, and friends) and bury the real signal in false positives. The trade-off is that a typo-squat like USDTT slips this specific check - but those usually do open a pool and get caught by the rest of the pipeline.
Duplicated, on purpose. The same map and check live in both mempool-watcher (the cheap pre-filter) and contract-analyzer (the authoritative signal). The list is ten lines and changes maybe twice a year; a shared package would be more ceremony than it is worth.

When the pre-filter enqueues an address, contract-analyzer runs the same check as a first-class signal and the scorer applies a hard floor:

// risk-assessment.ts - impersonation is high-severity regardless of other signals
if (allFlags.includes("impersonates_major_token")) {
  score = Math.max(score, 70);
}

A fake USDT with no pool and no trading history would otherwise score near zero on a pipeline built around liquidity and honeypot mechanics. The floor says: a contract pretending to be a major asset at a fake address is dangerous on its own, full stop.

The result

The deploy-watch path and the impersonation signal went fully live on 2026-06-08. The first two days:

	Coverage of the impersonation family
Before (DEX-triggered)	15 in 4 months - about 0.5% of the wild rate
After (deploy-time)	77 in 2 days: 30 fake USDT, 26 fake USDC, 21 fake DAI

77 in two days is roughly 270 per week, which puts us above the ~192/week the study observed - and every one of them was flagged at deploy time, with no pool, off two eth_calls. The blind spot is now one of our better-covered families.

What we were already doing on top

Credit where it is due: the deploy-watch study is the reason we found this, and its author is clearly building toward the same place we are. The difference is mostly that we have had a head start on the items he lists as "next steps", so if you are building something similar, here is what is worth adding after deploy-time metadata:

Real buy/sell simulation. We execute a buy then a sell against the live pair across multiple amounts. A contract that accepts buys and silently reverts sells is a honeypot, no matter how clean its source reads.
Bytecode clustering. We hash deployed runtime bytecode and group identical contracts. One scam template gets reused thousands of times; clustering turns "a new scam" into "the 4,050th token off a known factory".
Deployer and funder graph. We trace who deployed a contract and who funded that wallet, through mixers where possible. A throwaway EOA funded one hop from a known scam operator is a strong prior before you read a single opcode.
Multi-signal weighted scoring with floors. No single heuristic decides. Signals combine into a score, and high-severity ones (like impersonation) set floors so a dangerous contract cannot be averaged down to "safe".
Live, not batch. All of this runs as contracts appear, not in a nightly sweep.

None of that helped against FlashUSDT, because FlashUSDT never enters the part of the pipeline where any of it runs. That is the lesson worth keeping: a detector is only as good as its ingestion. The cleverest scoring in the world is useless on a contract you never ingested. We had spent months tuning the scoring and almost none questioning the trigger.

It took an outside writeup, with a different dataset and a different goal, to make the assumption visible. Thanks for that.

You can paste any token address into the free detector at rektradar.io to check whether it is the real asset or an impersonator. If you want the user-facing version of how this scam plays out, we wrote that up here.