Detecting honeypots and hidden taxes on Robinhood Chain

A honeypot lets you buy a token but not sell it, or lets you sell only after taking most of your proceeds as “tax”. On a chain where thousands of tokens launch every day, these are common, and the tricks keep changing. This article explains the three ways to measure a token’s real tax, why each alone misses cases, and how the Crius security endpoint combines them.

Why reading the contract isn’t enough

The classic approach scans the token’s source or bytecode for tax variables, blacklists, pause switches and owner-only setters. It’s useful, but it misses a lot:

• Taxes that change. A token launches with 0% tax, then the owner raises sells to 99% once enough people have bought. The code allowed it all along; the scan only sees “has a setter”.
• Whitelists. The tax applies to everyone except a few addresses, so the deployer’s own tests pass.
• Unverified code. Without source, a scan sees opaque bytecode.
• Uniswap v4 hooks. On v4 the tax can live in the pool’s hook rather than the token. The token contract looks perfectly clean.
• Per-block rules. Limits that act per L1 block (about 12 seconds on Robinhood Chain) look harmless in a single test transaction.

Method 1: realized tax from real trades

The most reliable measurement is what actually happened. For every real trade, compare what the pool sent with what the trader received (and the reverse on sells), using the transaction’s transfer logs. The difference is the tax that was really taken, whether by the token contract or a v4 hook.

Measured continuously, this catches taxes that change after launch, and splitting it by type of wallet exposes whitelists: if ordinary wallets pay 40% and a few addresses pay 0%, that’s visible.

Its limit is obvious: a token that nobody has sold yet has no realized sell tax.

Method 2: simulate a real sequence

For tokens without trade history, simulate one. Not a single call, but the sequence a real user goes through:

1. approve the router;
2. buy through the router people actually use;
3. transfer the tokens to a second, fresh wallet;
4. sell from that wallet.

Robinhood Chain’s node supports eth_simulateV1, which runs this whole sequence against the current state with fake balances, without deploying anything or spending real funds. If a step reverts, re-running it with tracing reveals the inner revert reason. The buy size is searched to stay under max-transaction and max-wallet limits, so a limit isn’t mistaken for a honeypot.

Its limit: simulation shows what happens now, for these wallets. It can’t predict an owner raising the tax tomorrow.

Method 3: static checks

Static analysis still earns its place for what could happen next: is ownership renounced, can the owner mint, pause, blacklist, change taxes or upgrade a proxy, and what’s the maximum tax the code allows?

Combining them

Each method covers the others’ blind spots:

When they disagree (simulation says 0% but real sells pay 30%), that disagreement is itself the warning sign, flagged as a mismatch.

Using it

curl "https://api.crius.sh/v1/robinhood/token/0x7b8892cea949bc60d494681d1bc3ea96071ab0b8/security"

The response combines realized and simulated tax, the honeypot verdict, contract flags and, for v4 tokens, the pool hook’s permissions and risk. It works without a key from cached results; fresh=1 runs a new simulation on demand (Starter plan and up, 20 credits) when you need the state at this exact block.

Practical rules before buying a fresh token:

• No realized sells yet? Rely on the simulation, and treat the result as provisional.
• Owner can still change taxes? Size positions as if the sell tax could go up.
• v4 hook unverified with swap permissions? Read the hooks guide and check realized sells closely.
• Liquidity unlocked? Check /liquidity: a token can be perfectly sellable until the liquidity is pulled.

No check makes a token safe; they make obvious traps visible. Treat the results as information, not advice.