Scams on BSC and Ethereum rarely look like scams at first. They look like harmless tokens on PancakeSwap or Uniswap, sitting next to real projects. The catch is in the contract, and the contract decides if you can ever sell.
I audit and triage these contracts daily. Honeypots are predictable once you know the tricks. What follows is a practical walkthrough of how to check if a token is a scam, what code patterns drive token cannot sell behavior, and how to use explorers and DEX tools to protect yourself.
What a honeypot really is
A honeypot isn’t just “high tax.” It is a token that lets you buy, then blocks or cripples selling. You might see transactions fail on sell, or go through with a 90 percent tax, or sell only for whitelisted wallets.
On BSC, honeypots are everywhere because fees are cheap and deployers can rinse and repeat. Ethereum has them too, just with higher gas overhead. Same playbook.
The most common patterns I see:
- Blacklist or whitelist sells using internal mappings to only let “privileged” addresses trade. Tax toggles that hike sale taxes to extreme levels once liquidity builds. Transfer hooks that revert or reduce amountOut through hidden logic. Trading gates that allow buys but block sells until the deployer flips a flag you will never see flipped.
Quick translation of the smart contract pieces
Most scammy ERC‑20 or BEP‑20 tokens override transfer and transferFrom. That is where all the logic hides. If you open the code on Etherscan or BscScan and only see a proxy pointing to an implementation, you need to read the implementation. The trap is never in the interface.
Watch for:
- owner or onlyOwner functions that change fees like setFeeTx, setBuyTax, setSellTax, setMaxTxAmount, setMaxWallet. Blacklist functions like setBlacklist, addToBlacklist, excludeFromFees, or a custom mapping check inside _transfer. Trading toggles such as tradingEnabled, openTrading, enableTrading. If these guard sells separately from buys, be careful. Custom routers and pairs. If the code uses a nonstandard router, swap path, or pair creation logic, test swaps carefully.
A honeypot can arrive in a few lines inside _transfer. Example patterns include a require that blocks sells to a pair if the sender is not whitelisted, or a fee computation that returns the full amount to the fee wallet on sell. You will also see logic that only activates when to == pair or when a sell is detected by reading from AutomatedMarketMakerPairs.
The tax trap, not always obvious
Taxes are not evil by default. Plenty of legitimate tokens use small buy and sell fees, usually 0.5 to 5 percent, for treasury or LP management. The red flags are mutable fees with no sane caps, especially when the owner can change them at any time.
If you see:
- setSellTax(uint256) with no maximum or with a max of 100, your sell can be taxed into oblivion. Fee exemptions granted to specific wallets through isExcludedFromFee, which can route around taxes only for insiders. A fee target wallet that is unbounded and owner controlled.
Some contracts disguise the tax hike. They ship with 0 percent, lure buyers, then raise it the moment liquidity thickens. On-chain sleuths on X often post charts from DexScreener right when this happens. You will see candles spike up, then every sell revert or drain.
Blacklists, max wallets, and other restrictions
Blacklists can be explicit or obfuscated. The obvious ones have blacklist[address] = true toggled by the owner. The sneaky ones build a blacklist dynamically when you buy from the pair, or they flag a wallet if it sells within the same block. Look for block.number checks around _transfer.
Max wallet and max transaction settings can also trap you. If maxTxAmount is set too low, you may not be able to sell your full position at once. Fragmented sells cost extra gas and slip into even higher fees if the sell tax scales with amount.
A tough corner case is when the contract blocks sells for the first N blocks after trading opens. You see buys go through, but every attempt to sell in the opening window reverts. launchBlock, initialBlock, or sniperProtection routines usually control this.
The liquidity piece that everyone underestimates
Liquidity is the other half of the scam. Tokens don’t need to only block sales if they can make sells worthless.
If the deployer seeds a tiny pool on PancakeSwap or Uniswap, any decent buy will spike the price. Then the deployer can either block your sells or yank liquidity. Start by checking the pair on DexScreener and the LP token holder on Etherscan or BscScan.
If liquidity is locked through services like Team Finance or Unicrypt, verify the lock. LP tokens should sit in a lock contract, not the deployer wallet. If you see the deployer holding most LP tokens, and the token supply is concentrated in the same wallet, you are staring at a rug setup.
How I do a fast honeypot token detection pass
I have a routine that takes under five minutes per token. It catches most traps before I ever hit swap. It doubles as a safe token scanner workflow for retail:
- Open the token on Etherscan or BscScan. Verify the contract is published. If it is a proxy, open the implementation and read _transfer. Search the code for “owner”, “fee”, “tax”, “blacklist”, “trading”, “maxTx”, “maxWallet”, “excludeFromFee”. Check write functions on the Read/Write Contract tab. See if the owner can set sell tax near 100, blacklist wallets, or change router/pair. On the pair page, review holders. Confirm LP lock. If the top holder is the deployer or a fresh wallet, walk away. Simulate a tiny trade on a fresh wallet with high slippage tolerance, then try a sell for a tiny amount. Watch the error messages and gas usage.
That last step matters. Real honeypots often revert with vague strings or no error data. If the token requires slippage at 49 percent just to swap, you are already paying the tax.
Reading the sell path in code
Most of the traps hit when to equals the pair address, which signals a sell. Typical honeypot code in _transfer might do:
- A conditional like if (to == pair && !isExcludedFromFee[from]) fee = sellTax; followed by fee math that can be set to absurd levels. A check like require(!blacklist[from]) that the owner can flip at will. A whitelist pattern: only whitelisted addresses can sell, gated by isWhitelisted[from].
The slicker implementations calculate taxes based on time since buy, block number, or wallet flags set in transferFrom. They also use storage variables with generic names, like _v1, _state, _rOwned tricks, to hide intent. If the code is minified or full of meaningless identifiers, it is not an automatic scam, but you should assume the power lies with the owner until proven otherwise.
Etherscan and BscScan tricks that save time
Etherscan and BscScan are your best friends. The basics are obvious, but a few fast checks separate safe from sketchy.
Click “Read Contract.” See the value of owner or getOwner. If renounceOwnership was called, confirm it. Many contracts “renounce” then keep upgrade authority using a proxy’s admin. If you see a proxy with an EIP‑1967 admin, check the Proxy tab. If the admin is still a wallet, the owner can upgrade to malicious logic at any time.
Open “Write Contract” and hit estimateGas for setters like setSellTax or setBlacklist to see if they are enabled. Sometimes devs leave them public by mistake. Real projects audited by firms like CertiK, PeckShield, Hacken, or Consensys Diligence usually have clear bounds and event logs on parameter changes. They also cap taxes and lock sensitive functions after deployment. Not always, but often.
On the pair page, click “Holders.” Expand the LP token whale. If it is a lock contract, you will usually see a recognizable name. If it is a regular wallet with no history, consider that liquidity removable. Cross check volume and price action on DexScreener. Thin pools with sharp wicks and zero net outflow on sells often signal restricted selling.
What “renouncing” does not fix
Scammers love to renounce ownership for optics while hiding control elsewhere. Common tricks:
- They renounce the token contract but keep control over the router or a fee controller contract. They use an upgradeable proxy. Ownership of the implementation is irrelevant if they keep proxy admin. They deploy a fee handler contract that the token calls during transfers. Ownership of that handler lets them change behavior post “renounce.”
Check for external calls inside _transfer such as _marketingWallet.callvalue: ... or IFeeManager.process(...). Follow the address to its contract. Read that code too.
When the sell fails only on DEX
You might test a transfer from wallet to wallet and it works. Then a DEX sell fails. That split is intentional. Contracts can treat sells differently by keying off the pair address.
Look for a set of addresses stored in AutomatedMarketMakerPairs. Many forks of Uniswap token templates maintain a mapping for AMM pairs. The code can use if (to == pair || toAMM[to]) to trigger sell logic only on AMM transactions. Wallet to wallet transfers remain fine, which helps scammers argue “the token is not a honeypot” to inexperienced buyers.
Taxes that hide in slippage
Slippage settings on the DEX UI are a social engineering tool. Telegram admins will say “set slippage to 20” to bypass “anti bot” measures. What is really happening is you are accepting a 20 percent tax. Some contracts even detect your slippage and raise the fee to match it.
A helpful test is to lower slippage step by step and compare the minimum received values on the router. If the delta is not linear or the min received nukes your bag, you are looking at fee logic that changes mid swap, often using swapExactTokensForETHSupportingFeeOnTransferTokens. The “supporting fee on transfer tokens” router function is legitimate, but it also hides the real transfer amount.
The role of the community and audit signals
honeypot-token-checker.github.ioI always watch on-chain sleuths and researchers on X. They catch live attacks and honeypots faster than any one person can. When PeckShield warns on a token or rug pattern, it is usually backed by real on-chain traces. Consensys Diligence threads often break down ERC‑20 antipatterns that show up in these traps. None of that replaces your own checks, but it sharpens your instincts.
If a project touts an audit, read it. Reputable firms name specific risks, list tax caps, and describe ownership posture. A two page PDF without function names or commit hashes is theater.
A minimal, practical honeypot token checker
If you only do two things before buying:
- Read the contract on Etherscan or BscScan long enough to find _transfer and any setSellTax or blacklist functions. If fees are unbounded or sells are gated, skip. Confirm LP tokens are locked with a credible locker. If unlocked or sitting with the deployer, skip.
That alone filters most landmines.
Edge cases that fool scanners
Automated honeypot token checker tools are helpful, but they miss edge cases:
- Fee logic that activates only after liquidity hits a threshold or after a time delay. Blacklists that populate on first sell, not first buy. Proxies that swap to a new implementation after a clean launch window. Tokens that allow small sells but block large ones using maxTxAmount to throttle exits.
If a token looks clean but the community insists they had sell issues, believe the crowd and dig deeper. Error logs on failed transactions and the code’s storage diffs around owner interactions tell the story.
Final notes on judgment
Legit teams give up power. They cap taxes at single digits, verify contracts, avoid strange routers, and lock liquidity. They announce parameter changes and push them on-chain with events. They don’t ask for 20 percent slippage.
If you are unsure, put the contract through your own crypto scam detection flow, ask around, and check recent trades on DexScreener. A healthy chart shows both buys and sells clearing at reasonable gas usage. If sells vanish or revert, or every sell prints a massive red fee to a single wallet, you have your answer.
A few minutes on Etherscan or BscScan beats days of arguing in Telegram. The contract tells the truth.