Scam entry · Scam round-up · Honeypot tokens

Honeypot tokens: you can buy in, you just can’t sell

The Chinese name for these is 貔貅盤, after a mythical beast that swallows everything and never lets anything out. It fits. You buy in, the balance shows up in your wallet, and the sell transaction never goes through. The chart looks relentlessly strong — not because the token is, but because nobody can sell, so there is no sell pressure. This page does not teach you Solidity. It covers the ways a contract can switch selling off, why “I checked and it was fine” has a very short shelf life, and four checks that cost nothing and need no wallet connection.

Honeypot token entry cover: buy in, never out
Chain Scam Index · honeypot token specimen

Separate two things first, because they call for completely different responses. A token going down and a token you cannot sell are not the same problem. In the first, you are losing money but the asset is still yours to act on. In the second, the asset is locked inside a contract someone else wrote, and how much it is nominally worth stops mattering, because that number cannot be realised.

It isn’t a price drop — the sell button simply does nothing

The experience usually runs like this. You buy an unfamiliar token on a decentralised exchange; the purchase goes through smoothly and the balance appears. The price climbs, you decide to take profit, you hit sell — and the transaction fails. You try another interface, raise the slippage, push the gas up. Still fails.

Most people’s first thought is that they are doing it wrong, so they spend the next hour studying the interface. The answer is somewhere else entirely: the token contract says your address may not move these tokens out. Your wallet is fine, the network is fine, slippage is not the problem. The rule itself forbids it.

A counter-intuitive but easily remembered test: a chart that only goes up is not strength, it is a warning. Real markets always contain someone taking profit and someone cutting a loss, which shows up as pullbacks. A line that climbs with almost no retracement has one very plain explanation available — nobody is getting out.

The ways a contract can switch selling off

You do not need to read the code, but knowing the shapes tells you what to go and look for. The common ones:

  • A whitelist. The contract keeps a list of addresses permitted to transfer out. If you are not on it, your sell never becomes a valid transaction. That list is normally controlled by the deployer and not published.
  • A trading switch. The contract keeps a switch the owner controls. Flip it off and nobody can transfer out; who gets let through, and when, is their call.
  • A blacklist. The inverse: selling works for everyone until the owner adds specific addresses to a blacklist, after which those addresses are stuck. This one is particularly nasty, because other people are visibly selling and only you cannot.
  • A sell tax raised to an extreme. Technically the sale completes, but the proportion taken on the way out approaches everything, which amounts to the same result. And the rate is often something the owner can change afterwards.

Line them up and the shared ingredient is obvious: every one of them depends on the contract’s controls still being in someone’s hands. So the question worth asking is not “is there something wrong with this contract right now” but “can they still change it later”.

The hardest one: sellable now, not sellable later

If honeypots only came in the shapes above, defending against them would be simple enough: simulate a sale before buying. What makes it genuinely difficult is the delayed variety — a contract that behaves perfectly at first and only switches selling off once some condition is met.

The condition can be block height. The technical breakdown published by Chainfeeds via Anue describes the pattern as a check such as require(block.number < _allowance) placed in the transfer path: while the chain has not reached that threshold everything works, and once it does, transfers out stop being valid. Transaction count works the same way — the contract turns after enough trades have accumulated.

The same breakdown is blunt about why this is hard to catch: when a contract like this is examined by security tooling that has no detection logic aimed at it, it trades normally in its initial state. In other words, the design targets the habit of checking before buying.

Which is why “I checked and it was fine” expires almost immediately. It establishes that selling worked at the moment you looked, not that it will work at the moment you want out. This is the same point this site keeps returning to elsewhere: a check confirms a present state, never the other side’s future behaviour.

Four checks that cost nothing and need no wallet

All four happen in a block explorer — no wallet connection, no gas. The order matters: the second is the strongest, and in most cases it settles the question on its own. There is an earlier step than any of this: making sure the contract you are buying is the right one at all — where to copy a contract address from is covered separately.

  1. Is the contract verified? Open the token’s contract address in an explorer and see whether the source is published. Skip anything unverified — not because unverified always means fraud, but because you have no way to check at all, and there is no reason to bet your own money on that. The reverse does not hold: verified is not safe. The block-height trick above can sit openly in published source, and you will not see that line unless you read the whole thing.
  2. Read the transfer history for a successful sale by an ordinary address. This is the most useful thing on the page and it needs no programming at all. Open the token’s transfers and look at the balance of buys against sells. If it is nearly all buys, with sales sparse or absent, that is your answer. Then push one step further: are the few sales all coming from the same handful of addresses — most likely the deployer and their whitelist? A healthy token has all sorts of unrelated addresses selling.
  3. Check whether the deployer still holds the controls. Does the contract have an owner; can that owner change the tax, add a blacklist, flip a trading switch? These are normally readable on the explorer’s contract page. While those powers exist, every other check you ran is a statement about the present only.
  4. Verify the contract address itself. Copycats reuse a well-known project’s name and logo and deploy a same-named token, so what you see in an interface is identical. The address is the only thing that separates them, and you should get it from a source you trust rather than copying it from a link or screenshot someone sent you.
