A honeypot token lets you buy but not sell. The contract looks clean — liquidity, owner, supply all normal — and the trap sits in the transfer logic. The only way to know is to actually try the trade. Here’s how an on-chain simulation does that safely.
A honeypot’s danger is exactly what a structural check can’t see: ownership, mint capability, and liquidity depth can all look fine while the sell path reverts or taxes you to zero. The trap is in the transfer code, not the metadata — so a token that scores well on every static signal can still take your money and never give it back.
Static scanners pattern-match the contract source or bytecode against known-bad signatures. That catches lazy copies, but a purpose-built honeypot hides the block behind conditionals, proxies, or obfuscated transfer hooks. The scanner reports “looks fine”; the sell still reverts. You cannot prove a token is sellable by reading it — only by selling it.
true402 runs the actual trade without spending gas or touching the chain: a single eth_call with a state override injects a tiny simulator at a throwaway address, funds it, and executes wrap ETH → buy → sell through the token’s deepest Base pool (Uniswap V3 / Aerodrome) in one EVM execution. It measures the token and WETH deltas and the per-leg revert flags. If the sell reverts or returns nothing, it’s a honeypot — proven, not guessed.
# Prove a Base token is sellable before you buy. ~$0.005 USDC over x402, no API key.
curl -s -X POST https://true402.dev/api/v1/token-safety \
-H 'content-type: application/json' \
-d '{"token":"0x<token-address>"}'
# 200 → the honeypot block of the safety report:
"honeypot": {
"simulated": true,
"sellable": false, // bought fine, sell reverted → honeypot
"roundTripBps": null,
"flags": ["honeypot"]
}The subtler honeypot lets a tiny sell through but reverts a larger one — a max-tx / anti-whale limit. A single small test clears it, so most checkers miss it. true402 probes at two sizes — a small probe and a larger “whale” probe — and flags sellable_small_only when the bigger sell is blocked, so size buyers aren’t lured in by a check that only tried pocket change.
Pay-per-call over x402, no account or API key. See rug-check a Base token from your agent for the drop-in (ElizaOS plugin, the rug-guard, or the raw API), and the full composite verdict at the catalog.
A honeypot is a token you can buy but cannot sell — or can only sell at a punitive tax. The contract looks normal: it has liquidity, an owner, a name. The trap is in the transfer logic, which blocks or taxes the sell path while leaving buys open. By the time a trader notices, their funds are stuck. Honeypots are common on fast-moving chains like Base, Solana, and BSC where traders buy new launches before inspecting the contract.
The only reliable way is to actually try the round trip. A simulation buys the token and immediately sells it inside a single eth_call with a state override — so it costs no gas and leaves no on-chain footprint — and checks whether the tokens come back out. If the sell reverts or returns nothing, it is a honeypot. Static contract scans only read the bytecode and guess, which a well-built honeypot can defeat. true402 exposes this as a pay-per-call check on Base.
A partial honeypot allows a tiny sell but reverts on a larger one, using a max-transaction or anti-whale limit. A single small test trade reads as "sellable", so most checkers clear it — then real size gets trapped. Catching it requires simulating at more than one size: true402 runs a small probe and a larger "whale" probe and flags sellable_small_only when the bigger sell is blocked.
A good one is built to fail conservative: anything it cannot cleanly simulate is reported as "not simulated", never as "safe", because a false safe loses money. true402 only reports sellable=true when a real round trip succeeded, and it never assumes safety on missing data, an RPC error, or a token with no tradeable pool.