The buy went through. The sell keeps failing. If that’s you, the token is almost certainly a honeypot — and the hard truth is the funds are usually stuck. Here’s exactly what happened, what you can (and can’t) do, and how to never hit it again.
The contract is written to allow buys but block or heavily tax sells. The liquidity, the holder count, the chart — all of it can look real, because the trap lives in the transfer logic, not the metadata. When you sell, the transaction reverts or returns dust. It targets exactly the behaviour that makes new launches exciting: buying before reading the contract.
Honeypots come in degrees: a full block (no sell ever works); a punitive sell tax (you can sell, but lose most of it); a max-tx / anti-whale trap (small sells pass, larger ones revert — so a quick test looks safe); and a latent trap, where an owner can blacklist your address or halt trading after you buy. The last two are why a single small test trade isn’t enough.
If the sell is blocked at the contract level, nothing off-chain can force it — not a different DEX, not a wallet setting, not a “recovery service.” Anyone asking for an upfront fee to un-trap your funds is running a second scam on top of the first. The honest answer is to treat it as a loss and make sure it can’t happen twice.
The only reliable defence is to simulate the sell before buying. true402 runs a real buy→sell round trip on Base inside one gas-free eth_call and tells you whether the token can actually be sold — at two sizes, so it catches the max-tx trap, and it flags an owner who can blacklist you later. ~$0.005 per check, no account, no API key.
# Check sellability BEFORE you buy. ~$0.005 USDC over x402, no account, no API key.
curl -s -X POST https://true402.dev/api/v1/base/token-report \
-H 'content-type: application/json' \
-d '{"token":"0x<token-address>"}'
# verdict: { "rating": "avoid", "reasons": ["honeypot: the sell side is blocked"] }If a trading bot is buying for you, wire the check in front of every buy — see rug-check a Base token from your AI agent (drop-in for ElizaOS, a custom guard, or the raw API). A bot that doesn’t check sellability will eventually buy a honeypot.
Because it is a honeypot. The token contract allows buys but blocks or punitively taxes sells inside its transfer logic. Everything else — liquidity, holders, the chart — can look normal; the trap is in code you do not see when you buy. When you try to sell, the transaction reverts or returns almost nothing. This is the most common scam on fast-moving chains like Base, Solana, and BSC, aimed at people who buy new launches before checking the contract.
Almost never. If the sell path is blocked at the contract level, no wallet, DEX, or "honeypot recovery" service can force the trade — the code simply refuses. The honest answer is that the funds are usually gone, and anyone promising recovery for an upfront fee is a second scam. The only reliable protection is to check whether a token can be sold before you buy it.
Simulate the round trip. A simulation buys the token and immediately sells it in a single eth_call with a state override — no gas, no on-chain footprint — and checks whether the tokens come back out. If the sell reverts, it is a honeypot. true402 exposes this as a pay-per-call check on Base (~$0.005 USDC, no account or API key) that returns an avoid|caution|ok verdict, and it also catches partial traps (sellable at a tiny size, blocked at a larger one) and latent ones (an owner who can blacklist you later).
That is a max-transaction or anti-whale honeypot: the contract permits tiny sells but reverts a larger one, so a quick test trade looks fine while real size gets trapped. A single-size check misses it. true402 probes at two sizes and flags sellable_small_only when the larger sell is blocked.