What is a honeypot token and how to detect one

A honeypot is a token you can buy and cannot sell. The contract accepts incoming trades normally and blocks outgoing ones — through sell-blocking logic, a tax the owner can raise to near 100%, an address blacklist, or a transfer restriction that only applies to people who are not the deployer. Simulators catch most of them. Not all.

How the block is actually implemented

There are four common mechanisms, and they fail differently, which matters because the tools that catch one are blind to another.

Hard sell-blocking. The transfer function contains a condition that reverts when the recipient is a liquidity pool, or when the sender is not on an allow-list. Your buy goes through because the pool is the sender; your sell reverts because the pool is the recipient. This is the crudest form and the one every simulator catches.

Dynamic tax. The contract has a setSellTax, setFee or equivalent setter with no hard cap in the code. At the moment you buy, sell tax is 0%. After the deployer has enough buyers, it becomes 99%. Your sell does not fail — it succeeds and returns almost nothing. This is a soft honeypot, and a simulator that only asks "does the sell transaction revert" will pass it.

Blacklist and pause. A mapping of blocked addresses, plus an owner-only function to add to it. You are not blocked when you buy. You are blocked when the deployer decides to be, which is usually after the buy that would have hurt them. A pause() modifier does the same thing wholesale.

Transfer restrictions and cooldowns. Maximum transaction size, maximum wallet size, one-transaction-per-block limits, or a hold period enforced in code. Individually these have legitimate anti-bot uses. In combination with a mutable owner setting, they are a throttle the deployer controls.

On Solana the picture is different, because the token program handles transfers rather than the token's own code. The equivalent risk is freeze authority: an unrevoked freeze authority lets whoever holds it freeze a specific token account, which stops that holder transferring or selling while everyone else trades normally. It is not a honeypot in the Solidity sense, and it produces the same outcome for you. Solana's mint and freeze authority covers how to read both.

How to check before you buy

Run these in order. The first two take seconds; the third is the one that catches what the others miss.

1. Run a simulation. A honeypot simulator executes a buy and a sell against the live contract state in a forked environment and reports whether the sell succeeds and what tax it pays. honeypot.is, TokenSniffer and ApeSpace all do this for EVM tokens. GoPlus exposes the same class of checks — honeypot behaviour, buy and sell taxes, mint capability, owner privileges — as a multi-chain API, which is why it appears inside other products rather than as a destination you visit. On Solana, RugCheck is the standard first check. How RugCheck, TokenSniffer and GoPlus actually differ sets out what each one covers.

Read the tax numbers, not just the pass/fail. A token with a 12% sell tax is not a honeypot and is still a bad trade if you did not know about it.

2. Read the contract for the setters. A simulation reports the current state. The contract tells you who can change it. Open the verified source on the explorer and search for functions that can alter transfer behaviour: anything named setTax, setFee, setMaxTx, blacklist, setTrading, pause, or an onlyOwner modifier attached to something that touches _transfer. Then check whether ownership is renounced and to what. Reading a token contract yourself walks through this without assuming you write Solidity.

3. Check whether anyone has actually sold. This is the check that beats simulators, and almost nobody does it. Open the pool's transaction list on the explorer or a screener and look for completed sells by wallets that are not the deployer and not the deployer's funding source. A token where hundreds of independent addresses have sold at normal tax is very hard to make a honeypot argument about. A token with a hundred buys and zero third-party sells is telling you something regardless of what any tool reports.

4. Test with an amount you will not miss. If you are going to buy anyway, buy a token dust amount and sell it immediately, before sizing up. This is real evidence rather than a simulation — and it is evidence about this second only, which is the whole problem with the method.

What these checks do not catch

Every technique above reads the contract as it exists now. The interesting attacks are about later.

Time-delayed restrictions. A contract can enable a sell block after a fixed number of blocks, after a timestamp, or after the pool reaches a size. Every simulator run before that point returns clean, correctly, because at that point the token is not a honeypot.

