The fastest way to avoid honeypots and soft rugs is to stop staring only at the token and start looking at the human, or bot farm, behind it. Tokens come and go. Creator histories stick around. When you combine a quick honeypot token checker with a deep read of the deployer’s past, you move from guesswork to pattern recognition.
This is the workflow I use on EVM chains when I’m screening a new coin on Uniswap, PancakeSwap, or a launchpad. You can copy it, adjust it to your risk tolerance, and you will skip a lot of pain.
Scammers recycle playbooks. Same factory, same bytecode, same “renounced,” same burn address, same tax toggles, just a new ticker and hype. If a deployer address has already rugged three tokens in the past month, the odds you are the exception are microscopic.
A token can fake everything surface level, including “renounceOwnership” and liquidity burns. The creator’s past deployments, internal transfers, and relationships with liquidity pools tell a more honest story. As frequently highlighted by security firms like PeckShield and Consensys Diligence, repeated exploit patterns are rarely one‑offs. That is especially true for honeypot crypto schemes on BSC where fees are cheap and factories are plentiful.
Below is a compact workflow you can run in a few minutes. I still do a tiny test trade after this, but this saves most of the time and money.
That’s your minimum viable defense. If anything feels off, walk away. There are always more charts.
Start with the creator address you pulled from Etherscan or BscScan. If the token was deployed through a launchpad or factory, you may see a factory contract as “creator” and the real actor behind it as the first admin or owner. That is normal. Track both.
Open the creator’s profile. The Contracts tab shows what they have deployed. The Transactions and Internal Txns show money and control flow. A clean creator has a manageable number of deployments, consistent gas profiles, and simple ERC‑20 code from standard libraries. A malicious creator often deploys clusters of near‑identical tokens, funds them from throwaway CEX deposits, and cycles profits through mixers or cross‑chain bridges.
Bytecode similarity helps. Etherscan’s Similar Contracts can reveal that the token matches a known template that previously blocked sells or skimmed fees. If you see 90 percent similarity with multiple rugged tokens, that is not a coincidence. Hacken and CertiK reports often mention these code reuse patterns when they audit clusters, and you will see the same on-chain.
Pay attention to time https://honeypot-token-checker.github.io/ spacing. Serial rugs are often deployed within hours or days of each other, each with a quick pump, no sell liquidity for buyers, then a drain. The creator might then self‑destruct supporting contracts or move admin keys to a new burner. The chain of custody matters more than any single “renounceOwnership” transaction.
Most sell‑blocking tricks happen inside ERC‑20 hooks. The implementation details vary, but the behavior rhymes. You are hunting for adjustable state that treats the DEX pair or buyers differently.
Common red flags in code:
Reading only the function names is not enough. Scan the require conditions around transfer and transferFrom. Some devs place pair checks deep inside, or rely on a modifier that turns into a honeypot switch at block N. Others rig the constructor to set punitive values when liquidity is added.
Not every “token cannot sell” case is a classic revert. There are softer patterns that dupe scanners.
A popular one is raising sell tax from 5 percent to 99 percent right after marketing pushes volume. Buyers can technically sell, but slippage parameters push most wallets to fail. Another is draining liquidity through a swap‑back that trades the treasury token balance into the pool repeatedly. You see price melting, not a revert, and many safe token scanners miss it.
Some contracts gate selling to time windows, or enforce a tiny maxTx on sells that only lets insiders unload. Others pause trading only on sells, then re‑enable it for insider exits. The fee code might look harmless until you trace paths that trigger special flags when the sender is not excluded.
Honeypot token detection sites are useful, but I treat them as a rough filter. I have seen tokens pass these scans, then flip a variable after a block threshold to trap buyers. Always pair scanners with a live micro trade and an Etherscan Read Contract check.