How this page was checked

The contract-level parts of this entry — whitelist, trading switch, blacklist and sell tax as the four ways out are closed, and block height or transaction count as the trigger for the delayed variety — were checked against the Chainfeeds/Anue technical breakdown and the Beosin analysis republished with permission by BlockTempo, on 2026-09-03. The desk has not bought a honeypot token to test this and will not; nothing here is written from hands-on trading.

One thing the checking made clear is worth stating on its own. Most published analysis of this scam puts the weight on whether the contract is verified. That test is useful and it does not stop the delayed variety, which can be verified source. The test that neither requires you to read code nor collapses against a delay is the second one above: don’t read what the contract says, look at whether anyone is actually getting out. Behaviour beats claims — the same yardstick this site applies in its other entries.

What a honeypot checker can and cannot tell you

Some tools will simulate a buy followed by a sell and report whether the token can be sold. They are useful, but you need their boundaries, because otherwise they are worse than nothing — they hand you a feeling of having checked.

  • They test the present. A successful simulation means it sells right now. A delayed honeypot, or an owner who raises the tax or blacklists you afterwards, is outside what a simulation can see.
  • They are not official and this site does not endorse any of them. Whether to trust a given tool is your call. Well-known tools get cloned too, so confirm the address yourself rather than following an unknown link — the look-alike domain checker is there for exactly that.
  • They cannot tell you it is not the token you think it is. A same-named copy is separated by contract address, not by simulation result.

Treat it as a magnifying glass, not a safe — the same thing we say about third-party revoke tools in the approval checkup and revoke guide.

Why people buy more after they notice

This section is not about technology, and it decides more outcomes than the technology does.

The Beosin analysis republished by BlockTempo records a scene: while the security team was examining a suspected fraudulent token impersonating a well-known project, they watched a user already holding it buy more, because the price looked strong. One analyst said “I think he’s going to buy again” — and before the sentence was finished, he did. That write-up (a case from May 2023) also notes that the contract’s whitelist state was not public and that both the switch and the list were controlled by the owner, so an ordinary participant could not sell by default.

Keep that scene, because it explains where the real damage comes from. It is not the contract. It is that every signal the scheme puts in front of you argues for buying more: the price rises, others are buying, the chat is busy. By the time you find you cannot sell, you are no longer judging — you are looking for explanations. I must have done it wrong. Maybe it clears in a bit. Maybe buy a little more to average down.

The moment you find you cannot sell, the move is to stop, not to add.

If you are currently talking yourself into buying more, leave the money where it is and go do check two: read the history, and see whether any ordinary address unrelated to you has managed to sell. It costs nothing and you do not have to ask anyone.

Frequently asked questions

I ran it through a honeypot checker before buying and it came back fine. Why can't I sell?

Because that kind of tool answers “can this be sold right now”, not “can this be sold later”. The delayed variety is built specifically to walk past that check: the contract behaves normally at first, and selling is only switched off once the chain passes a certain block height, or once the transaction count crosses a threshold. A tool running early sees a healthy token, because at that moment it is one. The same goes for an owner who raises the sell tax or adds your address to a blacklist after you checked. A clean result means the moment you checked was fine — not that your money is safe.

The contract is verified and I can read the source on the explorer. Doesn't that make it safe?

No. Verified means you can see it, not that you understood it, and certainly not that there is nothing wrong in it. The block-height restriction behind a delayed honeypot can sit in plain sight in published source — you simply will not notice that line unless you read the contract line by line. Open source is a necessary condition, not a sufficient one: skip anything unverified outright, and for the rest, still go and check whether anyone is actually managing to sell.

The price keeps climbing and there is plenty of activity. Can it still be a honeypot?

Yes, and that is exactly the picture it wants to show you. A token that can be bought but not sold has no sell pressure, so of course the line only goes up. As for the activity, whoever set it up can trade between their own whitelisted addresses and spread the token across many wallets to manufacture the look of a crowd. Neither the chart nor the volume is evidence. The only thing that is: whether ordinary addresses have actually completed sales.

I already bought in. Is there any way to get the money back?

Usually not. The tokens are still in your wallet and the balance is right there, but the sell action is blocked by the contract, and nothing on-chain can override that for you. Occasionally the operator opens the gate for a while — typically to keep buyers arriving — and sales go through during that window, but that is their decision, not something you control. Which is why the effort belongs before the purchase, not after it.

So what actually keeps me safe here?

The honest answer is that there is no amount of checking that makes this category safe. What you can do is lower the exposure: skip unverified contracts, read the transfer history for ordinary addresses that sold successfully, look at whether the deployer still holds the switches, and treat whatever you put in as money that can go to zero. And if you catch yourself saying “I'll buy a bit more to average down”, that is no longer a judgement call — it is the same move the victim in the case above made.

2026-09-03 · Entry created. Contract mechanisms and the case detail checked against the Chainfeeds/Anue breakdown and the Beosin analysis republished by BlockTempo.