Every cycle, traders lose money to tokens that were never meant to be sold. You buy in, the chart looks healthy, and when you try to exit, the transaction reverts. Or the price is fine until the deployer pulls the liquidity and the token goes to zero in a single block. Effective honeypot token detection is the difference between a calculated bet and a guaranteed loss, and most of the warning signs are visible on-chain before you ever click buy.
This guide explains what honeypots and rug pulls are, the concrete red flags you can check, how automation catches them, and where even good tooling falls short. None of this is financial advice.
What Are Honeypot Tokens and Rug Pulls?
A honeypot token is a contract designed so that buying works but selling does not. The trap can be coded directly into the transfer logic, hidden behind owner-only switches, or gated by conditions that only trigger for ordinary holders. The deployer can usually still sell; you cannot.
A rug pull is broader. Here the contract may function normally, but the team retains the power to destroy value: they remove the liquidity pool, mint a flood of new tokens, or quietly transfer ownership to an address that drains the project. The token works right up until the moment it doesn't.
The two overlap. A honeypot is one way to rug; an unlocked liquidity pool is another. Both come down to the same question: who holds power over this contract, and what can they do with it?
The On-Chain Red Flags
Most dangerous tokens share a recognizable set of traits. You can check these against verified source code on a block explorer or infer them from contract behavior.
- Can't-sell logic. Transfer or approve functions that revert for non-privileged addresses, fees set to 100% on sells, or a transfer path that only succeeds for whitelisted wallets.
- Hidden mint functions. A
mintcallable by the owner with no cap lets the team dilute every holder to zero. Watch for unbounded supply changes. - Blacklist / pause controls. Functions that let the owner freeze specific addresses or halt all transfers. Even if unused today, they can be flipped after you buy.
- Unlocked liquidity. If the LP tokens sit in the deployer's wallet rather than a lock contract or burn address, liquidity can be withdrawn at any time.
- Excessive owner privileges. The ability to change fees arbitrarily, set max transaction limits, or reassign critical roles after launch.
- Fake ownership renounce. A project may claim ownership is renounced while a hidden second admin role, a proxy upgrade path, or a backdoor modifier preserves full control.
A quick triage table:
| Red flag | What it enables | Where to look |
|---|---|---|
| Can't-sell / 100% sell tax | Traps buyers | Transfer & fee logic |
| Unbounded mint | Infinite dilution | Supply functions |
| Blacklist / pause | Freezing holders | Owner-only modifiers |
| Unlocked LP | Liquidity removal | LP token holder |
| Proxy / upgradeable | Logic swap post-launch | Proxy storage layout |
| Fake renounce | Hidden control | Admin roles, second owner |
How Automated Detection Works
Manually reading every contract is slow and error-prone. Two automated techniques do most of the heavy lifting.
Buy/Sell Simulation
The most direct honeypot test is to simulate the round trip. Using eth_call against a public RPC endpoint, a scanner can simulate buying the token and then immediately simulate selling it back, all without spending real funds or broadcasting a transaction. If the simulated buy succeeds but the simulated sell reverts, you've found a honeypot. This catches traps that are invisible in marketing material because it tests actual contract behavior rather than promises.
Bytecode and Source Analysis
Simulation tells you that something is wrong; static analysis tells you why and surfaces dormant risks. When verified source is available (via an explorer such as Etherscan), tools can parse the code directly. Where it isn't, bytecode-level analysis still reveals dangerous patterns. Static analyzers like Slither, symbolic-execution engines like Mythril, and fuzzers like Echidna can flag:
- Mint and ownership functions and who can call them
- Suspicious fee and transfer modifiers
- Proxy storage-collision risks in upgradeable contracts
- Access-control gaps and reentrancy
Layering source analysis over simulation gives you both the behavioral verdict and the structural reasons behind it, including risks that haven't been triggered yet.
The Limits: No Tool Catches Everything
Be honest with yourself about coverage. Automated checks are necessary but not sufficient.
- Amount-gated honeypots. A contract may allow small sells to pass simulation while blocking large ones, defeating a naive round-trip test that uses a tiny amount.
- Time- or block-gated traps. Selling works for a window after launch, then logic flips. A point-in-time scan can miss this.
- Off-chain dependencies. Oracle manipulation, a malicious owner key held by a real person, or social-engineering exit scams aren't visible in bytecode.
- Unverified source. Without verified code, analysis leans on bytecode heuristics, which are powerful but less precise than reading the source.
- Externally controlled liquidity. A lock can exist and still expire next week; "locked" is not "locked forever."
The right mindset is layered: a token that passes every automated check is less risky, not risk-free. A check that can't run should be treated as an open question, not a green light.
A Practical Checklist Before You Buy
- Confirm the source is verified, then read who can mint, pause, blacklist, and change fees.
- Simulate a buy and a sell — ideally at a realistic position size, not dust.
- Locate the LP tokens. Are they burned, in a credible lock, or in the deployer's wallet?
- Verify any "renounced ownership" claim against admin roles and proxy upgrade paths.
- Treat anything you can't verify as a risk you're choosing to accept.
Automating the Checks
Running Slither, Mythril, Echidna, simulation, and liquidity checks by hand for every token is a lot of work. NANOTESTING bundles these into one hosted smart-contract audit: it runs buy/sell honeypot simulation via eth_call, performs static and symbolic source analysis, checks LP locks and owner privileges, and reports an A–F risk grade. Critically, when a check can't run — for example, missing verified source — it's shown as a coverage gap, never a clean pass, so you always know what was and wasn't tested.
No scanner replaces judgment, but automating the mechanical red-flag checks frees you to focus on the risks that genuinely require it.