Honeypots and stealth rugs did not disappear after 2021, they just got smarter. Scammers learned to hide sell locks behind transfer hooks, proxy beacons, and selective whitelists. The good news, our toolbox to spot them also leveled up. If you know where to click and what to read, you can avoid most traps long before you hit swap.
Below is the practical stack I use when people DM me the dreaded question: can you check if this token is scam? It mixes automated scanners, block explorers, and a few habits that catch sell restrictions in minutes.
Automated scanners run static and dynamic checks. Static checks look for red flags in the source code, like a function named setFeeTx https://honeypot-token-checker.github.io/ that lets the owner jack taxes to 99%. Dynamic checks try a simulated buy and sell against a live DEX, then report if the sell reverts. Tools label this as honeypot token detection.
That does not mean a clean score equals safety. Scammers love conditional logic. A contract can allow sells for the scanner’s address range, then block normal wallets. It can whitelist the first block after launch, then switch to blacklist mode. Some checks run against a single router, while the trap lives on another pair. Treat scanners as triage, not gospel.
For a fast read on a token’s hygiene, I triangulate across a few reliable tools and explorers. They each bring a different lens.
On EVM chains, Etherscan and BscScan are still the backbone. Verified source code, read and write panels, Proxy and Token Tracker tabs, and owner history are pure signal. The “Contract” tab shows if it is upgradeable, who can upgrade, and which functions are externally callable. A quick scroll often reveals whether renounceOwnership was actually called or if ownership sits with a fresh EOA that just funded itself from a mixer.
For market context, DexScreener surfaces the real pair, liquidity depth, FDV math, and trade flow. You can quickly see if there are multiple pairs, whether the canonical pool has meaningful liquidity, and if someone is wash trading low volume to bait entries. I also glance at CoinGecko for warning labels. They flag suspicious tax tokens and clones faster than most CEX listings.
On pure “honeypot crypto” checks, I still see value in Honeypot.is for buy and sell simulations, especially on BSC where traps are common. StaySafu and Token Sniffer provide quick code heuristics for blacklist logic, trading toggles, and mint authority. GoPlus Security APIs feed many wallets now, and their token risk summary is handy for live “can transfer?” checks. De.Fi Scanner aggregates vulnerability signatures, including permissioned minting and wallet blacklist patterns. For older memecoin terrain on BSC and Fantom, RugDoc’s writeups and KYC notes can highlight known deployers and factory contracts that have a history.
On the professional side, security firms like PeckShield, CertiK, Hacken, and Consensys Diligence publish frequent scam alerts and post mortems. If any of them have flagged the deployer or router, I stop there. On-chain sleuths on X often catch live honeypots within minutes of launch, especially when the token name riffs on a current meme. Those threads, while noisy, have saved many wallets.
A typical honeypot token checker simulates a small buy against the token’s main liquidity pair, then immediately simulates a sell. If the sell reverts, reverts with custom errors, or routes 0 tokens out after transfer fees, it flags “token cannot sell”. Good scanners attempt different paths, like direct swapExactTokensForETH on Router v2, or routerless transfers followed by a sell, since some contracts trap on the router hook.
Under the hood, traps usually sit in these areas:
setFeeTx or setSellTax that the owner can raise close to 100%. The sell technically succeeds, but the user receives near zero. _transfer that blocks specific addresses on sell. Some contracts enable this only after a delay. tradingEnabled or launchBlock that reverts sells before a set time. Scammers can toggle it back on to trick scanners. maxTxAmount, maxWallet, or similar. If sell size exceeds the cap, the revert looks like a honeypot. msg.sender equals a specific router or pair, or if the recipient is whitelisted.A sound scanner tries to buy and sell in small chunks, through the canonical pair, with adequate gas, while avoiding paths that bypass the trap logic. Even then, selective whitelisting can fool it.

