Scammer Tactics in 2026
Seven attack patterns currently active on Ethereum. Each section maps the playbook to the on-chain detection signal and the practical counter-move. Drawn from a corpus of 36 263 confirmed scams, 156 bytecode clusters, and 200+ identified mass-funder wallets.
The scoring engine runs each tactic's detection signal automatically. 10 seconds, free, no signup.
The current playbook
Scam tactics evolve, but slowly. Eight out of ten tokens we flag in any given week fit one of the seven patterns documented below. The remaining two percent are novel attacks that get added to this list as they emerge. Familiarity with the playbook is the highest-ROI defense you can build for free - most retail losses come from not recognizing patterns that are obvious to anyone who's seen them once.
Honeypot
Contract that lets you buy but blocks every sell.
How it works
The single most prolific attack pattern on Uniswap V2 and V3. The contract overrides `transfer()` or `_transfer()` to revert on any address not on a whitelist, with the deployer's address being the only entry. Buys succeed because they originate from the Uniswap router (which is whitelisted by default in some variants); sells fail because the seller becomes the `from` address and the whitelist check trips. Catches retail buyers who never test a sell before piling in.
Detection
Honeypot simulation: simulate a buy then a sell on a forked mainnet. If the sell reverts on a clean buy, you have a honeypot. 100% precision in our 36 263-scam reference set - no false positive by construction.
Counter-move
Always test a 1% sell after buying. If you cannot test, do not buy.
Examples in the wild
- Conditional honeypot: sell succeeds the first time, fails the second
- Gas-price-branched honeypot: works below 30 gwei, fails above
- Time-locked honeypot: works for 10 blocks, then locks
- Address-whitelist honeypot: only specific pre-loaded addresses can sell
Brand-jack
Token uses the name or ticker of a well-known project to attract search traffic.
How it works
The scammer deploys a token called USDC, CLAUDE, KEKIUS or TRUMP. Search ads, Telegram bots and even some legitimate DEX aggregators surface the wrong contract to a search query. Retail clicks the first result, buys, gets honeypotted. Our index currently catalogs 239 fake USDC, 49 fake PEPE, 43 fake TRUMP, 19 fake MUSK, 19 fake MAGA, 6 fake SHIB, 6 fake CLAUDE and 3 fake KEKIUS contracts.
Detection
Name/ticker fuzzy matching against a curated allow-list of legitimate contracts (Circle USDC, the real PEPE community contract, the actual MAGA token where one exists). Combined with deployer age and bytecode signature, brand-jack catches scams that bypass other static checks because the contract code itself can be clean - the trap is at the perception layer.
Counter-move
Always pull the contract address from the project's verified primary source (verified Twitter, official docs). Never trust a Telegram link.
Examples in the wild
- 239 fake USDC on Ethereum mainnet - the real one is at 0xA0b8…eB48
- Fake CLAUDE tokens spiking around every Anthropic announcement
- TRUMP / KEKIUS brand-jacks at Token2049 cycles
Mass deployment (scam factories)
One wallet deploys 10-100 tokens in a week, throws each at the wall, harvests the buyers who stick.
How it works
Industrial-scale scam operation. A deployer wallet - usually freshly funded from a CEX withdrawal or a mass-funder a hop back - deploys 10 to 100 token contracts in rapid succession. Most never get any volume and are abandoned. A few catch a small viral wave; those are the ones to rug. The deployer's only on-chain activity is `CREATE` opcodes - no swaps, no transfers, no NFT mints. Once you find the deployer, every token they've launched is suspect.
Detection
Two on-chain signals stack: (1) deployer wallet has 5+ confirmed scams in its history, (2) one upstream funder is connected to 50+ deployer wallets. Graph databases catch this in milliseconds; manual due diligence misses it because no one walks the graph by hand.
Counter-move
Always click the deployer on Etherscan. If they have 10+ contracts deployed in the last 30 days, exit immediately - odds are stacked against you regardless of any single contract's individual signals.
Examples in the wild
- 1110-vanity factory: 1 110 tokens with vanity addresses ending in 0x...1110, all variants of the same honeypot template
- Moodang factory: bytecode reused across 50+ tokens
- Unicat factory: similar pattern, different template
Bytecode templates
Same contract code redeployed under 1 000+ different ticker names.
How it works
A scammer writes one good honeypot contract, then redeploys it with a different name, ticker and decimals for each victim. The deployed bytecode hash is identical across all instances. Our database currently tracks 156 such templates with 10+ tokens each. The largest template has 4 050 tokens sharing the same bytecode hash - that's 4 050 victims across a single attacker's catalog. Static signature matching catches these on first deploy with 100% precision; the attacker has to write a new contract from scratch to evade.
Detection
Hash the deployed runtime bytecode. Look up the hash in our `bytecode_token_map` table (or compute and search via Dune). If 10+ prior tokens share the hash and most are flagged scams, this is the same template.
Counter-move
Use a scanner with bytecode signature matching enabled. Manual hex inspection works but is impractical at scale.
Examples in the wild
- Top cluster: 4 050 tokens, bytecode 0x6d8b9b72…
- Second cluster: 1 541 tokens
- Third: 1 199 tokens
- 156 clusters total with ≥10 tokens each
Sell wall - fee elevation
Contract starts with low fees, raises sell tax to 99% via an owner-only setter once retail is in.
How it works
Soft-launch variant. The contract deploys with `sellTax` at 5% - looks normal. The owner then calls `setSellTax(99)` once enough volume has accumulated. New sellers receive 1% of what they expect; the deployer wallet keeps the rest. Functionally identical to a honeypot but harder to catch in a static scan because the contract is benign at launch. Static fee scrapers see 5%, give a green light, retail piles in. Then the tax flips.
Detection
Source-code regex: look for owner-callable setters on the tax variable (`setBuyTax`, `setSellTax`, `excludeFromFee`, `setFees`). Combined with `no_renounce_ownership` flag = high probability that the owner is still in position to flip the switch.
Counter-move
Wait 7-14 days after launch before buying. Watch for any tax-mutation events. If the owner has never been renounced AND has tax-setter privileges, treat as conditional honeypot.
Examples in the wild
- sellFee() initially 5%, called with 99 at block N+5 000
- buyFee + sellFee combined exceed 50% - practically unsellable
Fresh deployer funding patterns
Deployer wallet less than 24h old, funded by a small CEX withdrawal, no other history.
How it works
Scaffolding pattern. The scammer creates a fresh wallet, withdraws 0.05-0.5 ETH from Binance/MEXC/KuCoin, deploys the contract, seeds the liquidity pool, and the wallet has no other activity. Three to five wallets repeat this loop in parallel - fresh wallet, single CEX withdrawal, deploy, seed pool, abandon. The funding pattern is invariant: small withdrawal, single tx, no return funds.
Detection
Two-hop graph traversal. From the deployer, walk back to the funding tx. If the funder is (a) a CEX hot wallet OR (b) another freshly funded wallet that itself traces to a CEX, and the chain has no organic activity in between, you have a scaffolding launch.
Counter-move
Click the deployer's first incoming transaction on Etherscan. Walk it back one hop manually. If you see Binance/MEXC/KuCoin and nothing else in the history, treat as scaffolding by default.
Examples in the wild
- 50% of all scams in our 90-day dataset trace to under 200 distinct mass-funder wallets
- Common pattern: 0.1 ETH withdrawal → fresh wallet → deploy + seed pool → abandon
Proxy-upgrade time-bombs
Deployer ships a proxy contract that looks clean today but can be upgraded to a malicious implementation tomorrow.
How it works
Most subtle current playbook. The deployer ships a UUPS or beacon proxy that delegates to a benign implementation contract. The static signals all look fine: clean source, reasonable distribution, locked LP. Weeks or months later, the deployer calls `upgradeTo(maliciousImpl)` and now every `transfer()` reverts or transfers tokens to a drain address. Static analysis cannot see the future implementation; only real-time monitoring of upgrade events catches this in time.
Detection
Combine `proxy_detected` flag with `proxy_admin_detected` (admin role exists and isn't burned). Any proxy with an unrenounced admin role is conditionally safe at best. Real-time monitoring on upgrade events is the only defense once you're holding.
Counter-move
Avoid proxies in the speculative tier. Or accept that your due diligence has a shelf-life and set price alerts to exit on any unusual movement.
Examples in the wild
- UUPS proxy with admin role still on deployer
- Beacon proxy where the implementation can be swapped by the deployer at will
What's missing from this list
Bridge exploits and cross-chain message replay attacks. Those are real but live outside the ERC-20 token layer this site focuses on; safer to read the dedicated bridge incident write-ups.
Wallet drainers and approval-phishing UIs. Those attack the wallet, not the token. If you've signed an unlimited approval to a malicious contract, no token-level scan can save you.
MEV sandwich attacks. Those are predatory but legal, structurally different from scams: you lose to slippage but you can still sell.
Cross-references
- How to check token safety
The 7-step manual flow that catches every tactic above - 20 red flags checklist
Each tactic maps to one or more flags in the catalogue - Why scams keep working
Information asymmetry, scammer iteration loop, distribution gap - Scam factory size mapping
Empirical distribution of scam factory sizes across 156 clusters