MEVDAO

Honeypot Tokens: How to Spot One Before You Buy

By Merunas Grincalaitis · · 6 min read · 0 views

A honeypot is a token you can buy but can't sell. The chart looks amazing because nobody can sell, so the price only goes up. You buy, you watch it pump, you try to take profit, and the transaction reverts. Or it goes through and you get back almost nothing because the "sell tax" was quietly set to 99%.

If you snipe or trade new launches, you'll run into these constantly. I want to explain how they work under the hood, because once you know the handful of tricks they use, most honeypots become easy to spot. Then I'll go through the exact checks I run, and where every one of them can still fail.

How a honeypot actually blocks you

Every ERC-20 transfer goes through the token's own transfer or transferFrom function. When you sell on Uniswap, the router calls transferFrom to move your tokens into the pair. The token developer writes that function, so they can put any rule they want in there.

Here are the patterns I see most often.

Sell-side blacklist. The contract keeps a mapping of blocked addresses, and the transfer reverts if the sender is on it. The owner adds buyers to it right after they buy, sometimes automatically for anyone who buys in the first blocks.

require(!isBlacklisted[from], "blocked");

Whitelist-only sells. The opposite. Only addresses the owner approved can send tokens to the pair. Everyone can buy, only the team can sell.

Adjustable tax with no cap. A setFees(buy, sell) function with no upper limit. At launch the sell tax is 5%, then the owner calls it with 99 and every sell pays 99% to the team wallet. Technically you can sell. Practically you can't.

Tiny max sell or max transaction. A maxSellAmount that the owner drops to something like 1 token. Your sell reverts unless you split it into thousands of transactions, and each one costs more gas than it's worth.

Trading pause. A global tradingEnabled flag that's checked on sells but not on buys, or on transfers to the pair only.

Balance tricks. The balanceOf function returns a number that isn't your real balance, or a hidden fee is taken from your balance on every transfer. Your wallet shows tokens you can never move.

Upgradeable proxy. The token is fine today, but it sits behind a proxy, and the owner can swap in a malicious implementation tomorrow. Nothing in the current code looks bad.

Fake renounce. The owner() function returns the zero address, so scanners report "ownership renounced", but the real control sits in another variable, like a _dev or _marketing address that has its own privileged functions.

Notice the theme: most of these aren't honeypots at deployment. They're switches. The contract is sellable while people are checking it and becomes a trap once the money is in.

The checks I run before buying

1. Simulate a buy and a sell

This is the first thing, and it's the only one that tests real behaviour instead of reading code. Tools like Honeypot.is do exactly this. They simulate a buy and then a sell against the current state of the chain, and report the buy tax, sell tax, transfer tax, any max buy or max sell, and the gas used. The Honeypot.is API docs list these fields if you want to call it from your own bot.

Dedaub has a similar honeypot checker, and there are others, like GoPlus's token security API.

What to look for:

  • Sell simulation failing outright: walk away.
  • Sell tax far above buy tax: walk away.
  • Gas for the sell way higher than for the buy: something heavy runs on sells. Find out what.
  • Max sell much smaller than max buy.

But keep this in mind. Honeypot.is says it on its own site: just because a token isn't a honeypot now doesn't mean it won't change. A simulation tests the current state. It doesn't tell you what the owner can do in the next block.

2. Read the owner powers, not just the code

If the source is verified on Etherscan, open the "Write Contract" tab. That shows every function you can call, and the ones guarded by onlyOwner (or any custom modifier) are the owner's powers. I'm looking for:

  • Anything that writes to a blacklist or whitelist
  • Fee setters, and whether they have a hard cap like require(fee <= 10)
  • Max transaction / max wallet setters, and whether they can go down
  • Pause or tradingEnabled toggles that can be turned off again
  • Functions that can move or burn other people's balances
  • upgradeTo, or anything that changes an implementation address

If the source isn't verified, that's a decision by itself. On a fresh token, unverified code means I don't buy.

3. Check whether it's a proxy

An upgradeable token can turn into anything. Etherscan detects most proxies and shows a "Read as Proxy" tab. You can also read the standard EIP-1967 implementation slot yourself:

cast storage 0xToken 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc --rpc-url $RPC

A non-zero value there is the implementation address. If an EOA controls the upgrade, the whole token is basically a promise.

4. Look at who has managed to sell

Open the token's transfers or the pair's swaps on a block explorer. Are there sells from normal wallets, not just from the deployer or a couple of team-looking addresses? If you see lots of buys and only one or two sellers, that's the classic honeypot chart.

5. Check liquidity and the deployer

This isn't strictly about honeypots, but it's the same goal: getting your money back. Is the LP locked or burned? Did the deployer launch other tokens recently, and what happened to them? A deployer with a string of dead tokens has a pattern.

Where the tools fail

I want to be honest about this, because a lot of people treat a green checkmark as a guarantee.

  • Switchable honeypots. The token is sellable during the check and the owner flips it after enough people buy. There's a good discussion of this on Ethereum Stack Exchange, and some open-source sniper repos, like lqsniper, mention switchable honeypots specifically as a problem.
  • Targeted blocks. The contract lets the simulator's address sell, or lets small amounts sell, but blocks real buyers or large amounts. A simulation from one address with one size can miss that.
  • Time or block based logic. Sells work for the first N blocks, or only after N blocks. A check at the wrong moment misses it.
  • External calls. The token calls another contract on every transfer to decide whether to allow it. The real logic sits in a contract the owner can change at any time.

So I treat the checks as a filter, not a guarantee. They catch the lazy honeypots, which is most of them. The clever ones you defend against with position sizing and speed.

If you snipe: test inside the bundle

When you're sniping a launch in the same block as liquidity is added, you don't have time to run a website check. You do it in code.

The approach I use is to simulate the whole thing before sending it. Take the add-liquidity transaction, your buy, and a test sell of a tiny amount of what you'd receive, and simulate them in order. With Flashbots you can do that with eth_callBundle against the next block. If the test sell reverts or returns way less than expected, you don't send the real bundle. I go through simulation and the other bundle methods in Flashbots bundles explained.

This still doesn't protect you from a switch that's flipped later, but it kills the "honeypot from block one" case completely, and that's the most common one at launch.

What I do if I'm already in one

Short answer: usually nothing works. Some quick things to check before you give up:

  • Is it a max-sell limit? Then you might get out by selling smaller amounts, if gas allows.
  • Is it a sell tax that the owner might lower again? Sometimes they lower it to lure in a second wave.
  • Is your address blacklisted, or is everyone blocked? If only you are blocked, you can't fix that by sending tokens to a new wallet, because the transfer out is what reverts.

Don't pay "unlock fees" to anyone who DMs you claiming they can get your tokens out. That's another scam aimed at people who just got scammed.

The short version

  1. Simulate buy and sell, and compare taxes and gas.
  2. Read the owner-only functions: blacklists, fee setters without caps, pausable trading.
  3. Check for a proxy.
  4. Look for real sellers.
  5. Size every new-token position as if it could go to zero, because some of them will.

If you'd rather not do all of this alone, the MEVDAO Premium Sniping Group is where we snipe proven tokens together, and the Sniper Bot is part of the same subscription. There's a 3-day trial if you want to try it first.

← All articles