New tokens are cheap to deploy and even cheaper to abuse. The fastest way to catch a scam before it catches you is to focus on minting rights, supply controls, and transfer rules. If a contract can print more supply at will, or if it can silently block sells, everything else is window dressing.
This guide walks through what actually matters when you check if a token is scam, how honeypot token detection works at a code and liquidity level, and how to use explorers like Etherscan and BscScan to validate what you are buying. I will call out specific functions to look for, explain how sell restrictions are implemented in practice, and share a workflow I use across Ethereum, BNB Chain, and EVM sidechains.
Why minting and supply controls are the core risk
Every ERC‑20 or BEP‑20 boils down to a ledger of balances and a few functions: transfer, transferFrom, and sometimes mint or burn. The moment a contract can increase its supply without constraint, your slice of the pie can be diluted to near zero. That is the classic infinite mint rug.
Supply controls also hide in subtler places. A token can block your ability to sell without ever changing total supply. Honeypot crypto schemes route sells through a DEX pair, then revert in special cases like if msg.sender is not whitelisted. From the outside, price pumps and you can buy, but any attempt to exit fails. A safe token scanner should tell you whether the contract has code paths that discriminate against sellers.
DexScreener and CoinGecko can show market data, but they do not inspect mint authority or blacklists. That is your job, and it starts with an etherscan contract check or bsccscan equivalent.
Reading the contract: the functions that matter
You do not need to be a Solidity engineer to catch 80 percent of traps. Scroll the verified source and search for these pressure points.
Mint authority and supply caps
Look for function mint(address to, uint256 amount) or internal calls like _mint. If mint is public or external and gated only by onlyOwner, the owner can expand supply at any time. Some projects set a hard cap in code, like require(totalSupply() + amount <= maxSupply). That is better, but only if maxSupply is immutable or not changeable by the owner.</p>
Be careful with proxy patterns. If the token is behind a proxy, the implementation can be upgraded to add a mint function later. On Etherscan, check the “Proxy” badge and click through to the implementation. If you see an upgradeable pattern, review the admin multisig and timelock. Upgradable tokens are not always bad, but the upgrade authority should be a reputable multisig with visible signers, not a single EOA.
Ownership, roles, and the myth of renunciation
Many rugs call renounceOwnership() to look safe. On Etherscan, that flips owner to the zero address. If the contract uses OpenZeppelin’s Ownable, renunciation removes owner‑only powers. But if the code also has a manager, controller, or role‑based access control like AccessControl, those roles can still execute sensitive functions. Scan for onlyOwner, onlyRole, and custom modifiers. If you see DEFAULT_ADMIN_ROLE, check who holds it in the “Read Contract” > “getRoleMember” panels.
Renouncing ownership also does not matter if the critical parameters were already set to malicious values before renunciation. I have seen tokens where the team set a blacklist and a 99 percent fee, then renounced. The trap was baked in.
Transfer path hooks, fees, and sneaky sell restrictions
Tokens implement special logic in _transfer or hooks like _beforeTokenTransfer. Search for these functions and scan for conditionals around the DEX pair. The typical pattern checks from == pair (buys) or to == pair (sells), then applies extra rules.
Common red flags: a setFeeTx or similar function toggles an arbitrary fee that can be adjusted to 100 percent, making sells impossible. Some contracts keep separate buy and sell tax variables, for example buyFee and sellFee, and allow the owner to increase the sell side later. Others maintain a blacklist mapping, like mapping(address => bool) isBlacklisted, and block transfers if isBlacklisted[from] is true.
Look at transferFrom as well. Approvals plus transferFrom can be used to drain user wallets if the token bugs allowances. Malicious tokens sometimes override approve or transferFrom to set hidden allowances or to block revocations. It is rare, but a quick scan never hurts.
A quick on‑chain checklist before you buy
- Verify minting: is there a mint function, who can call it, and is there a hard cap that cannot be changed? Ownership power: who is owner or admin, is the contract upgradable, and are there any hidden roles or managers? Transfer rules: scan _transfer and hooks for sell‑side checks, blacklists, max wallet or max tx limits, and any setFeeTx style toggles. Liquidity posture: how much liquidity is in the main pair, is LP locked or burned, and can the deployer withdraw it through a router call? Trading gates: is trading gated behind a flag like tradingEnabled, when was it enabled, and can it be turned off or weaponized?
This is learn more the fastest path to avoid crypto scams on EVM chains. If you want a second opinion, a honeypot token checker or bsc honeypot check service can simulate a buy and sell. Treat them as signals, not gospel. Contracts can whitelist scanner addresses.
Liquidity tells you what the code tries to hide
You can confirm behavior by looking at the DEX pair on Etherscan or BscScan. Locate the token’s primary LP, check reserves, and see who added liquidity. If the deployer owns the LP tokens and they are not locked or burned, they can pull the rug by removing liquidity. A large mint authority combined with unlocked liquidity is a time bomb.
DexScreener helps surface which pools are active and if liquidity is fragmented across multiple pairs. Fragmentation can be a tactic to fake depth. If you see one pair with tiny liquidity but explosive price action, and another dead pair with most of the supply, be suspicious.
Max transaction or max wallet limits can trap you even if liquidity looks healthy. These limits often appear as variables like maxTxAmount or maxWallet. Some teams increase them over time, others use them to block sells while allowing buys. On the read contract tab, try fetching these values and compare them to total supply.
How honeypots actually block your exit
Honeypot tokens typically let transfer succeed between wallets, and let buys go through the router into the pair. Sells fail with a revert only when to == pair or when the router is the caller. That is why basic wallet to wallet tests do not catch them.
I look for three mechanics in the code:
- A boolean like sellingEnabled that can be turned off after hype builds. A fee variable for sells that can be set near 100 percent so your tokens are swapped but you receive almost nothing. A blacklist or anti‑bot list seeded during launch that later gets wide entries, including any address that ever received tokens from the router.
Honeypot token detection tools try a simulated buy and sell through the router. Good ones rotate caller addresses and use small random gas limits to mimic retail flow. But whitelists exist. If you want to be sure, try a tiny live test with a burner wallet on a low fee chain. On BNB Chain, a sub‑dollar test can be enough. If the token cannot sell at all or slippage has to be absurd, walk.
Roles, routers, and the DEX gotchas
Not all fee and blacklist logic is evil. Anti‑bot systems around launches do help for the first few blocks. The problem is persistence. If there is no time decay or if only the owner can remove restrictions, you are trusting that owner indefinitely.
Router dependencies are another edge case. Some tokens restrict transfers unless the router address is part of the flow. That can brick transfers later if the project migrates to a new router or chain. A safe pattern treats the router and pair addresses as configurable only by a governance process, not a single EOA.
Watch for reflection tokens and tokens with rebasing supply. They alter balances on transfer or per block. If the math is sloppy or fees stack, you can end up with transfers that revert due to rounding. That looks like a honey pot to users, but it is actually bad accounting.
Forensics when you smell smoke
When the code looks murky, on‑chain behavior usually gives it away. On Etherscan or BscScan:
- Open the holder list. If the top holder is a fresh contract with ownership of LP tokens, that is the LP token contract, not a red flag by itself. The next top holders matter more. If a single EOA holds 50 percent of supply and is not a vesting contract, you are one tweet away from a dump. Check internal transactions around the deploy block. If mint events show supply increases after launch, figure out who called them and when. Many rugs mint in stealth after setting a few legit‑looking parameters. Review approvals to the router. If users globally approve the token to the router and the token overrides transferFrom in a dangerous way, the attack surface grows. It is rare, but a high risk if present.
Security firms like PeckShield, CertiK, Hacken, and Consensys diligence teams often flag trending contracts with mint or transfer traps. On X, on‑chain sleuths will post bytecode snippets and decoded events when a new honeypot hits. Treat those warnings as early smoke detectors.
When renouncing and audits still are not enough
A token can be audited yet still be dangerous if the team later deploys a new implementation behind a proxy or changes parameters after the audit snapshot. Reputable audits help, but you should still re‑check ownership, upgrade keys, and config right before you buy. If ownership was renounced, confirm that all powerful roles were removed, not just owner.
An honest team will lock LP tokens for a defined period, show a public multisig for upgrades, and set immutable or time‑locked supply caps. They will also set sane, bounded fees. A setFeeTx that can go from 2 percent to 98 percent is not bounded. Watch for code that clamps fees within a small range, and verify those clamps are enforced in all paths.
A quick, real‑world workflow
Say a friend sends you a hot BSC token. You paste the address into BscScan. The contract is verified. You search for mint. There is a mint function gated by onlyOwner, and maxSupply exists but there is another function setMaxSupply callable by the owner. That means caps are mutable. You search for _transfer. You find a sellFee and buyFee, plus a setFeeTx that sets both without limits. You also see isBlacklisted and a function to add any address to it, again owner‑only.
You switch to the Read tab. owner is a fresh EOA, not a multisig. Check the pair on the token tracker. Liquidity is 150k USD equivalent, LP tokens sit in the deployer wallet. Nothing is locked. You check DexScreener, see a sharp up‑only chart with thin liquidity and volume mostly buys. Sniff test fails on three independent axes: mint risk, sell fee and blacklist risk, and LP unlock. That saves you a headache.
Now a healthier example. You check an Ethereum token. No mint after construction, totalSupply matches the initial mint. Fees exist but are bounded to a small maximum with explicit require(fee <= 5). Ownership is a 3 of 5 multisig with doxxed signers. LP tokens are in a time‑lock for a year. There is a tradingEnabled flag, but the function to disable trading is not callable after it is first enabled. That is not perfect, but it is a reasonable DeFi safety baseline.</p>
Common red flags that map to real losses
- Owner can mint at any time, or can raise maxSupply without community consent. Sell path has higher, unbounded tax controlled by setFeeTx, or a fee that can be directed to the owner. Blacklist or anti‑bot logic with no decay, plus broad discretionary power to add addresses after launch. Upgradable proxy with a single EOA as admin, no timelock, and no audit of the latest implementation. LP not locked or burned, or liquidity split across fake pairs to exaggerate depth.
If you see two or more of these, consider it a stop sign. A honeypot token checker might still return green if it is whitelisted in code. Your own small live test, done with throwaway funds and a burner wallet, beats any safe token scanner.
What actually keeps you safe
Scam tokens rely on speed and opacity. Slow down and use public data. An etherscan contract check will tell you who holds the keys. DexScreener and the DEX pair page will show whether you can reasonably exit. Audit names from firms like Consensys Diligence, PeckShield, Hacken, or CertiK can raise confidence, but only if you confirm the exact contract and settings match the audit.
Most importantly, trace the power to three places: who can mint, who can change transfer rules, and who can pull liquidity. If those controls are limited, time‑locked, or genuinely renounced, risk drops fast. If they are concentrated in one fresh wallet, do not let a green candle talk you into becoming exit liquidity.