Honeypot tokens and how to spot one

What a honeypot token is

A honeypot token is a token whose contract is written so that buying succeeds and selling does not. On the surface it behaves like any other token on a decentralized exchange: the price chart moves, buys go through, and a balance appears in your wallet. The trap is in the exit. When a holder tries to sell back to the pool, the transaction reverts, or so much of the proceeds is confiscated by a tax that selling is pointless, or the account simply is not permitted to sell at all. The deployer, meanwhile, retains the ability to sell and withdraws the value that buyers deposited. Because the loss is bounded by what you spent acquiring the token, a honeypot is a scam that monetizes the purchase itself rather than a later theft.

The economic signature is distinctive. A honeypot’s on-chain history typically shows many buys and few or no successful sells by ordinary holders, because the contract is preventing those sells. That asymmetry is one of the clearest tells available before you commit funds.

The contract mechanisms

Honeypots are implemented in the token’s transfer logic. Several techniques recur, sometimes in combination:

• Reverting sells. The transfer function contains a condition that causes any sell, a transfer to the liquidity pool or router, to revert, while allowing buys. Buyers can enter; nobody can leave.
• Confiscatory sell tax. Rather than blocking outright, the contract applies an extreme tax on sells, for example taking the large majority of the proceeds. A token that lets you sell but keeps most of what you sell is a honeypot in effect even if a sell technically succeeds. Some contracts let the owner raise this tax after launch.
• Blacklists. The contract exposes a function that lets the owner add addresses to a blacklist that cannot transfer or sell. Ordinary buyers are added over time, or everyone except whitelisted addresses is effectively blocked.
• Whitelisting the deployer. Only specific addresses controlled by the scammer are permitted to sell. This is the mechanism behind the tell that only the deployer can sell.
• Maximum-sell limits. A cap so low that meaningful exit is impossible, sometimes combined with cooldowns.
• External dependencies. The transfer logic calls out to another contract the owner controls, so behavior can be changed after launch without touching the token contract itself.

What unites these is that the restriction lives in code the buyer can, in principle, inspect before buying, which is why review is the core defence.

Detection method one: simulation and honeypot checkers

The most accessible check is a honeypot simulator. Tools such as honeypot.is take a token address, execute a buy and then a sell against a fork of current chain state, and report whether both succeed along with estimated buy and sell taxes. A sell that reverts in simulation is a direct, mechanical warning that the contract blocks exits. High or asymmetric taxes shown by the tool, a low buy tax with a punitive sell tax, indicate the confiscation mechanism.

These simulators are valuable precisely because they exercise the exit path rather than trusting the token’s marketing. GoPlus Security’s token-security data, used by many wallets and interfaces to surface automatic warnings, performs comparable analysis. A related manual variant is a minimal test purchase followed by an immediate attempt to sell a small amount; if the sell fails, the behavior is confirmed, though this risks the test funds and should only be considered where that loss is acceptable.

Reading the on-chain trade history directly complements the simulator. A block explorer or a decentralized-exchange data tool lists the individual buys and sells against the liquidity pool. A pattern of many distinct buyer addresses with few or no successful sells by anyone other than the deployer is the economic footprint of a working honeypot, because the contract is preventing those holders from exiting. Conversely, a healthy two-sided history of buys and sells by many independent addresses is evidence, though not proof, that the exit path currently functions. This check is useful precisely because it observes what holders were actually able to do rather than what the contract claims, and it requires no code-reading skill.

The critical limitation, stated by honeypot.is itself, is that a token classified as not-a-honeypot at scan time can change afterward. If the owner can raise the sell tax, enable a blacklist, add a max-sell limit, or swap an external dependency, a clean scan reflects only the state at that instant. A passing simulation is therefore evidence of current behavior, not a guarantee of future behavior, and must be combined with source review of what the owner is permitted to do.

Detection method two: verified-source review

Open the token on a block explorer and check whether its source is verified. As covered in contract-verification guidance, a verification badge means the published source recompiles to the deployed bytecode, so what you read is what runs. On verified source you can look for the mechanisms above:

• Owner-only functions that set or change a tax, a fee, a blacklist, a whitelist, or a maximum transaction or sell amount, for example functions named along the lines of setTax, setFees, setBlacklist, setMaxSell, or excludeFromFee.
• Conditions in the transfer path that treat sells differently from buys, or that gate transfers on an allow-list.
• Calls to an external contract inside transfer logic, which can move the malicious behavior off the token contract.
• The absence of any renouncement of ownership where the token claims to be immutable.

The corollary is equally useful: a token that asks the public to buy but whose contract source is not verified is itself a warning. Without verified source there is no way to review the transfer logic, and legitimate projects that want holders generally verify. Unverified code plus a buy request is a reason for caution on its own.

A further point about ownership is worth making precise, because it is frequently misunderstood. A contract whose owner has renounced ownership cannot have its tax raised or a blacklist toggled by that owner afterward, which removes one avenue for a later trap. But renouncement is not a clean bill of health: the harmful logic may already be hard-coded into the transfer function so that no owner action is needed, or control may sit in an external contract that was not renounced. Read renouncement as one fact among several, and confirm from the source what the transfer path does unconditionally, not merely what the owner is currently able to change. Some wallets and decentralized-exchange interfaces surface automatic warnings drawn from security data providers; heed those warnings, but do not treat their absence as clearance, since new or obscure tokens may simply not have been assessed yet.

Reading the two checks together

Simulation and source review answer different questions and are strongest together. Simulation answers can I sell right now, and at what cost? Source review answers what is the owner permitted to do to me after I buy? A token that passes simulation but whose source lets the owner enable a blacklist or raise the sell tax is not safe; it is currently benign and structurally able to become a honeypot. Conversely, a token whose sell reverts in simulation needs no further analysis, the exit is already blocked.

Because detection here genuinely requires contract review, the honest characterization of difficulty is that spotting a honeypot is achievable but not casual: the tools are accessible, yet interpreting them, and reading verified source for owner powers, takes deliberate effort. The general principle that follows is conservative. A token you cannot evaluate, because its source is unverified, its owner retains broad transfer-altering powers, or its history shows buys without holder sells, should be treated as unsuitable to buy regardless of how it is being promoted, since the amount at risk is the entire purchase.

Sources

• honeypot.is token honeypot checker
• GoPlus Security Token Security API documentation
• Types of Contract Verification (Etherscan Information Center)
• Verifying smart contracts (ethereum.org)
• Ethereum security and scam prevention (ethereum.org)