When a token starts pumping on DexScreener and your group chat yells buy, the only thing between you and a honeypot is a 3 minute contract check. Etherscan’s Contract tab is enough to spot most sell restrictions and silent admin switches. You do not need to be a solidity dev to catch the obvious traps, but you do need a method.
This is a practical walkthrough of the Read Contract and Write Contract tabs on Etherscan, with the usual landmines I see in audits and post-mortems. Everything here also applies to BscScan on BNB Chain, with the same layout and quirks.
Start on the right contract
Open the token on Etherscan, go to the Contract tab. If you see “Contract Source Code Verified,” great. If it shows “This contract may be a proxy,” click through to the Implementation address. Most routing tokens and hyped launches use proxies to allow upgrades. You must analyze the implementation, not the proxy wrapper. Many “safe token scanner” tools miss this and give you a false sense of security.
Glance at the compiler version and libraries. If you see OpenZeppelin imports, you can expect standard roles like Ownable or AccessControl. If verification is missing, you are flying blind. At that point, rely on bytecode heuristics, community alerts from PeckShield or CertiK, and avoid large positions.
Read Contract tab: the fastest x-ray
The Read tab is your passive view. No wallet, no transactions. Think of it as a dashboard of storage variables. I focus on a small set of functions that correlate with honeypot token detection and sell locks.
- Open Read Contract and check: owner or getOwner, sometimes _owner or owner() tradingEnabled, isTradingEnabled, or a boolean like tradingOpen blacklist or isBlacklisted(address) maxTxAmount, maxWallet, limitsInEffect buyFee, sellFee, taxFee, setFeeTx variables pair or uniswapV2Pair, pancakePair feeExempt or isExcludedFromFees(address) paused or paused() for Pausable router, marketingWallet, treasury, feeRecipient totalSupply, decimals, name, symbol
A few seconds on each of these tells you 70 percent of what matters. If there is a proxy, repeat on the implementation’s Read tab.
Ownership and admin control
If owner() returns a wallet, ask yourself if you trust it. Renounced ownership helps, but scams sometimes use a proxy where the implementation’s owner is zero while the proxy admin retains full upgrade power. If you see TransparentUpgradeableProxy or UUPS, check the proxy admin on the proxy page. Etherscan often exposes Admin in a separate field. A contract with renounceOwnership in code is meaningless if an upgrade can reintroduce fees later.
AccessControl variants use roles like DEFAULT ADMINROLE. Read hasRole(role, address) if exposed, but many projects do not make this friendly. Presence of AccessControl is not bad, just note that DEFAULT ADMINROLE holds real power even if owner is zero.
Trading gates and liquidity toggles
Look for tradingEnabled or tradingOpen. If false, you cannot trade yet, even if liquidity is there. If true, still verify sell mechanics by looking at fees and limits. Some tokens let buys through from the router before enabling sells, catching early apes in a token cannot sell trap.
Check uniswapV2Pair or pancakePair. If the pair address is zero, there may be no official pool. That is a red flag if trading is already hyped. On live pairs, click the pair address to see liquidity supply and lock status in the Pair Info. Liquidity presence is not a safety guarantee, but no liquidity or a dev-owned LP on BSC is a common setup for soft rugs.
Blacklists and exemptions
IsBlacklisted(address) or blacklist(address) mapping presence is not instant doom. It has legit uses against bots. The danger is obfuscated function naming or bitwise maps that silently block sells from normal users. If you can read isBlacklisted, paste your wallet and a random buyer’s wallet from the token holders list. If either returns true, walk away.
Look for isExcludedFromFees or feeExempt(address). High sell tax honeypots often exempt the deployer and their test wallets, making it look safe in small buys. Then public wallets face 99 percent sell tax. If exemptions exist, check whether the router or pair is exempted. That can indicate weird accounting that disables sells via the pool.
Limits and taxes
MaxTxAmount and maxWallet are standard anti-whale tools. If maxTxAmount is very low relative to totalSupply, you may not be able to sell a reasonable position. Values expressed in raw token units need decimals applied. For a token with 18 decimals, a maxTxAmount of 1000000000000000 equals 0.001 tokens. I have seen rugs set maxTx during hype to a tiny fraction so your sell reverts.
Fees get split across buyFee, sellFee, taxFee, liquidityFee, marketingFee. If you see a combined sellFee over 20 to 30 defi scam detector percent, be skeptical. I have audited real projects with temporary high taxes during launch, but these are rare and usually well documented. Also read the swapThreshold or tokensForSwap values. Contracts can accumulate taxes and auto swap on sells, causing huge price slippage for unlucky sellers.
Hidden honeypot toggles
Some creators rename variables. Look for innocuous names that gate behavior, like limitsInEffect, tradingLimits, cooldownEnabled, transferDelay, or marketActive. Cooldown or transfer delay mechanics can block rapid sells and turn into a honeypot when misconfigured. Also scan for custom functions that look like setFeeTx, setTax, setLimits, enableTrading, or manualSwap. If these exist under an owner, they can flip conditions after launch.
As frequently highlighted by firms like PeckShield and ConsenSys Diligence, a quick scan of these toggles before buying catches a surprising number of bad actors.
Write Contract tab: safe probing without hurting yourself
Write lets you call state-changing functions, but be careful. You do not want to be the person spending gas to test a rug’s kill switch. The safest approach here is mostly observational, with minimum transactions.
Connect your wallet only if you must. If you do, use a fresh address with no approvals. For ERC‑20s, focus on approvals and harmless toggles. For example, you can simulate a sell path by approving the router without actually swapping: approve(router, smallAmount). If this reverts, it is not conclusive, since approve is usually unconstrained. What matters is whether transfer or transferFrom to the pair reverts.
A controlled test I use on low value is to transfer a tiny amount to the pair address. If transfer(pair, 1) fails with a custom error or revert, it often indicates anti-sell logic that blocks transfers to automated market maker pairs. Some contracts use an isAMMPair map. If the pair is flagged, sells can be blocked while peer to peer transfers still succeed, the classic honeypot crypto pattern.
If there is a function like enableTrading or openTrading, do not call it. That is an admin action. But its presence tells you the owner can gate trading. A function like setFeeTx or setTaxes is another red flag. A reputable team usually caps fees with require(totalFee <= X). If there is no cap, the owner can set fees to 100 percent.</p>
For tokens using Pausable, pause and unpause can shut down transfers entirely. If you see pause() and unpause() under onlyOwner, you are accepting that risk.
Function names that matter and why
- transferFrom: Router sells use transferFrom under the hood. If transferFrom has extra checks absent in transfer, the contract may let you receive tokens but never route them back to the pool. mint: Many legit tokens mint, especially for staking rewards. If mint is owner-gated with no cap, supply can balloon and nuke price. Read totalSupply and maxSupply if present. renounceOwnership: Trust, but verify. On proxies, renouncing the implementation’s owner does not remove the proxy admin. Some teams use Ownable2Step, which requires acceptOwnership. If you see pendingOwner set but not accepted, control still exists. setFeeTx or setTaxes: Without a hard-coded ceiling or a timelock, this is an instant risk lever. Audit firms like Hacken and CertiK routinely flag unbounded fee setters in reports for good reason.
How to check if a token is a honeypot, fast
Use a mix of on-chain reads and a small live test. External “honeypot token checker” sites are helpful on BSC and Ethereum, but they can miss proxy logic or dynamic limits that switch after the first few blocks of trading. Manual verification is still your best defense.
- Quick Etherscan workflow: On the token page, open Contract, then Read. Confirm owner, trading flags, fees, limits, and pair. Click the pair, check reserves and recent swaps. Look for sells from normal wallets. If no sells appear after many buys, that is a giant warning. In Token Tracker, scan Holders. If the top wallet holds the LP tokens or if a single “marketing” wallet holds most supply, risk is high. If the code is verified, Ctrl+F for blacklist, setFee, maxTx, cooldown, isAMMPair. Note any owner-only mutability. If you must test, send a dust buy, then try a tiny sell. Do not rely on transfer to a friend, test to the router or via a DEX.
That sequence takes two to four minutes and filters most traps. On BSC, where bsc honeypot check tools are common, still confirm via BscScan’s Read Contract.
Sell restrictions you will actually see in the wild
The most common is a per-block transfer delay. Contracts store lastTransferTimestamp per wallet and require that current block is greater than the stored value, which blocks back-to-back trades. In a honeypot this is abused by never updating timestamps for sells to the pair.
Another trick sets a maxTxAmount that changes based on trading phase. Early buyers can acquire tokens, then the owner flips the phase and sets maxTxAmount to a tiny amount that fails your sell. Some do this only for sells by checking if recipient is pair.
Blacklist logic can key off gas price or block number, punishing mempool snipers. That is fine for fair launches, but if the owner leaves it on, regular users get flagged and cannot sell. I have also seen tokens that refund buys with a subtle fee rebate, but block sales for a period under a tradingOpen timestamp. These pass quick honeypot scans until you try to exit.
Finally, watch router and pair addresses. If the token hardcodes a fake router or a custom pair, swaps on Uniswap or PancakeSwap may fail. A safe token usually references a well known router, like UniswapV2Router02 on Ethereum or PancakeRouter on BSC.
Reading revert reasons and events
If a transaction fails, open the failed tx on Etherscan and read the error. Some rugs leave helpful revert strings, like OnlySellsDisabled or MaxTxExceeded. Others hide it behind require(false). When code is verified, Etherscan’s “Decode Input Data” and “Logs” can show events fired just before the revert. For example, an event like SetBlacklist emitted frequently is a bad sign.
If you have access to a node or use Tenderly, simulate a sell and step through the call stack. You will see where transferFrom checks isAMMPair[sender] or takes 99 percent fee on sells.
Cross checking beyond Etherscan
Do not stop at one tool. CoinGecko and CoinMarketCap listings are not safety endorsements, but they sometimes show audit badges. If an audit exists, read what firm did it and whether the report lists unmitigated risks. ConsenSys Diligence, PeckShield, and Trail of Bits are credible names, but even then, audits are snapshots.
Community on X is fast at exposing bad contracts. Accounts known for on-chain forensics often post honeypot warnings within minutes. Treat viral calls carefully, but if multiple sleuths flag blacklist or fee abuse, trust the smoke.
Tradeoffs and edge cases you should weigh
Not every admin function is evil. A fee switch can fund operations, and blacklist can fight MEV bots. The risk comes from who controls it and whether there are caps or timelocks. A timelock on setTaxes with a 24 hour delay makes a fee hike visible. A multisig vs a single EOA for owner reduces rug risk. If the project claims renounced ownership but upgrades still happen, that is a lie, not a nuance.
Some tokens block direct sells to the pair unless routed through the DEX. That is unusual, but I have seen it. So a transfer to pair reverting does not always mean honeypot. You need to test a real swap if you are determined to buy. Keep the test tiny.
Liquidity locks help, but do not prevent bad fee switches or blacklist abuse. Teams can lock LP on Unicrypt or PinkSale, then drain value through taxes. A lock is not a safe token scanner, it is a single data point.
A compact red flags checklist
- Owner can change fees without a hard cap, or can blacklist arbitrary wallets. tradingEnabled or limitsInEffect variables that the owner can flip, with no timelock. Huge sellFee or dynamic tax that treats sells differently, especially if exemptions exist for insiders. Proxy with a separate admin, while marketing claims renounced ownership. No successful sells on the pair after many buys, or transfer to pair consistently reverts.
If two of these show up, treat the token as a crypto scam detection candidate and size accordingly, or pass.
Final thoughts from the audit desk
Etherscan’s Read and Write tabs are the quickest path to clarity. You do not need to reverse engineer assembly to avoid most traps. If you can read a few booleans, spot fee setters, and recognize proxy admins, you will sidestep the majority of honeypot setups that make token cannot sell headlines.
I like automation too. Honeypot token checker scripts and explorers like BscScan’s token security panel can save time. Just remember, scammers iterate. Manual checks, plus watching real sells, keep you ahead.
If a contract looks clean, still plan your exit. Approve the router, sell a test amount, and only then scale. In DeFi, your best defense is speed, skepticism, and a healthy habit of clicking the Read tab before you click Buy.