How to identify honeypot tokens

A practical checklist for detecting tokens that can be bought but not sold, covering contract identity, transfer restrictions, administrator powers, simulation, liquidity, and small round-trip tests.

For educational purposes only; not investment advice. Crypto assets can lose all value.

Direct answer

A honeypot token is designed or configured so that a trader can acquire it but cannot sell it normally, or can sell only after an extreme fee. The restriction may sit in the token’s transfer logic, an external contract, an address list, a trading switch, a transaction limit, or an upgradeable implementation.

No single scanner result proves that a token is safe. Use several independent checks: verify the exact chain and contract address, inspect verified code and privileged roles, simulate the complete sell path from the intended wallet, examine real sell transactions and pool liquidity, and only then consider a small round trip whose full loss is acceptable.

A rising chart is weak evidence. When most holders cannot sell, recorded trades can show buys without a competitive flow of sells, while the displayed price says little about how much value can actually leave the pool.

Chain and contract address were independently verifiedBuy, transfer, and sell behavior were simulatedOwner, upgrade, mint, pause, blacklist, and fee powers were inspectedLiquidity, holder concentration, and withdrawal conditions were checkedSource verification and recent privileged changes were reviewed

0 / 5

0 items reviewed; 5 items still unresolved

Completing this review does not prove an asset, transaction, or system is safe.

How it works

ERC-20 standardizes functions such as transfer and transferFrom, but it does not require every token to have identical policy. A custom implementation can add conditions based on sender, recipient, amount, block state, or another contract. Code can therefore allow transfers into a liquidity pool while reverting, confiscating most of the amount, or selectively blocking transfers out through the sell route.

Review the complete execution path, not only a function name. A sell on an automated market maker may involve an allowance, a router, one or more pools, and the token’s transfer logic. Look for owner or role-controlled functions that can pause trading, change fees or limits, manage allowlists or blocklists, replace a router or pair, mint supply, or change a dependency.

Ownership renunciation is not conclusive. Other roles may remain, an external controller may hold authority, or a proxy may keep the same address while its implementation logic changes. OpenZeppelin’s access-control documentation explicitly notes that privileged functions can mint, freeze transfers, or perform upgrades; a timelock matters because it gives users notice before a scheduled change.

Simulation is useful but bounded. Ethereum’s eth_call executes without creating an on-chain transaction and uses the state at a selected block; eth_estimateGas also does not add the transaction to the chain. Set the actual sender, route, amount, and current block context. A successful result describes that call under that state, not a guarantee about the next block or a later administrator action.

A verification workflow

Confirm the network and full contract address from independent official sources. On an explorer, verify that the deployed bytecode matches the published source and determine whether the address is a proxy.
Trace both transfer and transferFrom behavior, including inherited code and external calls. Identify fee setters, trading switches, maximum-wallet or maximum-transaction rules, address lists, exemptions, roles, proxy administrators, and any delay on privileged changes.
Inspect recent on-chain sells by unrelated addresses. Confirm that swaps produced the expected output asset, not merely a successful transaction status. Compare input, output, transfer events, effective fee, price impact, and pool reserves.
Simulate the exact sell transaction from the intended wallet at the current state. Compare at least two independent tools or RPC providers when the result matters, and treat a revert, unexplained output, or large discrepancy as a stop signal.
If the preceding checks are satisfactory, test a buy and sell with an amount you can lose completely. Verify the wallet’s final balances and transaction receipts. Do not increase slippage repeatedly to force an unexplained trade through.

The economically relevant figure is recoverable value, not the quoted wallet balance:

Recoverable value = expected swap output - price impact - protocol fee - token fee - network fee

Pool reserves can also make a legitimate token difficult to exit. Estimate the output for the intended position size; a successful tiny sale does not show that a larger sale can clear near the displayed price.

Red flags and limits

Sells consistently revert while buys succeed, or only privileged and exempt addresses can sell.
The effective sell fee is extreme, undisclosed, wallet-specific, or changeable immediately by an administrator.
Verified source is absent, does not cover the active proxy implementation, or depends on an unverified external contract.
Liquidity is shallow, concentrated under one controller, or removable without a meaningful lock or governance delay.
Simulators disagree, the route works only through a project-controlled interface, or recent independent sell evidence is absent.

Stop when contract identity is uncertain, a sell cannot be explained, privileges cannot be enumerated, or the prospective loss exceeds the test budget. Buying again is not a diagnostic step. Increasing gas can help transaction inclusion, but it does not bypass a contract restriction; increasing slippage only accepts a worse execution price and may expose the trade to additional loss.

Even a clean review and successful round trip are point-in-time evidence. Pool reserves, blocklists, fees, external dependencies, and upgradeable logic can change afterward. Recheck before each material increase in exposure and assume that no checklist removes smart-contract or liquidity risk.

Common misconceptions

“Verified source means safe.” Verification links source to deployed bytecode; it does not prove that the logic is benign or that privileged roles are constrained.
“Renounced ownership means no one can change the rules.” Separate roles, controllers, or proxy administrators may retain authority.
“A scanner says sellable, so the next sale will work.” The state, sender, route, block, liquidity, and implementation can differ from the scanner’s test.
“A successful small sale proves the whole position can exit.” Fee tiers, wallet limits, price impact, and finite reserves can produce a very different result at a larger size.

Sources

ERC-20: Token Standard - Ethereum Improvement Proposals (accessed: 2026-08-20)
JSON-RPC API - Ethereum.org (accessed: 2026-08-20)
Access Control - OpenZeppelin (accessed: 2026-08-20)
Proxy Upgrade Pattern - OpenZeppelin (accessed: 2026-08-20)