We score every new ERC-20 contract that lands on Ethereum mainnet. Across all 78,372 tokens we have analyzed to date, the data tells a story we did not expect: scammers have converged on one single attack pattern, and it’s responsible for 86% of every confirmed honeypot we’ve ever scored.
In the last 30 days alone, that share rose to 92%. The Sell Wall Honeypot is no longer a technique - it’s the standard.
The numbers
| Metric | All-time | Last 30 days |
|---|---|---|
| Tokens analyzed | 78,372 | 23,314 |
| High-risk (score ≥ 70) | 36,119 (46%) | 12,979 (56%) |
| Confirmed scams (score ≥ 90) | 1,078 | 812 |
Confirmed honeypots (honeypot flag) | 11,078 | 5,462 |
Two things jump out. First, 46% of every ERC-20 we see is a scam - and that ratio climbs to 56% on the last 30 days. Second, 75% of all confirmed (score ≥ 90) scams in our history were deployed in the last 30 days. Scammers aren’t just present on Ethereum. They’re accelerating.
The pattern: Sell Wall Honeypot
Of the 1,078 confirmed scams we’ve ever scored, the same combination of risk flags shows up over and over.
| Flag signature | All-time | % of confirmed | Last 30d | % of recent confirmed |
|---|---|---|---|---|
honeypot + sell_failed | 927 | 86% | 748 | 92% |
honeypot + buy_failed | 827 | 77% | 657 | 81% |
buy_failed + sell_failed | 827 | 77% | 657 | 81% |
honeypot + hidden_owner | 623 | 58% | 464 | 57% |
The dominant signature is honeypot + sell_failed: a contract where a buyer’s transferFrom succeeds against the DEX pair, but the same call reverts the moment the buyer tries to sell back. Money flows in. It does not come out.
How it works on-chain
The honeypot is implemented inside the ERC-20 _transfer function. A typical sketch:
function _transfer(address from, address to, uint256 amount) internal override {
// Buyer side: incoming transfer from the Uniswap pair - allowed.
if (from == uniswapV2Pair) {
super._transfer(from, to, amount);
return;
}
// Seller side: transfer back TO the pair - blocked silently or with revert.
if (to == uniswapV2Pair) {
require(blacklist[from] == false, "ERC20: insufficient balance");
// The require message is intentionally misleading.
}
super._transfer(from, to, amount);
}The same wallet adds every non-deployer address to blacklist after the buy event, so require(blacklist[from] == false) fails on every sell attempt. The error message mimics a benign “insufficient balance” so block explorers and wallet UIs don’t flag it as malicious.
There are variations - pausable toggled by the owner, approve_with_transfer hooks that steal allowances, hidden_owner proxies that swap the implementation post-deploy - but the core is always the same: buy() yes, sell() no.
Why it works
The pattern survives because three things have to fail at once for a buyer to escape:
- Pre-buy simulation: most wallets and aggregators don’t eth_call a sell against the contract before pushing the buy. Even MetaMask only simulates the transaction it’s about to broadcast, not the reverse.
- Etherscan verification: 56% of these contracts are deployed unverified. The bytecode reveals the trap, but a typical retail buyer never decompiles bytecode.
- Token metadata mimicry: 30% of confirmed scams on Ethereum impersonate a known brand. USDT has 245 fakes. USDC has 237. YSUBA has 137. TRUMP has 41. PEPE has 41. XRP has 38.
A buyer searching for “USDC on Ethereum” finds dozens of contracts with the right ticker, and the wrong contract address.
How RektRadar detects this
We run a eth_call simulation against every fresh deployment, in both directions:
- Simulate a buy from a fresh wallet → if it reverts → score 100, flag
buy_failed. - Simulate the corresponding sell back to the pair → if it reverts → score 100, flag
sell_failed.
Both checks together = the honeypot flag fires. The combination ships within seconds of contract creation, before the deployer has time to add liquidity or seed a paid promotion.
The simulator runs locally against our own Ethereum node, so it sees every deployment within one block (~12 seconds on mainnet). The full list of every honeypot we’ve ever caught is queryable on app.rektradar.io.
Top recent brand-jacks (last 30 days)
If you want to see the pattern in the wild, here are the names that recur the most in the last 30 days:
| Ticker | Fakes in 30d | Top RektRadar score | Notes |
|---|---|---|---|
| YSUBA | 137 | 80 | Largest active factory we track |
| ASTEROID | 44 | 100 | Brand-jack of a 2024 meme |
| TRUMP | 35 | 100 | Politically-loaded ticker, recurring wave |
| SCAM | 34 | 100 | Yes, “SCAM” is literally a brand-jacked ticker |
| BTC | 32 | 100 | Fake Bitcoin tokens on Ethereum |
| ELON | 31 | 80 | Musk-association wave |
| LIFE / AGI / AI / NICE / GOBLIN | 20-29 each | 100 | AI-trend hype tickers |
| PEPE | 24 | 80 | Meme bluechip with permanent fakes |
| USDT | 19 | 80 | Sharp drop from 245 all-time - scammers rotated away |
The rotation matters. USDT had 245 fakes all-time but only 19 in the last 30 days. Scammers chase whatever ticker is trending, ship 20-40 copies of the same Sell Wall Honeypot bytecode under each name, then move on.
What you can do
If you’re trading on Ethereum:
- Don’t search by ticker. Search by contract address. The legitimate USDT contract address is
0xdAC17F958D2ee523a2206206994597C13D831ec7. Anything else is a fake. - Run a sell simulation before you buy. RektRadar does this automatically - paste an address at app.rektradar.io and the verdict appears in ~3 seconds, with the simulation flags listed.
- Watch for the
honeypot + sell_failedcombo. If a token shows both, the sell path is broken on-chain. Walk away.
If you’re building tooling:
- The bytecode signatures behind the Sell Wall Honeypot are public on Etherscan (the few that get verified). We index them in the bytecode similarity database powering
/api/score. - The deployer-graph overlap is enormous: 5 deployers were responsible for 16,830 contracts in the largest cluster we visualize on the home page demo. Mass-deployer is a strong secondary signal.
Methodology footnote
All numbers in this article come from the RektRadar production database as of 2026-05-14. We score every ERC-20 contract creation event on Ethereum mainnet via factory-watcher and contract-analyzer (our open-source pipeline). A score ≥ 70 marks “high-risk”, and ≥ 90 marks “confirmed scam” - defined as having at least one of honeypot, sell_failed, buy_failed, hidden_owner or approve_with_transfer actively firing on an eth_call simulation.
The dataset is biased toward Ethereum mainnet (we don’t yet cover L2s or Solana) and toward contracts with at least one liquidity pool on Uniswap V2/V3 - pure rug deployments without a pool never get a score because there’s nothing to simulate a buy against.
Code, schema and the analysis queries are reproducible from the mik3fly-lab repos.