If you play on BSC, expect more fee-on-transfer and stealth-tax tricks. I watch for pancakeSwapV2Router and pancakeSwapV2Pair addresses hardcoded in the contract. Many honeypots key off sender == pair checks to treat buys and sells differently. An owner-only setSwapEnabled or setMarketingWallet can hide a path that drains on sell.
Also note that BSC has a jungle of routers. If the token creates a pair on a fringe router, the main router path might work for a scanner but fail in practice. When running a bsc honeypot check, make sure you identify the active pair and router on DexScreener, then validate against that exact route.
Here is the lightweight workflow I run on Etherscan or BscScan before touching a new token.
owner, getOwner, owner() on OpenZeppelin Ownable, or role admins on AccessControl. Then check if renounceOwnership or transferOwnership was called, and to whom. transfer, _transfer, transferFrom, beforeTokenTransfer, afterTokenTransfer, and any custom takeFee blocks. Note any blacklist mappings, tradingEnabled, launchBlock, max wallet or max tx variables. setFeeTx, setTax, enableTrading, setMaxTxAmount, excludeFromFees, or an unrestricted mint is a red flag if ownership is not burned or held by a reputable multisig.This takes three to five minutes and filters out the majority of traps.
Honeypot checks are binary, but liquidity is narrative. On DexScreener, find the top liquidity pair and verify it is the canonical pool. If a different pair has real depth, the launch might be legit. If all volume routes through a thin pool with sudden spikes, that is often bot orchestration.
Look for liquidity locks. Teams that actually plan to build usually lock LP tokens on services like Team.Finance or Unicrypt, or they form LP in a treasury multisig with a visible time lock. If LP is sitting in the deployer wallet, any honeypot scam talk of safety is fluff. You can verify LP token holders on the pair contract’s Token Tracker page on Etherscan or BscScan.
Tax tokens are not automatically scams, but high, mutable taxes are. A 2 to 5 percent buy and sell tax can fund operations if coded transparently. A setTax hook that the owner can change without limits is a honeypot waiting for a flip. Many “token sell restriction” complaints come from buys routed through a pair with stale reserves, then sells that hit an anti-bot window. Always test a tiny sell after a tiny buy to confirm path symmetry.
If I am unsure, I dry run the transaction. Tenderly’s transaction simulator lets you simulate a buy and sell directly from your wallet state without sending on-chain. You can also use callStatic in a script, or run a local fork and hit router.swapExactTokensForETHSupportingFeeOnTransferTokens to see if the sell path transfers out nonzero.
Watch for gas griefing. Some honeypots are not reverts, they burn absurd gas in beforeTokenTransfer for sells, making them economically unsellable. If your simulation shows 2 to 3 times the expected gas on sell, pause.
Security firms like PeckShield and CertiK often post live alerts about new honeypot tokens, frequently with deployer address clusters. I scan X for the ticker and contract prefix. Serious red flags appear quickly as wallets report “token cannot sell” or “stuck on approve”. CoinGecko also applies tags like “Suspicious” or “High Tax” that correlate well with problem code.
Community sleuths often spot copied bytecode from a known scam. If the bytecode hash matches a previously rugged contract, no tool score will save you.
Upgradeability is the big one. A token can verify a benign implementation, pass every safe token scanner, then the owner upgrades to a malicious implementation. On Etherscan, the Proxy tab shows the current implementation and the admin. If a single EOA controls it, nothing is locked.
Another is router selectivity. Some code allows sells only through a specific router, and scanners often test a mainstream route. If you buy through Router A and can only sell through Router B, you are effectively stuck unless you arcane route hop, which most users will not.
Whitelist based traps still appear. The owner can whitelist known scanner addresses or the first block, so simulations pass, then real wallets get blacklisted after a time window. Also watch for hidden fee managers via roles. An AccessControl role like FEE_MANAGER_ROLE held by an unseen address can bypass ownership renounce optics.
Finally, mint functions. If mint is callable by the owner or another role, supply can balloon after hype builds. It is not a honeypot, but it is a different kind of loss.
Scanners reduce risk, they do not erase it. A careful etherscan contract check and a measured, test sized trade will save you more often than another fancy dashboard. If a contract gives the owner the ability to change taxes, block addresses, mint more tokens, or toggle trading, assume those powers will be used. When something looks too perfect, it usually hides a function you did not scroll far enough to see.
Use tools to catch the obvious, then rely on habits and skepticism to catch the rest. That mix has kept my wallets clean through more token seasons than I care to admit. Stay curious, keep transactions small until you are sure, and let the scammers harvest someone else’s impatience.