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.

DEV Community: Bryan MARTIN