DEV Community: Laurent HALBRUN

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

Laurent HALBRUN — Tue, 28 Jul 2026 22:20:18 +0000

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:

Most malicious contracts aren't verified, or are verified with obfuscated / misleading source.
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.
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.

Scraping Leboncoin & SeLoger past DataDome — what actually worked (and the honest cost)

Laurent HALBRUN — Thu, 23 Jul 2026 22:26:03 +0000

If you've tried to scrape Leboncoin or SeLoger (two of France's biggest sites), you've met DataDome — and probably lost. Here's what I found after actually shipping it, including the parts nobody says out loud.

The wall: DataDome guards everything

First myth to kill: there's no clever back door. I tested the obvious one — Leboncoin's internal mobile API (api.leboncoin.fr/finder/search), the JSON endpoint the app uses. From a residential IP, with and without an app key:

HTTP 403 → {"url":"https://geo.captcha-delivery.com/captcha/?..."}

DataDome sits in front of the web pages and the internal API. A plain residential IP + stealth browser passes lighter anti-bot (Google Maps, Amazon, Pages Jaunes) but not DataDome's hard mode. Don't waste a week on undetected-chromedriver here.

What actually works: solver-backed residential unlocker

The only reliable path is a service that (a) provides a residential IP and (b) solves the DataDome challenge. I routed the request through one, asking for a French residential proxy + JS render + antibot, and got a clean 200 with the full page:

HTTP 200 | 1.05 MB | not blocked | __NEXT_DATA__ present

The honest tradeoff: it's not free. A premium+antibot+JS-render request burns real credits (~$0.005–0.02 each). If someone tells you DataDome is beatable for free at scale, they're selling you a cookie that expires in a few hours.

Don't parse the DOM — read the embedded JSON

Once you're through, both sites hand you structured data if you know where to look:

Leboncoin is a Next.js app: the ads are in __NEXT_DATA__ at props.pageProps.searchData.ads — each with list_id, subject, price, location, owner.type (private/pro), images, attributes. No brittle CSS selectors.

const m = html.match(/<script id="__NEXT_DATA__"[^>]*>([\s\S]*?)<\/script>/);
const ads = JSON.parse(m[1]).props.pageProps.searchData.ads;

SeLoger renders cards you can read with data-testid (sl.explore.card-container, sl.explore-card-price). One gotcha that cost me a 422: SeLoger's inseeCodes param zero-pads the commune to 4 digits — INSEE 33063 (Bordeaux) becomes 330063. Miss that and you get "could not get content".

The result

Clean, structured listings from both:

Leboncoin "iphone" Bordeaux → 3976 results
  60 € | iPhone 11 | private | 2026-07-23
 130 € | iPhone 11 - Garantie | pro

SeLoger Bordeaux → median 5657 €/m²
  Appartement 4p 163m² | 1 370 000 € | 8422 €/m²

I wrapped both as pay-per-result actors so you don't have to manage the unlocker, cookies or the SeLoger code quirk:

Leboncoin: https://apify.com/x402farm/leboncoin-scraper
SeLoger: https://apify.com/x402farm/seloger-scraper
The wider farm (residential scraping + French business data): https://api.x-402.online/start

Happy to answer questions on the DataDome specifics in the comments.

Scraping French sites that block datacenter IPs — what actually worked (Pages Jaunes, Google Maps)

Laurent HALBRUN — Thu, 23 Jul 2026 17:49:54 +0000

Some sites just refuse to be scraped from the cloud. Point a headless browser at them from AWS/GCP and you get a bot wall, a captcha, or an empty results feed. The fix that finally worked for me wasn't a smarter parser — it was where the request came from.

The problem: datacenter IPs are a dead giveaway

Two French sources I needed:

Pages Jaunes (the French Yellow Pages) — anti-bot (DataDome), and the phone number is lazy-loaded so a naive scrape only sees name + address.
Google Maps — aggressively rate-limits and blocks cloud IP ranges; the results feed often loads empty from a datacenter.

From a cloud IP, both mostly failed. From a residential IP, both worked.

Fix 1 — route the browser through a residential IP

Running real Chromium through a residential IP (not a cloud range) passes the DataDome challenge on Pages Jaunes and lets the Google Maps results feed actually populate. Same code, different exit IP — that's the whole trick for the network layer.

Note: not every anti-bot falls to this. Pages Jaunes' DataDome is passable this way; some others (Leboncoin, SeLoger) run a much harder challenge that a plain render won't beat. Test before you assume.

