How to check if a token is a honeypot before your bot buys it

Your bot spots a fresh pair with volume ripping. It buys. The transaction confirms. Green candle. You go to take profit and… the sell reverts. Or it goes through but you receive 1% of what you should. You just bought a honeypot — a token you can buy but can't sell.

If you're building an autonomous trading agent, a sniper, or any bot that touches tokens it didn't hand-pick, this is the single failure mode that wipes accounts fastest. Here's how these traps actually work, why the "just read the contract" advice doesn't scale, and how to gate every buy behind a single pre-trade check.

What a honeypot actually is

A honeypot isn't magic. It's a token contract that makes buying work normally so liquidity and hype build up, while quietly making selling impossible or worthless for everyone except the deployer. Common mechanisms:

• ~100% sell tax — the transfer function siphons almost the entire amount on a sell. You "can" sell; you just get dust back.
• Transfer blacklist / allowlist — _transfer reverts unless from is the owner. Everyone can buy, only the deployer can sell.
• tradingEnabled gate — trading is toggled on to attract buyers, then flipped off.
• Max-tx / max-wallet limits set so low a normal sell always reverts.
• Pausable / mintable / proxy-upgradeable — even a "clean" contract today can be upgraded into a trap tomorrow.

The nasty part: none of these look alarming to a human skimming the token page. The buy tax can be 0%. The chart can look organic. The trap only fires on the sell path.

Why "just read the contract" doesn't scale

The advice you'll hear is "read the Solidity." Three problems:

1. Most malicious contracts aren't verified, or are verified with obfuscated / misleading source.
2. Even with source, the trap is often hidden in modifiers or an external call — a require(canTransfer(from)) where canTransfer reads a mapping the deployer controls. Nothing in _transfer itself looks wrong.
3. Your bot has milliseconds, not minutes. You can't manually audit a contract per trade.

Static reading catches the lazy scams and misses the good ones.

The two signals that actually work

1. Transaction simulation. Simulate a buy and a sell against current chain state (an eth_call / state-override or a forked EVM). If the simulated sell reverts, or the amount out is a fraction of the amount in, you have your answer — regardless of what the source says. This catches the trap by its behavior, not its code.

2. Known-pattern security data. Databases like GoPlus continuously classify contracts for honeypot markers, buy/sell tax, blacklist functions, ownership, open-source status, holder distribution, and proxy/upgrade risk. Cross-referencing these catches known bad patterns instantly.

Do both and you cover behavior and reputation. The problem: standing up a simulation node per chain and wiring the data sources is real infrastructure — for eight chains, it's a project in itself.

One call instead of that project

I got tired of maintaining that plumbing, so I bundled it into a single endpoint that returns a clear verdict. Here's a live call against USDC on Ethereum:

curl 'https://residential-scraper-crypto-company-data.p.rapidapi.com/v1/crypto/security?address=0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48&chain=ethereum' \
  -H 'x-rapidapi-key: YOUR_KEY' \
  -H 'x-rapidapi-host: residential-scraper-crypto-company-data.p.rapidapi.com'

{
  "found": true,
  "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
  "chain": "ethereum",
  "verdict": "OK",
  "isHoneypot": false,
  "buyTaxPct": 0,
  "sellTaxPct": 0,
  "isOpenSource": true,
  "holderCount": 8213785,
  "flags": [],
  "tokenName": "USD Coin",
  "tokenSymbol": "USDC"
}

A flagged token looks like this instead:

{
  "found": true,
  "verdict": "AVOID",
  "isHoneypot": true,
  "buyTaxPct": 5,
  "sellTaxPct": 99,
  "isOpenSource": false,
  "holderCount": 41,
  "flags": ["honeypot", "high_sell_tax", "not_open_source", "blacklist_function"],
  "tokenName": "SafeMoonInu2",
  "tokenSymbol": "SMI2"
}

The verdict collapses everything into four buckets so your bot can branch on one field:

• OK — no red flags
• CAUTION — minor concerns (some tax, low holders)
• HIGH_RISK — serious markers, size down or skip
• AVOID — honeypot / rug markers, do not touch

Wiring it into a pre-trade guard

The quickest way is the honeypot-guard npm package — it wraps this endpoint, payment included:

npm install honeypot-guard

import { assertSafeToBuy } from "honeypot-guard";

await assertSafeToBuy(token, "base"); // throws if honeypot / rug
await executeBuy(token);              // only runs when it's safe

Or call the API directly:

The whole point is to make it a hard gate in front of every buy:

async function safeToBuy(address, chain) {
  const res = await fetch(
    `https://residential-scraper-crypto-company-data.p.rapidapi.com/v1/crypto/security?address=${address}&chain=${chain}`,
    { headers: {
      'x-rapidapi-key': process.env.RAPIDAPI_KEY,
      'x-rapidapi-host': 'residential-scraper-crypto-company-data.p.rapidapi.com'
    }}
  );
  const s = await res.json();
  return s.verdict === 'OK' || s.verdict === 'CAUTION';
}

// in your trade loop:
if (!(await safeToBuy(token, 'base'))) {
  log(`Skipping ${token}: failed safety check`);
  return;
}
await executeBuy(token);

It covers 8 chains — Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, Avalanche, Solana — behind one key, so a multi-chain sniper doesn't need eight integrations.

Try it

Try it live (free, no wallet): paste a token address and get the verdict → api.x-402.online/honeypot

There's a free tier to wire it into your bot and see the verdicts on real tokens: the endpoint is here. For autonomous agents that pay per call, the same route is also available as a pay-per-call x402 endpoint (USDC on Base) — no subscription, no key management.

If you're running a bot right now: what's your current pre-trade check — simulation, a security API, or nothing but vibes? Curious what's actually catching traps for people in production.