Owner-triggered restrictions. More common than the timed version and harder to argue with. Nothing in the deployed code is malicious until someone sends a transaction. A scanner cannot report on a transaction that has not been sent. What it can report is that the capability exists — which is why the setter check above matters more than the simulation result.

Proxy upgrades. If the token sits behind a proxy, the code you simulated is not necessarily the code that runs tomorrow. The admin can point the proxy at a new implementation. Check for a proxy pattern and who holds the admin role before you treat any scan as durable.

Simulation evasion. Simulators execute from a known set of conditions. A contract can behave differently depending on the caller, the gas, the block, or whether the transaction is part of a bundle. This is an arms race, and the tools are usually ahead — but "usually ahead" is not "reliable", and a novel evasion is invisible by definition until someone gets caught by it.

Everything that is not a honeypot. A clean honeypot check says nothing about supply concentration, the deployer's holdings, or whether the token is worth anything. Most losses in this category are not honeypots at all. Where automated safety scoring stops covers the wider limits.

And the reverse error is worth naming: a failed sell is not proof of a honeypot. Sells fail for slippage set too low, for insufficient gas or priority fee, for a pool that moved between quote and execution, and for chain-level reasons that have nothing to do with the token. Failed sells during volatility are the most common user complaint about fomo, which overtook Axiom as Solana's leading trading terminal by volume around 6 August 2026 — that is a routing and volatility problem, not a contract one. Why sells fail, and what to do about it separates the causes. Diagnose before you conclude.

Frequently asked questions

How can I tell if a token is a honeypot before buying?

Run a simulator such as honeypot.is, TokenSniffer or ApeSpace on EVM chains, or RugCheck on Solana, then read the contract for owner-controlled tax, blacklist and pause functions, then check the pool's history for completed sells by wallets unrelated to the deployer. The third check is the strongest and the least used.

I bought a token and cannot sell it — is it a honeypot?

Not necessarily. Raise slippage, check you have enough gas or priority fee for the chain, and try a smaller amount. If a sell reverts consistently across sizes and slippage settings while other wallets are selling successfully, that points at your address specifically, which suggests a blacklist rather than a blanket block.

Do honeypots exist on Solana?

Yes, in a different form. Solana tokens do not carry their own transfer logic, so the classic Solidity sell-block does not apply. An unrevoked freeze authority achieves the same result by freezing a specific token account, and it can be exercised at any time until it is revoked. Check authority status before buying, not after.

Can a token become a honeypot after it launches clean?

Yes, and this is the main limitation of every detection tool. If the owner retains a tax setter, a blacklist function, or proxy admin rights, the token can be made unsellable later without any change visible in an earlier scan. Check what the owner can still do, not only what the contract currently does.

Is a high sell tax the same as a honeypot?

Mechanically no, practically often yes. A 90% sell tax lets the transaction succeed and takes nearly everything. Some tools report it as a tax rather than a honeypot flag, so read the reported tax figures rather than the headline verdict, and treat any uncapped, owner-adjustable tax as an open-ended risk.

---

The one thing a buyer can verify without trusting you

Everything above is a buyer trying to establish, from the outside, what a deployer can still do. If you are launching, the fastest way to shorten that list is to remove your own optionality. Locking your LP through Team Finance — built by TrustSwap, which also builds Meme Central — fixes LP tokens for a set term on Ethereum, Robinhood Chain, Polygon, Base and BNB, and shows as a verified badge on your token's page in the cross-chain feed of new launches on Meme Central. It does not address honeypot logic in the token contract at all, and it is not a substitute for renouncing the setters described above.

---

Nothing here is financial, legal or tax advice. Memecoins are extremely high-risk: most lose most of their value, and the majority of tokens launched never reach a decentralised exchange at all. Never spend money you cannot afford to lose entirely. Meme Central does not recommend any specific token. Data described as Meme Central's own reflects tokens indexed by Meme Central and is not whole-market data.