Token Honeypots: How They Trap Buyers and the Warning Signs

A honeypot token is, in Dedaub’s words, “a crypto token you can buy but cannot sell.” The chart only goes up, because every buy pushes the price higher and nobody except the deployer can sell. By the time a buyer tries to take profit, the sale fails, or goes through and returns almost nothing.

Honeypots are not one trick. They are a family of contract features, most of them with legitimate uses elsewhere, switched on or tuned to trap buyers. This guide explains the main mechanisms on EVM chains (Ethereum, Base, BNB Chain, Robinhood Chain) and on Solana, what scanners like honeypot.is and GoPlus can and cannot catch, the checks you can run yourself on an explorer, and the figures on how common they are.

How a honeypot blocks the sell

On EVM chains, a token is a contract, and every transfer runs its code. Selling means transferring the token into the trading pool. A honeypot adds conditions to that one direction.

Most of these hide in the transfer function. OpenZeppelin’s standard ERC-20 says “all customizations to transfers, mints, and burns should be done by overriding” one internal function, _update, and that is where to look. A simplified illustration, not taken from any real token:

// Illustration only. Real honeypots hide this behind innocent names.
function _update(address from, address to, uint256 value) internal override {
    if (to == pair && from != owner()) {          // someone is selling into the pool
        require(!flagged[from]);                  // blacklist
        uint256 fee = value * sellTax / 100;      // owner can set sellTax to 100
        super._update(from, owner(), fee);
        value -= fee;
    }
    super._update(from, to, value);
}

Names are part of the disguise. CertiK documented a function called “Approval For All” that “doesn’t approve anything, it contains a hidden blacklist.” Researchers studying “Trapdoor” tokens found one that “managed to bypass GoPlus’ check by naming its whitelist with a misleading name allow.”

“Ownership renounced” is not enough

Renouncing ownership is meant to remove the owner’s powers: OpenZeppelin’s renounceOwnership() “leaves the contract without owner,” so onlyOwner functions can no longer be called. Honeypots work around it. SlowMist warns that contracts “may falsely claim to have renounced ownership while retaining the ability to modify the code.” GoPlus flags a hidden owner, “used by developers to maintain ownership ability even after abandoning ownership,” and contracts that can take back ownership. The Trapdoor study describes incomplete renouncement, in which “the scammer can secretly add another of his addresses.” A renounce only matters if the code has no other privileged path.

On Solana, the token program has the switches built in

Solana tokens do not carry custom transfer code by default. Their risks are authorities and extensions set on the mint, which you can read on any Solana explorer:

GoPlus’s Solana checks map onto these: freezable, balance_mutable_authority, transfer_hook (“Hook may block user from trading”) and default_account_state. A token whose liquidity is burned but whose freeze authority is live can still trap every holder; checking liquidity locks covers mint and freeze authority in more detail.

What scanners can and cannot tell you

honeypot.is “simulates a buy and a sell transaction to determine if the token is a honeypot,” plus extra checks. It flags problems such as taxes “extremely high, making it an effective honeypot,” a “very high amount of users” who cannot sell, and source code that is “not available, allowing for hidden functionality.” It currently “only supports Ethereum, Binance Smart Chain and Base,” and it is honest about the limit: “Just because it’s not a honeypot now, does not mean it won’t change!”

GoPlus reads the contract and returns flags for each risk above. Its is_honeypot field means the token “maybe cannot be sold because of the token contract’s function,” and it returns nothing when the source is closed. It also reports honeypot_with_same_creator, “the number of honeypot tokens created by this creator.”

Why a clean result is not a clean token:

• Results go stale. Dedaub: “Deployers can flip a contract between safe and malicious by toggling trading, editing a blacklist, or raising the sell tax after launch.” Its advice: “re-scan immediately before any trade rather than trusting an older result.”
• Traps can wait. The Trapdoor study found some tokens “let users exchange back and forth freely at the beginning to attract more users before suspending trading.” Webacy notes others “start with low fees that increase over time.”
• Detection is incomplete. On the Trapdoor study’s dataset of tokens, “GoPlus can only successfully detect 60%.” Simulation has its own blind spot: “if the tool cannot simulate a buy, it cannot detect if a given token is a scam.”
• Coverage is not universal. Robinhood Chain (chain ID 4663) is not among honeypot.is’s supported chains, and its chain ID does not appear in the chain list of GoPlus’s token-security API documentation. On Robinhood Chain, the manual checks below are the check.
• Closed source is the loudest warning. GoPlus: “Closed-sourced contracts may hide various unknown mechanisms and are extremely risky.” A scanner that cannot read the code cannot clear it.

Checks you can run yourself

On Etherscan, BaseScan, BscScan, or Robinhood Chain’s Blockscout and RobinScan:

1. Search by contract address, never by name. SlowMist: “Always search by the contract address, not the token name, to avoid counterfeit projects.” Copies of popular names are cheap.
2. Confirm the source is verified, and remember what that means. Etherscan: “’Verified’ does not mean the contract is safe to interact with or that it has been audited.” It means you can read it.
3. Read the transfer logic. Open the code and find the transfer function (_update, _transfer). Look for conditions on sells into the pair, tax variables the owner can change, lists of addresses, pause flags, and calls to other contracts. Etherscan suggests using “your preferred LLM or Etherscan’s Code Reader to review the source code.”
4. Use Read Contract. It is free and needs no wallet: check owner(), the current taxes and limits, and whether trading is enabled. If the page shows Read as Proxy, the logic lives at an implementation address that can be swapped; find out who controls the upgrade.
5. Look for real sellers. Open the token’s transfers into the pool address. Webacy: “Look for successful sells by other wallets.” A token with hundreds of buyers and sells only from the deployer is the classic pattern.
6. Check holders and the creator. How much does the owner hold? Has the deployer launched tokens before, and what happened to them?
7. Check the explorer’s reputation label. A token marked Suspicious or Unsafe has been reported or appears in a public scam database; “An OK reputation is not an endorsement.”
8. Test small, then think. Webacy suggests trying “selling a tiny amount before investing more.” A successful test sell proves the trap is not on right now, for that size. It does not prove it will stay off.

Two rules for after the fact. First, as Dedaub puts it, “you cannot tell from price, volume, or a green chart” whether a token is a honeypot; CertiK specifically warns about tokens with “an all green chart.” Second, Dedaub’s rule if your tokens are stuck: “never send more to unlock a stuck balance, as that is a second scam.”

How common are they

The short lifetimes are the point. A honeypot does not need to last; it needs one afternoon of buyers.

Checklist before you buy a new token