LP handling reveals intent. If LP tokens go to a team wallet, you are betting on trust. If they are burned to 0xdead or locked in a reputable locker like Team Finance or Unicrypt, the risk drops, but it is not zero. I have seen devs lock for 7 days, farm hype, then nuke it on unlock.
Check the LP pair address on Etherscan or BscScan. Click Holders to see where LP tokens live. Open Internal Txns to confirm who added and who can remove liquidity. If the creator is the only actor, they can single‑sided add and later pull in a way that creates the illusion of depth, then yank the bid at once.
On DexScreener, zoom the first 24 hours. Sudden TVL spikes followed by flat or vanishing liquidity often precede a rug. Combine that with the creator history and you get the real picture.
Many scams hide behind proxies. The token contract you see is a TransparentUpgradeableProxy or UUPS proxy. “Owner: 0x0000…dead” on the proxy means little if the implementation contract or the ProxyAdmin still has a live admin.
On Etherscan, look for the Proxy tab. Check the implementation address and the admin. If the admin is a creator‑controlled wallet or an unlabeled multisig, they can upgrade to a malicious implementation that turns transfer into a trap. Renounce means nothing if an upgrade flips the logic.
Factories can muddy attribution. Launchpads like PinkSale or Gempad often deploy tokens via a factory. You must still chase the owner after deployment, the wallet that receives marketing fees, and any manager roles set at init. Consensys and PeckShield have warned repeatedly that “renounced” with hidden managers is a common stunt.
BSC honeypot check cases tend to be more chaotic because fees are low and MEV bots swarm. You will see more deployments per creator, more copy‑paste contracts, and more aggressive blacklist code. The playbook is the same, just faster. Use BscScan’s labels, DexScreener’s chain filter, and keep your buys tiny if you must touch anything new.
Token tax marketing is also more common on BSC. Teams pitch reflections, auto liquidity, or buyback fees. These can be legitimate designs, but if setFeeTx or its cousins are owner‑controlled without caps, assume sell tax can be set to 99 percent at any time.
Keep this tight and unforgiving. If you tick several of these, skip the token.
Say you spot a new coin on CoinGecko trending tab and a green DexScreener chart on Ethereum. You open the token on Etherscan, click the Contract tab, then Creator. The creator shows five contracts created in the past week. Two prior tokens have dead charts, one with only buys for the first hour, no sells, then flatline. You open the old token’s code and see transferFrom uses a modifier that checks a pair mapping, and setIsFeeExempt is only callable by the owner. The owner renounced after 10 minutes, but the manager role still exists on a separate address that can set fees.
Back to the new token, you open Read Contract. There is a limitsInEffect flag set to true, a blacklist mapping initialized but empty, and a setFeeTx function with no maximum. LP is added by the creator, and LP tokens sit in their wallet. Your safe token scanner gives a mixed result, not an outright honeypot. You attempt a 0.005 ETH buy, it fills. You try to sell immediately, the transaction requires 40 percent slippage to pass. That is more than enough data. Walk.
None of this took more than 10 minutes. You avoided becoming exit liquidity.
Audit firms like CertiK and Hacken often publish post‑mortems that read like pattern libraries. You will notice the same handful of code levers in rugs: unrestricted fee setters, blacklist gates, upgradeable proxies with live admins, and liquidity under creator control. On-chain sleuths on X, some anonymous and very sharp, keep public lists of repeat deployers and “factory rugs.” When multiple independent sources point at the same creator clusters, believe the data.
A quick Etherscan contract check combined with these public warnings is often enough. Wait for clarifications, demand verifiable LP locks, and verify code limits. If a team refuses, your timeline is telling you everything.
There are legit projects with anti‑bot limits at launch. They enable trading gradually, exclude partners from fees, and relax limits over hours. That alone is not a scam. What matters is transparency and caps. If setFeeTx has a hard coded max of 10 percent, if blacklist is disabled after launch and provably cannot be re‑enabled, if LP is locked for meaningful time, you can consider it.
Proxies are not evil by default. Blue chips use upgradeability. The difference is clear governance, well known multi‑sigs, and public audits. If a small cap claims they need a proxy for “future features,” but the admin is an unlabeled hot wallet, that is not the same class of risk.
Always set your own thresholds. I avoid any token where I cannot verify the worst‑case outcomes. If I cannot bound fees, if I cannot prove LP safety, if creator history is dirty, I pass. Missing one moonshot is cheaper than eating one honeypot.
Do this a few times and your hit rate will improve fast. The habit pays for itself the first time you avoid a “token cannot sell” spiral. And if you are ever unsure, step back. Markets are infinite. Your bankroll is not.