By Bryan Martin - founder of RektRadar. Ethereum scam-detection infrastructure since 2024. GitHub · LinkedIn.
Crypto has a “fake project” problem and a “fake token” problem. The first is a marketing problem - Discord servers, KOL hype, fake roadmaps - and there is no purely technical way to detect it. The second is a contract problem, and it is mostly solved: on-chain scams leave the same handful of fingerprints, and once you know them, ten seconds and a contract address is enough.
This guide takes the second problem head-on. We analyzed 78,723 Ethereum tokens at deployment time using a 9-dimension scanner (honeypot simulation, source code patterns, bytecode opcodes, liquidity, holder distribution, deployer history, graph relationships, real-time events, sandwich detection). 36,263 of them - 46% - came back as scams (risk score >= 70). Below are the nine on-chain signals that flagged almost all of them, in plain English, with the exact rate at which each appears among confirmed scams.
What “fake cryptocurrency” actually means in practice
People use the phrase to mean three different things. Pretending they are the same is why most beginner guides land off-target.
- Honeypots. Buy transactions succeed, sell transactions fail. You can buy the token; you can never sell it. The contract is written so only an allow-listed wallet (the deployer’s) can exit. Around 45% of our scam set are honeypots in some form.
- Rug pulls. The contract is technically OK at deployment. The owner adds initial liquidity, retail buys, then the owner pulls the liquidity and disappears. The token’s chart shows a vertical line straight down. Around 30% of our scam set rugs within 60 minutes of launch.
- Brand-jacks. A scam contract reuses a famous ticker (USDC, $TRUMP, $CLAUDE) on Ethereum. The real token does not exist on the chain the scammer is using, or it does but at a totally different address. The scam piggybacks the headline. Around 8% of our scams. See also our list of fake crypto exchanges for the exchange-side version of the same problem.
The nine signals below cover all three categories. Some of them (honeypot simulation results) are deterministic; others (deployer profiling, ownership patterns) are statistical. We give the precision rate for each so you can weight them yourself.
Methodology
Dataset snapshot: 2026-05-15. 78,723 Ethereum tokens analyzed at deployment time over the last 90 days. 36,263 classified as scams (risk score >= 70).
Every token was analyzed by RektRadar within a few minutes of contract deployment (the analyzer sits on a mempool watcher that catches new token factories). Each token receives 80+ binary flags across the 9 dimensions. We then took every token with risk score >= 70 (our “scam” threshold, calibrated on labeled honeypot/rug data) and counted the flag occurrences. The ”% scams” number under each signal below is: of all tokens that tripped this flag, the share that ended up with risk score >= 70.
A signal showing 100% does not mean “every token with this flag was a scam” in some absolute sense - it means every token with this flag was classified as a scam by our 9-dimension scorer that uses many flags. A signal showing 65% means: about two-thirds of the tokens carrying this flag also tripped enough other flags to cross the scam threshold. Both numbers are useful in different ways.
Limits of our data
Three caveats a careful reader should know before using these numbers in isolation:
- The percentages are scorer-conditional, not isolated predictive power. A flag tripping at 90% scam-rate means 90% of the tokens carrying that flag were classified scam by the multi-flag scorer, which uses many overlapping signals. The isolated predictive power of a single flag - what % of tokens with only that one flag are scams - is lower. We give the conditional rate because it reflects how the signal works in practice (signals co-occur), but a Bayesian read of the data would adjust downward.
- Sampling window. The dataset is a 90-day snapshot ending 2026-05-15. Scam techniques drift: new bytecode patterns appear, others get patched out. The signals on this list are stable across our 18-month history, but the exact percentages will shift over time. Treat them as 2026 baselines, not constants.
- Selection bias toward “new tokens with liquidity.” Our analyzer catches tokens at deployment time via a mempool watcher and a factory watcher. A token that never gets liquidity added or that is deployed on an obscure factory contract may not enter the dataset. The base rate of “tokens that look real enough to bother indexing” is therefore elevated compared to the entire chain, where the majority of contracts deployed are abandoned, never funded, or test artifacts.
Where it matters, the body of this article calls out which signals are deterministic (#1-#3) versus probabilistic (#5-#9).
1. The contract is a honeypot
11,222 tokens flagged. 100% of them are scams. (signal page →)
This is the most damning signal in the dataset. Our scanner simulates a buy transaction and then a sell transaction on a forked mainnet at the current block. If the sell transaction reverts on a contract where the buy succeeded, the token is a honeypot. Full stop.
How to spot it manually: paste the contract address into Honeypot.is or GoPlus’s free scanner. They run the same kind of simulation. If either says “sell failed”, do not buy. There is no nuance: a contract whose sell function reverts under a normal call has been engineered that way on purpose.
2. The sell function fails in simulation
10,345 tokens flagged. 100% scams. (signal page →)
A subtype of the above. The honeypot detector specifically caught a transfer() revert from a holder that just bought the token. This sometimes happens because of a _taxFee over 100% (only the deployer can sell because they are excluded from the fee), sometimes because of an explicit allowlist, sometimes because of a _isTrading flag the owner controls. The mechanism does not matter - the outcome does.
How to spot it manually: same as #1. You don’t need to read the code; you need the simulation.
3. The buy function fails in simulation
9,521 tokens flagged. 100% scams. (signal page →)
The opposite trap and rarer. The contract refuses buys from unknown addresses. This is usually a soft honeypot in development: the deployer is gating buys to a whitelist and will open it up “after presale” - except the presale never opens. If a freshly deployed token won’t even let you buy, that is the deployer telling you what they think of you.
How to spot it manually: the honeypot simulators above will report a BUY_FAILED error. You can also check the Etherscan “Transactions” tab and look at whether buys are succeeding from non-deployer wallets in the first few blocks. If only one wallet has bought, that is your answer.
4. The liquidity pool has almost no ETH
8,652 tokens flagged. 100% scams. (signal page →)
The deployer added liquidity, but the ETH side of the pool is under 0.1 ETH. This is either a rug-in-waiting (the deployer will pull the tiny liquidity for 0.08 ETH the moment retail buys arrive), a scaffolding launch (the contract was deployed without serious intent to trade), or a brand-jack designed to pop on a search result rather than to actually trade.
How to spot it manually: open DEX Screener and paste the contract. If the liquidity column shows under $200, treat it as a scam. Real projects do not launch with $50 of liquidity, regardless of what the Telegram says.
5. The contract has an approve_with_transfer pattern
8,907 tokens flagged. 85.9% scams.
This is the most technical signal on this list and also one of the most predictive. The contract’s approve() function silently calls transfer() on the caller’s balance - meaning if you sign an approval for this token (which DEXes ask you to do before swaps), the contract immediately drains your tokens to the deployer. You think you are approving Uniswap to spend your USDC. You are actually approving the scam contract to take your USDC.
How to spot it manually: this one is hard without tooling because it requires reading the contract source. The shortcut: if the contract is unverified on Etherscan (no source code published) and the token is brand-new (under 24h old), assume the worst. 85.9% of tokens with this pattern are scams in our dataset; the remaining 14.1% are legitimate contracts that happened to use the pattern for reasons unrelated to draining (proxy upgrades, etc.). For a beginner, the heuristic “unverified + brand new” gets you most of the way.
6. The contract is pausable by the owner
5,908 tokens flagged. 90.9% scams.
The contract has a pause() function that the owner can call at any time. Once paused, no one can buy or sell. This is the soft-honeypot mechanism: the owner lets retail buy for a few hours, pauses trading, and dumps their own bag privately via internal allowlisted functions.
How to spot it manually: open the contract on Etherscan, click “Contract” → “Read Contract”, and look for a paused boolean or a pause() function in “Write Contract”. If you see either, the owner can freeze trading at will. Legitimate tokens almost never have this - once a token is launched and decentralized, there is no reason for an owner to retain the ability to pause it.
7. The contract has a blacklist function
5,154 tokens flagged. 90.2% scams. (signal page →)
Same shape as #6 but more targeted. The owner can blacklist specific addresses, after which those wallets can no longer sell. The pattern goes: retail buys, owner watches who is about to dump (e.g. someone selling a large bag), blacklists their address, dumps before them. The blacklisted wallet is now holding a bag they cannot exit.
How to spot it manually: same Etherscan “Read Contract” tab. Look for blacklist, setBlacklist, isBlacklisted, or similar function names in “Write Contract”. A real ERC-20 has none of these. Etherscan also shows recent state changes - if you see blacklist entries being added in the hours before a price crash, you are looking at the playbook in action.
8. The deployer wallet is brand new
6,632 tokens flagged. 89.9% scams. (signal page →)
The wallet that deployed this contract was created less than 24 hours before the deployment, has under 5 transactions total, and was funded by either a CEX hot wallet or another fresh wallet that itself was funded by a CEX hot wallet. This is the standard scam-factory pattern: each scam gets its own clean wallet so the on-chain trail does not link back to previous scams.
How to spot it manually: on Etherscan, click the “Contract Creator” address. Look at:
- Date of first transaction - if under 7 days old, that is a warning sign
- Total transaction count - if under 10, warning sign
- Funding source - if the wallet was funded by a single CEX withdrawal and nothing else, very strong warning
The exception is legitimate projects launched by professional teams who use a dedicated deployment wallet, but those wallets are also usually announced in the project’s docs. If a deployer is brand new AND the project has no docs page identifying them, the answer is almost always scam.
9. The contract was deployed inside a known scam factory cluster
5,145 tokens flagged. 89.8% scams. (signal page →)
The deployer wallet for this contract is graph-connected to at least one previously-flagged scam - same funder, same deployer pattern, same bytecode template. Scam contracts almost always come in batches: one factory wallet deploys dozens of similar honeypots, each on a fresh wallet, each funded by the same upstream source. Once you have ID’d one wallet in the cluster, the others can be detected by graph proximity.
This is the signal that beginners cannot really replicate manually. Mapping a 3-hop funder graph back from a deployer to known seeds takes infrastructure (we use a dedicated graph-crawler service per chain). What you can do as a beginner: search the project’s contract address on /scam/<ticker> - if the same ticker appears with 200+ other contract addresses, the ticker is a known brand-jack target.
How to combine these signals
A single signal is rarely enough to call a token a scam. Honeypot detection (#1, #2, #3) is the exception - those three are deterministic and a single positive is sufficient. The other six are probabilistic: any one of them in isolation might be a false positive (legitimate tokens occasionally have a pause() for legal compliance reasons, for instance). The rule that works on our dataset:
- 3 or more flags from this list of 9 → 89% chance of scam
- 5 or more → 96%
- Any of #1, #2, or #3 → 100%
If you are going to do this manually for every token you consider buying, the realistic process is:
- Run the address through a honeypot simulator (#1/#2/#3). Free. Ten seconds.
- Check Etherscan for source verification, pause function, blacklist function (#6, #7). Free. Two minutes.
- Check the deployer wallet’s age and funding source (#8). Free. One minute.
- Check liquidity on DEX Screener (#4). Free. Thirty seconds.
That covers six of the nine signals in under five minutes. The remaining three (#5 approve_with_transfer, #9 cluster detection, and the deeper deployer graph) require reading contract source code or running tooling, which is the actual reason scanners exist.
How a scanner does this in 10 seconds instead of 5 minutes
We built RektRadar to run all 9 signals automatically. You paste a contract address; it returns a 0-100 risk score plus the list of flags that fired. Free, no signup, no card. The scanner uses a forked-mainnet simulation for honeypot detection (#1-#3), parses verified source for #5-#7, queries our on-chain index for #4 and #8, and runs graph proximity against our cluster database for #9.
If the answer is “the contract is unverified, the deployer is new, and our simulation says sell fails”, the scanner will tell you that in under ten seconds. That is the entirety of the value proposition: same signals you would check manually, faster and with the deployer graph that you cannot really build at home.
The two things that are NOT on this list and why
People often expect “audit status” and “team KYC” to be reliable signals. They are not, for our purposes.
- CertiK / Hacken audits. Useful in the abstract, but scam tokens routinely claim audits they don’t have, and the actual scam vector is usually a function the auditor never reviewed (a backdoor added after the audit, a pause function the audit considered standard). Audit badges show up roughly equally on real and fake projects in our dataset.
- Doxxed teams. Most scams have a fake doxx - stock photos, AI-generated LinkedIn profiles, paid actors. On-chain signals are unforgeable in a way that “the team is doxxed” is not. We do not use team identity as a feature in the scoring at all.
The 9 signals above are the ones that are both predictive and hard to fake without making the scam itself fail.
Try the free scan - no signup, no card if you want to skip the manual five minutes. Or skim the list of currently-flagged scam tickers to see what these signals look like in the wild - every page there is a real token that tripped at least three of them in the last 30 days.