Originally published at true402.dev/guides/static-scan-vs-honeypot-simulation.
A token can pass a rug-checker and still refuse to sell. The reason is a gap in how most checkers work — they read the contract but never run it. Here's what a static scan can't see, and what a simulation catches.
What a static scan does: read the contract for bad patterns
A static rug scanner (Token Sniffer and most "rug checkers" work this way) reads the contract's bytecode or source and flags known-bad patterns: a mint function, a blacklist, a 100% sell tax, non-renounced ownership, lopsided holder distribution. It's fast, free, and genuinely useful for catching the obvious stuff.
The blind spot: it never runs the trade
Because a static scan only reads, it can't see traps that only appear at runtime:
- an upgradeable proxy whose logic is swapped after launch,
- a sell that reverts only above a certain size (max-tx / anti-whale traps),
- a block that depends on external state,
- conditions a static read just can't evaluate.
The contract looks clean — and still won't let you sell.
What a simulation does: actually buy, then sell
A honeypot simulation trades the token without spending anything: it runs a buy and then a sell in a single gas-free eth_call with a state override — no real transaction, no on-chain footprint — and measures whether the tokens come back out. If the sell reverts or returns dust, it's a honeypot.
Because it executes the real transfer path, it catches the runtime sell-block a scan can't. The key property: the "did WETH actually come back out" measurement can't be faked by the token contract, because it's the real swap code path being executed.
true402's implementation probes at two sizes, so it also catches the nastier variant — sellable small, blocked at size.
The honest take: use both
Static scans aren't useless — they're a fast, free first filter for the obvious red flags. But for anything you're about to actually buy, add a simulation that proves the sell works. The strongest check does both in one pass: structural checks (mint, ownership, proxy), liquidity depth, and the buy/sell simulation, returning a single avoid/caution/ok verdict.
# Free to try — a few checks a day, no wallet, no signup. Simulates the buy + sell on-chain.
npx @true402.dev/rugcheck 0x<token>
# ⚠️ CAUTION (score 75/100)
# • ownership is not renounced
# checked on-chain: honeypot sim + liquidity + ownership
For agents: the simulation, pay-per-call
If you're building a trading bot or agent, wire the check in as a pre-trade gate: POST https://true402.dev/api/v1/base/token-report over x402 — pay per call in USDC on Base, no account, no API key. There's also an MCP server (npx @true402.dev/mcp-server) that exposes it as a native agent tool.
FAQ
Can a token pass a rug-checker and still be a honeypot?
Yes. Most rug-checkers do static analysis — they read the contract for known-bad patterns. That catches the obvious traps, but it cannot run the contract, so it misses honeypots whose sell-blocking only happens at runtime. The only way to be sure is to simulate the sell.
Is a static rug scanner like Token Sniffer enough?
It's a useful first pass — fast, free, good at flagging mint/blacklist/fee/concentration red flags. But static scanners share one blind spot: they don't execute the trade. For anything you're about to actually buy, pair the scan with a buy/sell simulation that proves the token can be sold.
What is a honeypot simulation and how does it work?
It actually trades the token, without spending anything: a buy then a sell inside a gas-free eth_call with a state override — no real transaction — measuring whether the tokens come back out. If the sell reverts or returns dust, it's a honeypot.
How do I verify a token is sellable before I buy?
Run a check that simulates the round trip and inspects contract structure and liquidity in the same pass, returning one verdict. Free to try a few times a day via npx @true402.dev/rugcheck 0x…, then pay-per-call over x402 — no account, no API key.
Top comments (0)