Fix 2 — read JSON-LD, don't fight the lazy-load

On Pages Jaunes the phone is deliberately hidden until a JS interaction, so scraping the search page gives you phone: null. But each business detail page ships a <script type="application/ld+json"> block with the real number:

const m = html.match(/"telephone"\s*:\s*"([^"]+)"/);
const phone = m ? m[1].replace(/^\+33/, "0") : null;

Read the structured data instead of the rendered DOM. On a Bordeaux "avocat" search this recovered 100% of phone numbers (5/5) vs ~0% from the search page alone.

Fix 3 — Google Maps is a SPA, so wait + scroll

Google Maps loads its results feed via XHR after the initial HTML. If you grab page.content() too early you get an empty shell. You have to:

Set the Google consent cookies (SOCS / CONSENT) so you skip the consent interstitial.
Wait for div[role="feed"].
Scroll the feed until you have enough cards, then read them.

for (let i = 0; i < 12; i++) {
  const n = await page.evaluate(() =>
    document.querySelectorAll('div[role="feed"] a[href*="/maps/place/"]').length);
  if (n >= max) break;
  await page.evaluate(() => {
    const f = document.querySelector('div[role="feed"]');
    if (f) f.scrollTop = f.scrollHeight;
  });
  await page.waitForTimeout(1300);
}

Each card gives you name (the link's aria-label), rating (.MW4etd), reviews (.UY7F9), category (.W4Efsd), phone and website. Clean B2B leads — name + phone + website + rating — the kind cloud scrapers miss because the feed never loads for them.

Turned it into pay-per-result actors

Rather than keep this to myself, I packaged them as Apify actors — pay per result, no subscription:

Pages Jaunes B2B leads (optional verified phone from JSON-LD): https://apify.com/x402farm/pages-jaunes-leads
Google Maps local businesses: https://apify.com/x402farm/google-maps-leads

Happy to answer questions on the residential-IP approach or the JSON-LD phone trick in the comments.

I built 53 pay-per-call APIs that AI agents can pay for autonomously (x402 + USDC on Base)

Laurent HALBRUN — Wed, 22 Jul 2026 01:59:37 +0000

AI agents are getting good at deciding what data they need. What they're bad at is the human paperwork around getting it: creating accounts, clicking email confirmations, pasting API keys, entering a credit card. Every one of those is a wall an autonomous agent can't climb on its own.

x402 removes that wall. It's an open payment protocol: the server answers 402 Payment Required, the client pays a few cents in USDC on-chain, and the request goes through — no account, no key, no human. So I built a farm of APIs designed to be consumed exactly that way.

What's in it

Base URL: https://api.x-402.online/ — the root returns a machine-readable JSON catalog, and there's an /openapi.json + /llms.txt for agents.

53 endpoints, all pay-per-call in USDC (from $0.005), settled on Base (also accepts Polygon & Arbitrum):

Web tooling — clean-markdown extraction, JS-rendered HTML, screenshots, PDF, link/meta extraction
French business & open data — company lookup (SIREN/SIRET), full KYB dossiers, financial scores, real-estate AVM & investment scorecards, BODACC, cadastre, DVF sale prices, geocoding, weather, holidays, IBAN validation…
UK company data — Companies House profiles, officers, PSC/beneficial owners, one-call KYB verdict
US public companies — SEC EDGAR profiles, annual financials, filings, one-call financial snapshot

The friction is the value: these wrap sources that need signup, keys, or heavy parsing (XBRL, registries) and expose them as one clean, payable call.

How an agent uses it

import { wrapFetchWithPaymentFromConfig } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(process.env.AGENT_KEY);
const fetchPaid = wrapFetchWithPaymentFromConfig(fetch, {
  schemes: [{ network: "eip155:8453", client: new ExactEvmScheme(account) }],
});

// The wrapper handles the 402 -> sign -> retry automatically.
const res = await fetchPaid("https://api.x-402.online/v1/us/snapshot?ticker=AAPL");
console.log(await res.json());

The agent's wallet just needs USDC on Base. No gas needed on the client side — the facilitator settles.

It's live and already settling

Real on-chain payments are going through today (verifiable on BaseScan). If you're building agents that need company data, web extraction, or open-data lookups without the account/key dance, point them at https://api.x-402.online/ and let them pay their own way.

Feedback welcome — happy to add endpoints agents actually ask for.