Honeypot Crypto: What Blocks the Sell, and How to Find It First
A honeypot crypto token is built so that buying works and selling does not. You swap in, the pool takes your ETH, the balance appears in your wallet, and then the exit fails. The transfer reverts, or it goes through at a tax that leaves you with almost nothing. The chart still looks alive because other people are still buying.
That asymmetry is the entire trick. A token that blocked buys would be obvious within seconds. A token that blocks sells can run for hours or days, because every buyer only discovers the problem at the moment they try to leave.
This piece covers the mechanisms that create the block, how a sell simulation from a real holder detects it, why a passing simulation is not a guarantee, and how to check the contract yourself before you size a position.
What a honeypot token actually does
Two shapes, one outcome.
Hard block. The token contract rejects the transfer to the pool. Your wallet shows a failed transaction, you pay gas, and the tokens stay put. On most chains this is a revert, which is easy to spot once you know to look.
Soft block. The transfer succeeds but the economics are destroyed. A sell fee set high enough that exiting is pointless, or a fee that only applies when the destination is a pool. The transaction confirms, and you are still stuck.
Some of these are not malicious at launch. A project can ship a fee setter, a trading switch or an upgradeable proxy for legitimate reasons, and then the owner key changes hands, or the team simply decides to use it. The code that lets a team pause trading is the same code that lets a team block your sell. You are not judging intent. You are judging what is reachable.
The mechanisms that block a sell
Blacklists and transfer gates
A mapping of blocked addresses, checked inside the transfer function. Once your address is on it, every transfer out fails. The function that adds an address is usually called something like blacklist, blocklist or setBlocked, and it is usually owner-only.
Fee setters and the trading switch
A fee setter lets the owner change buy and sell tax after launch. A trading switch (often enableTrading, or a boolean tied to the pair) lets the owner turn transfers on and off. Both can be set to values that make selling impossible or pointless. If the owner can change fees, the fee you see at scan time is not the fee you will get at exit time.
Upgradeable logic
An EIP-1967 proxy, a beacon proxy or an EIP-1167 minimal proxy means the contract you are reading is a shell. The logic lives elsewhere and can be replaced. A scan that only reads the proxy will look clean while the implementation does whatever the owner wants. This is why the proxy pattern has to be identified first, before any other finding means anything.
Who holds the privileged roles
Owner, treasury, guardian, minter. Each one is either a plain wallet, a Safe, a timelock or another contract. A Safe sounds reassuring until you read getThreshold() and getOwners() and find a 1-of-1: one owner, one signature required. That is a single key wearing a multisig costume. There is a fuller breakdown of that pattern in the 1-of-1 Safe explainer. A timelock is different, because changes are queued and visible before they take effect.
Dangerous functions in the bytecode
Even without verified source, the function selectors for mint, blacklist, pause, fee setters, trading switch, upgrade and rescue can be spotted in the bytecode. Presence is not proof of intent. Absence is a meaningful signal, because you cannot call a function that is not there.
How a sell simulation from a real holder works
This is the part most checkers get right and most traders never inspect.
The idea: instead of guessing what the transfer function does, you ask the chain to execute it. You take an address that actually holds the token, build a transfer of that holder's tokens into a real pool, and run it as an eth_call. An eth_call executes against current state and returns the result without changing anything and without costing gas.
If the call reverts, the sell path is blocked right now, for that holder, into that pool. That is a strong honeypot signal. It is not a theory about what the code might do. It is the code refusing to move tokens.
If the call succeeds, the sell path works at that moment. That is genuinely useful information, and it is far better than reading source code and hoping.
Why a passing simulation is not a guarantee
A passing honeypot crypto check is a snapshot, not a promise. Several things can change after it.
The contract can be upgraded. If the logic sits behind a proxy, the implementation can be swapped and the transfer function replaced.
The owner can change fees or flip the trading switch. A sell that costs nothing today can cost everything tomorrow.
The simulation used one holder and one pool. A token with multiple pools can behave differently across them, and a holder with a special exemption (a whitelist address, a market maker) will pass where an ordinary wallet fails. Simulating from a real, ordinary holder is what matters.
Liquidity can leave. A working sell path into a pool with no ETH in it is not an exit. That is a different failure and it belongs in the real float discussion, not the honeypot one, but it hurts the same way.
Treat a pass as "this is not blocked right now", not as "this is fine".
How to check a honeypot crypto token by hand
You can do a meaningful version of this yourself with a block explorer and an RPC endpoint.
- Read the contract. Open the token on the explorer and look for the proxy pattern first. On an EIP-1967 proxy, the implementation address sits in a known storage slot. If the explorer labels it as a proxy, read the implementation, not the shell.
- Read the privileged roles. Call
owner()and check whether the returned address is a wallet or a contract. If it is a contract, callgetOwners()andgetThreshold()on it. A threshold of 1 with one owner is a single key. - Read
totalSupply(). Data sites often show max supply, which is not the same number as what has actually been minted. - Look for the dangerous selectors. In verified source, search for mint, blacklist, pause, setFee, enableTrading, upgradeTo. In unverified bytecode, compare the function selectors against those signatures.
- Run the sell path. Build an
eth_callthat transfers tokens from a real holder to the pool. If it reverts, stop.
Step 5 needs an RPC endpoint. On Robinhood Chain the public endpoint at https://rpc.mainnet.chain.robinhood.com works but is rate-limited, and Robinhood's own docs say it is not for production. A second public endpoint exists at robinhood-rpc.publicnode.com, and the docs recommend Alchemy, Chainstack, QuickNode, Blockdaemon, dRPC, Validation Cloud and GlobalStake. The endpoint trade-offs are covered in the Robinhood Chain RPC guide.
Doing this by hand takes a block explorer tab, a read-contract tab and a script for the simulation. It is worth knowing how. It is not worth doing for every token you glance at.
How SellTape does it in one message
SellTape is read-only on-chain analysis delivered in Telegram. No wallet connection, no signing, no deposits, and it never asks for keys.
The contract scan section does the work above in a single pass: upgradeable proxies (EIP-1967, beacon, EIP-1167 minimal proxy); owner and other privileged roles (owner, treasury, guardian, minter) and whether each is a plain wallet, a Safe with its threshold, a timelock or a contract; dangerous functions present in the bytecode; a simulation of whether the owner can change fees; and a sell simulation from a real holder, where a revert is a honeypot signal.
Then it goes further than the sell check. The holder map labels the top holders as pool, staking vault, burn, Safe, contract or wallet, and separates staking and pool supply from the real float. The third section shows who is actually selling over the last 24 hours across all pools of the token, split into protocol mint-and-sell, treasury-directed selling, unstakers, ordinary holders, wallets not checked for bot behaviour, and arbitrage bots, which are not dumping. That last distinction matters more than people assume, and it is explained in the piece on why arbitrage bots are not dumping.
Every report carries a risk grade of LOW, ELEVATED, HIGH, CRITICAL or INCOMPLETE, plus the block number, UTC time and caveats. Missing data produces INCOMPLETE, never a low grade. You can see the format on the sample tape, and plans run from Free (3 scans a day) through the Trader, Pro and Group tiers on the pricing page.
Other checkers, and what each one covers
As of September 2026, several tools cover parts of this. None of them splits sell flow by source.
| Tool | What it does | Chains (as of Sept 2026) | Sell flow by source |
|---|---|---|---|
| SellTape | Contract scan, holder map, sell-by-source over 24h | Robinhood Chain, Ethereum (Base, Arbitrum, BSC, Berachain coming) | Yes |
| Honeypot.is | Honeypot and tax simulation | Ethereum, BSC, Base | No |
| Token Sniffer | Automated token audit scores | EVM tokens | No |
| GoPlus | Token security API (mintable, owner, honeypot-style flags) | Multi-chain | No |
| Bubblemaps | Holder-cluster maps | Includes Robinhood Chain | No |
| DexScreener | Charts, pairs and trading data | Many chains | No |
The practical read for any honeypot crypto check: use a honeypot simulation to catch the obvious block, use a holder map to see who controls supply, and use a sell-by-source breakdown to see who is actually pressing the button. A side-by-side of Token Sniffer, Bubblemaps and DexScreener covers where each one stops.
What else to check before you size a position
A clean sell simulation answers one question about a honeypot crypto token. These answer the ones next to it.
Unlocks and unstaking. Tokens leaving a vesting contract or a staking vault arrive on a schedule, and when they arrive they can be sold. That flow is often visible in advance if you look for it. See token unlocks and unstaking.
Real float. Supply sitting in staking vaults, pools, burn addresses and treasury Safes is not freely trading. A quoted market cap can badly overstate what can actually be sold.
Mint and sell. A project contract that receives newly minted tokens from the zero address and sells them into a pool is diluting holders, even when it is by design and even when the token is not a honeypot.
Owner reachability. If the owner can change fees, pause transfers or upgrade logic, the token is only as sound as that key. A timelock buys you time to react. A 1-of-1 Safe does not.
Key takeaways
- A honeypot crypto token blocks the sell, not the buy. Hard blocks revert; soft blocks make the exit economically pointless.
- The mechanisms to look for are blacklists, fee setters, trading switches, pause functions, mint functions and upgradeable proxies.
- A sell simulation from a real holder is the strongest single check, because it executes the transfer instead of reading about it.
- A passing simulation is a snapshot. Upgrades, fee changes and liquidity removal can invalidate it later.
- Check who holds the privileged roles and what shape they are. A 1-of-1 Safe is one key.
- SellTape runs the contract scan, the holder map and the 24h sell-by-source breakdown in one Telegram message, and returns INCOMPLETE rather than a low grade when data is missing.
Scan a token free in Telegram at t.me/SellTapeBot.
SellTape is an information service, not financial advice.