Most scam checks are post-mortems. They tell you a token is a honeypot after someone is trapped, or that liquidity is gone after the rug. Useful, but late.
This week we shipped four new detection signals. Three of them are sharper versions of static checks. The fourth is a different category entirely: it watches the mempool for the rug transaction itself and flags it before it is mined - seconds of warning instead of a post-mortem.
Our signal catalogue went from 55 to 105 documented signals in the process. Here is what the four new ones catch.
1. The mempool warning: a rug action seen before it lands
A rug is almost always a single transaction the operator broadcasts: removeLiquidity, setFee (up to a confiscatory tax), setBlacklist, pause, mint. Between broadcast and inclusion, that transaction sits in the public mempool for seconds to minutes.
We already stream pending transactions to catch sandwich attacks. So we added a watcher that keeps a live set of the high-risk tokens we have recently scored, and for every pending transaction asks one cheap question: does this touch one of those tokens with a privileged, value-affecting function?
- Liquidity removal goes through the router, but the token address is right there in the
removeLiquidity(token, ...)calldata - we decode it and match. - Owner functions (
setFee/ blacklist /pause/enableTrading/mint/transferOwnership) are called directly on the token, so the target address is the match. The function selector labels the alert; an unrecognized call to a tracked high-risk token still surfaces as a generic owner interaction.
When it fires, the token is re-scored immediately (its on-chain state is changing) and an imminent-rug alert is posted to our Telegram channel - the one signal where seconds genuinely matter. Ordinary transfers and approvals never trigger it; the whole point is to isolate the operator’s hand on the lever.
It is armed and live. It will not catch every rug - a deployer who routes through a private relay (Flashbots) is invisible in the public mempool, and that opacity is itself a risk signal - but for the ones broadcast in the clear, it turns a post-mortem into a warning.
2. Sybil-funded holders: fake demand, not real holders
Holder count and a flat distribution chart are the trust signals retail leans on. They are also the easiest to fake: take one bag, split it across dozens of fresh wallets funded from a single source minutes before launch, and the supply looks organic.
Concentration checks miss this - each puppet wallet holds little. The funding graph gives it away. For the top holders we now resolve each wallet’s first funding source and cluster by funder. When several holders trace back to the same non-exchange address, that is the sybil signal.
The one thing that makes this safe rather than noisy: we exclude exchange hot wallets. A cohort that all withdrew from the same Binance address is normal; a cohort all funded by one anonymous EOA is a puppet show. Skipping that exclusion would false-positive on half of crypto.
3. Lock quality, not just “is it locked?”
A “liquidity locked” badge is binary in most checkers, and scammers exploit exactly that. Two failure modes hide behind a green checkmark:
- Partial lock - half the LP sits in a locker, half in a wallet the operator controls. Enough to pass a yes/no check, not enough to protect anyone.
- Expiring lock - the lock is real but unlocks in days. We read the actual unlock date from the UNCX locker on-chain; a three-day lock during launch hype, then a pull, is a classic.
Lock duration and coverage matter as much as lock existence. Now we report both.
4. Phishing-bait tokens: the metadata is the attack
Not every scam is a rug. A whole class of tokens is airdropped en masse to random wallets with a URL or claim-channel baked into the on-chain name - “Visit claim-xyz.com to redeem”, “t.me/freedrop”. They never trade; the spoofed metadata is the entire con, luring holders to a drainer site.
Because they have no pool and no trading history, pool-based and honeypot checks never see them. We now flag a token whose name() or symbol() carries a URL, a scam-TLD domain, or a claim-channel invite as name_contains_url - detectable the moment the contract is deployed. (We deliberately ignore bare @handles and TLD-substrings inside ordinary words, so “DeFi” and “config” don’t trip it.)
Why we publish the signal list
Every flag our analyzers can raise has a public page explaining what it means, why it puts funds at risk, and how we detect it on-chain - 105 of them now. It is documentation, but it is also the honest version of a scam detector: no black box, no “trust the score”. You can read exactly what each judgment is built on.
You can paste any Ethereum token address into the free detector at rektradar.io and see these signals applied live.