Rug pulls rarely look evil at first glance. Most start with a decent website, a hyped name, and a chart that ticks up just enough to lure entries. What separates a veteran from a victim is the muscle memory of checking on-chain facts before clicking buy. Liquidity, ownership, and timers tell most of the story if you know where to look.
This guide walks through what I actually do when I triage a token. I will reference the tools I use daily, explain the contract switches that hide honeypots, and show you how scammers exploit DEX mechanics. Keep it practical, keep it fast.
Liquidity is the bloodstream
On AMMs like Uniswap and PancakeSwap, your ability to sell depends on the liquidity pool. If the pool is shallow or controlled by the deployer, your exit can vanish in a single transaction.
Start with the pair on DexScreener or the DEX info page. Confirm which pool you are trading against. Scammers love to seed a tiny legit pool while routing trading through a different pair they control. On Etherscan or BscScan, open the pair contract, then the LP token, and inspect holders. If the largest LP holder is the deployer or a fresh wallet, you already have your answer.
Lockers are helpful, not perfect. Teams often lock LP tokens using services or burn them to the zero address. Verify the lock on-chain, do not trust screenshots. Actual LP tokens should sit in a recognizable locker contract, not in a random wallet. If the LP is burned, confirm the burn address actually holds the LP token and the supply matches the pool. I have seen fake burns where the team minted a parallel LP token and burned the wrong one.
Migration and router permissions matter. Some tokens include a migration function that lets the owner yank liquidity to a new pair. Scan the token ABI for anything named migrate, setRouter, setPair, or updatePair. A stealthy variant is a transfer tax that spikes only on sells, making the token effectively unsellable once the dev flips a switch.
Low liquidity cuts both ways. A small pool can be normal at launch, but tiny liquidity plus high marketing wallet fees plus a dev-controlled LP is a blow-off top waiting to happen. If you see 90 percent taxes in the first hour, honeypot scam that is not anti-bot, it is extraction.
Ownership and privileged switches
Most ERC-20 and BEP-20 tokens use Ownable or AccessControl. That means a single owner wallet or a set of privileged roles can call functions like setFeeTx, blacklist, or setMaxTxAmount. Those switches make or break safety.
Renouncing ownership helps, but it is not a silver bullet. I have audited contracts where renounceOwnership was cosmetic while a proxy admin still controlled logic. If the token is behind a proxy, the admin can upgrade code even if the token contract shows renounced. On Etherscan, look for a Proxy pattern badge or the implementation field. On BscScan, proxy detection is less consistent, so check for delegatecall usage and storage slots that hint at EIP-1967.
Read the write functions. Red flags include:
- setFeeTx or setTax with unbounded values. blacklist or excludeFromReward that can permanently block selling. setSwapEnabled and setSwapBack that lets the dev throttle the swap router behavior. setMaxTxAmount or setMaxWallet without sane minimums. enableTrading or setTrading that gates all transfers until the owner flips it.
Transfer hooks matter. Any of _beforeTokenTransfer, _transfer, or transferFrom can inject conditions. A honeypot often allows buys but reverts sells with a sneaky require that triggers only when msg.sender is the pair or when the path includes WETH or WBNB. The revert message can be blank or something like TransferHelper: TRANSFER FROMFAILED. Both are common in honeypot crypto traps.
Timers, cooldowns, and fake antibot logic
Launch code often includes tradingEnabled flags, cooldown timers, and anti-sniper rules. These can be useful at launch to stop MEV bots, but they also serve as a perfect rug toggle.
Look for:
- tradingEnabled set to false by default, with onlyOwner enabling later. If liquidity is added before enabling trading, insiders can pre-seed positions. Cooldown windows that reset on each transfer, causing endless sell lockouts for regular wallets. A maxSell or maxTx that is so low you cannot exit meaningfully. If you can only sell 0.05 percent per transaction with a 30 second cooldown, you will be donating slippage to the pool. Dynamic tax ramps. Contracts that set a low buy tax and a spiky sell tax later, sometimes bound to block numbers, are textbook honeypot token detection cases.
Some teams brand these as safeties. Judge the code, not the label.
A quick triage that saves hours
Use this lightweight sweep before you touch a new token.
- Check the token on Etherscan or BscScan, verify source code and compiler match, and scan read/write functions for fee and blacklist mechanics. On DexScreener, confirm the active pair, liquidity depth, and age of the pool. Match LP supply to the pair and verify any LP lock on-chain. Run a honeypot token checker you trust, then manually simulate a sell on a test wallet with a tiny amount. Do not rely on one safe token scanner alone. Review top holders on the token and LP. Look for fresh wallets seeded by the deployer, airdrop traps, or a dev wallet with a huge unlocked allocation. Search X for the token address. Community sleuths frequently surface hazards faster than dashboards, and firms like PeckShield and CertiK sometimes flag live threats.
Honeypots: when you can buy but cannot sell
A classic honeypot makes buys pass and sells fail. The code path usually keys on the pair address. For example, _transfer checks if recipient is pair, then applies a sellFee that can be set to 100 percent, or it simply reverts. Some use per-wallet mappings to whitelist only the dev. Others wrap the revert in tricky math, like division by a variable set to zero post-launch.
Tests beat marketing. If your bsc honeypot check or an Ethereum honeypot scanner says green but you still see suspicious code, send a dust buy and try a sell with minimum tokens. Confirm gas does not explode due to a loop over a whale list. token safety check Hiding a revert behind gas griefing is another pattern I see.
Router-check gimmicks also show up. Contracts sometimes hardcode an expected router and break sells routed through other aggregators. On BSC, watch for PancakeRouter only logic. On Ethereum, watch for UniswapV2 vs V3 confusion used to trap sellers during cross-router arbitrage.
If you get a revert, read the error on Etherscan’s write proxy or your wallet debug logs. If it is TransferHelper: TRANSFER FROMFAILED, go straight to the token’s _transfer code and search for require conditions on pair or on balance after fees.
Fees, reflections, and liquidity math that bites
Reflections and swap-back mechanics can create sell cliffs. Tokens that accumulate fees in the contract, then sell to fund a marketing wallet, can dump right before you. That is not necessarily a scam, but when combined with thin liquidity, it feels like a rug.
AMMs price via x * y = k. If the pool holds 10 ETH and 100,000 tokens, a single 5 ETH sell will nuke price. When you also pay a 10 to 20 percent sell tax routed through swapBack, you are compounding impact. Many investors misread this as a rug when it is tax plus shallow pool. Still, teams that plan sustainability do not launch with 3 ETH of liquidity and a 25 percent sell tax.
Ownership “renounced”, proxies alive
A frequent trap: the owner calls renounceOwnership, Twitter cheers, then the proxy admin upgrades the implementation. Etherscan labels proxies on most major networks. Always open the proxy’s admin and implementation. If admin is a wallet, not a timelock or a multisig, trust falls to zero.
Even without a proxy, some deployers hide authority in other modules. A separate tax controller contract can be owned while the token shows renounced. If you find external calls like IFeeController.getFee, inspect that controller too.
Blacklists, trading gates, and soft rugs
Blacklist functions can freeze selling by targeting the largest holders. I have seen “anti-whale” labels that map to a pure blacklist. Another softer rug: owner sets swap thresholds to block swapBack so marketing fees never convert, then later flips taxes to drain buyers at peak hype.
Cooldown and max wallet combined with aggressive taxes can create what traders call a soft honeypot. Technically you can sell, practically you get sandpapered by limits and slippage.
Tools I rely on when speed matters
Explorers beat dashboards. Etherscan and BscScan let you read code, check holder distributions, and simulate transactions. Block explorer “Read Contract” and “Write Contract” tabs are the fastest sanity checks available. On BSC, code verification quality varies, so fall back to bytecode diffs and proxies if the source is missing.
DexScreener is my default for pair discovery and live liquidity. I also cross check with the DEX’s own info page. CoinGecko listings are not an endorsement, and I treat them as a directory, not a safety badge. For audits, firms like PeckShield, CertiK, Hacken, and Consensys publish research and incident analyses that sharpen your pattern recognition. I also keep an eye on on-chain sleuths on X. They routinely flag honeypot crypto contracts and live rugs before dashboards catch up.
Honeypot token detection tools are useful, not perfect. Use a honeypot token checker that shows the method path and fee assumptions. If a safe token scanner ignores custom routers or per-block fees, it can miss sell restrictions. Your own dust trade is the final arbiter.
What to read in the code, fast
You do not need to be a dev to spot danger in a token contract. Search for:
- setFeeTx, setTax, or updateFee with no upper bound or with separate buy and sell paths that can diverge wildly. blacklist or prohibit, plus any isBlacklisted mapping with onlyOwner access. tradingEnabled or setTrading plus anything that sets launchBlock or adds whitelist addresses. transferFrom and _transfer branches that treat when sender is pair or when recipient is pair differently. Mint or burn functions callable by owner, and any external call to a fee controller contract.
Check decimals and totalSupply sanity. A 9 decimal token with a 1e18 style math bug can behave erratically. Also track routers or pairs hardcoded in storage. If the token references the router directly, a change in router address can trap liquidity.
Fixable warnings vs fatal red flags
When I say pass or proceed, I separate solvable risks from dealbreakers.
- Fixable: LP not locked yet at launch but locker transaction is queued and visible on-chain. Fixable: High taxes for first few minutes with a documented schedule and hardcoded caps. Fixable: tradingEnabled gate with a known block timestamp and a public multisig owner. Fatal: Owner or proxy admin can set fees to 100 percent or blacklist arbitrary addresses. Fatal: LP tokens sit in a dev wallet or a non-timelocked EOA with no plan to lock.
BSC specifics and chain habits
On BSC, memecoins with reflections and owner-controlled taxes are common. Builders often fork older SafeMoon style contracts. That means blacklist, fee toggles, and anti-bot code are everywhere. Your bsc honeypot check should include a manual sell simulation because many scanners still misread reflection math.
Ethereum has more proxy usage. If the project uses an upgradeable ERC-20 via OpenZeppelin, the proxy admin becomes your primary risk check. I have also seen migration contracts that quietly siphon balances via transferFrom using perpetual allowances granted at launch. Always check allowances granted to routers or manager contracts.
When to walk away
If you see a fresh deploy, LP added by the deployer, no lock, and a fee controller held by a single EOA, you do not need another signal. If the team cannot explain why they need blacklist in a fair launch, you are the product. If their “audit” is a PDF with no firm name, no scope, and no commit hash, it is wallpaper. Real audits by Consensys Diligence, PeckShield, Hacken, or CertiK include findings, severities, and versions. Even then, audits reduce risk, they do not erase it.
Rug pulls thrive on impatience. You will miss a few rockets by insisting on checks. You will also keep your stack. If nothing else, remember this: liquidity tells you if you can exit, ownership tells you who can change the rules, and timers tell you when they plan to. Run your own etherscan contract check, trust but verify with multiple tools, and treat every unaudited token like it is trying to take your lunch until it proves otherwise.