What a honeypot actually is
A honeypot token looks completely normal from the outside: it has a name, a symbol, a chart, sometimes even real early buyers. The trap is in the contract code, not the marketing. Common mechanisms: a hidden sell tax set to 100%, a blacklist function the deployer quietly adds your wallet to after you buy, or a trading-enabled flag that only the deployer's own wallet can bypass. In every case, the buy transaction succeeds, and the sell transaction reverts or returns almost nothing.
Reading the contract source won't reliably catch this. Deployers who build honeypots on purpose write code that looks clean on a skim, or they simply don't verify the source at all, which is itself a signal but not proof either way.
The only test that actually proves it
The only reliable way to know if a token is a honeypot is to simulate a real buy, then a real sell, and see if the sell actually succeeds. Not read the code. Not check if it's "verified." Actually try the trade.
How to check a token in under a minute
Reading the result correctly
| Verdict | What it means |
|---|---|
| PASS | Simulated sell succeeded with a normal loss. Not a guarantee of profit, just not a trap. |
| CAUTION | Something else is flagged (unverified source, thin liquidity, deployer history) but the sell itself worked. |
| DANGER | The simulated sell failed, or lost an extreme amount. Treat as a honeypot. |
| "could not simulate a sell" | No pool exists yet, or it's a fresh launch. Not proof of danger, but also not proof of safety, there's simply no trade to test yet. |
One honeypot trick this doesn't catch
A deployer can sometimes make a token sellable for the first buyer (to fool a scanner or an early investor into vouching for it) and only start blocking sells later, once volume builds. This is rare because it requires deliberately time-delayed logic, but it's why a PASS from an hour ago isn't a PASS forever for a token whose contract source is unverified. Re-scan before a large trade on any unverified contract.
Frequently asked
Can a token be a honeypot for some wallets but not others?
Yes. A deployer can hard-code a blacklist that only blocks specific addresses, or add liquidity in a way that only their own wallet can withdraw from. A general simulation catches the common "nobody can sell" case; it can't prove a targeted blacklist doesn't exist for a wallet it hasn't tried yet. Verified source code is the only way to rule this out with certainty.
Does a verified contract mean it's not a honeypot?
No. Verified just means the source code on the explorer matches what's deployed, it says nothing about what that code does. A verified contract can still have a 99% sell tax written in plain sight. Verification helps you (or a scanner) read the logic; it doesn't replace actually testing a sell.
Can a token's honeypot status change after launch?
Yes, if the contract has an owner function that can change tax rates, add blacklists, or disable trading. This is why ScanHood also checks for that kind of owner power separately from the honeypot simulation itself, a token can be sellable today and not tomorrow if the deployer kept that lever.
What does "no pool / new token" mean exactly?
It means there's no liquidity pool yet for the simulator to test a trade against, usually because the token launched seconds ago. It is not a safety signal either way. Locked-liquidity launchpad tokens (see the no-rug guide) are a partial exception, some are structurally safe from the moment of launch even before a normal pool exists.