DEV Community: bykamo

I Made My Website Charge AI Crawlers with HTTP 402. In 30 Days, 5,811 Came and 5 Paid.

bykamo — Fri, 12 Jun 2026 06:48:03 +0000

I run a content site, do-and-coffee.com. Like everyone else, it gets scraped by AI crawlers. Instead of blocking them, I did something else: I put a paywall in front of the site that returns HTTP 402 Payment Required to bots, with machine-readable payment instructions. If a crawler pays a cent in USDC, it gets the article. If it doesn't, it gets the 402 and nothing else.

Then I let it run for 30 days and watched. Here's what actually happened — and it's not the number you'd put on a pitch deck.

TL;DR

A Cloudflare Worker sits in front of the site. AI crawlers get 402 + x402 payment requirements; humans and search bots pass through free.
Payment is USDC on Base, $0.01 per article, verified and settled through Coinbase's CDP facilitator.
30-day result: 5,811 crawler requests, 5 paid, 5,806 served a 402. Revenue at $0.01/article ≈ $0.05.
The interesting part isn't the revenue. It's who paid: GPTBot paid 4 times out of 48 requests; ClaudeBot paid once out of 651.

Architecture

do-and-coffee.com/blog/article/*  ─▶  x402 Worker (Cloudflare)
                                       │
   has X-PAYMENT-RESPONSE? ───────────┤─▶ yes ─▶ proxy origin (200)
   KV cache hit (payer:url)? ─────────┤─▶ yes ─▶ proxy origin (200)
   no X-PAYMENT? ─────────────────────┤─▶ 402 + payment requirements
   has X-PAYMENT? ────────────────────┘
        │
        ├─▶ CDP /verify   (is the signed payment valid?)
        ├─▶ CDP /settle   (waitUntil: confirmed — on-chain)
        └─▶ on success: KV.put(payer:url, receipt, ttl 24h) ─▶ proxy origin

The worker speaks the x402 protocol: a 402 response carries an accepts array describing exactly how to pay (scheme exact, network base, asset USDC, amount, payTo wallet). A compliant agent reads that, signs a USDC payment, and retries with an X-PAYMENT header. The worker verifies and settles it through Coinbase's facilitator, then proxies the real article.

How it works

The 402 response

When there's no payment, the worker builds the requirements and returns 402:

function buildPaymentRequirements(resourceUrl: string, env: Env): PaymentRequirements {
  return {
    scheme: "exact",
    network: "base",
    maxAmountRequired: "10000", // 0.01 USDC (6 decimals)
    resource: resourceUrl,
    description: "Access to Do and Coffee premium article content",
    mimeType: "text/html",
    payTo: env.RESOURCE_WALLET_ADDRESS,
    maxTimeoutSeconds: 60,
    asset: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base
    extra: { name: "USD Coin", version: "2" },
  };
}

Verify, then settle

When a payment does arrive, the worker decodes the X-PAYMENT header, then calls the CDP facilitator twice — once to verify the signature is valid, once to settle it on-chain:

const settleRes = await fetch(`${env.FACILITATOR_URL}/settle`, {
  method: "POST",
  headers: { "Content-Type": "application/json", ...settleHeaders },
  body: JSON.stringify({
    x402Version: 1,
    paymentPayload,
    paymentRequirements: reqs,
    waitUntil: "confirmed", // block until the chain confirms
  }),
});

Don't charge twice

A paid payer is cached in Workers KV for 24 hours, keyed by payer:url, so a crawler that re-fetches the same article within a day isn't billed again:

await env.PAID.put(`${settleJson.payer}:${targetUrl}`, receipt, {
  expirationTtl: 86400,
});

What it cost / earned

Worker + KV: within Cloudflare's free tier at this volume — $0.
Facilitator: Coinbase CDP, no per-call fee at this scale.
Revenue over 30 days: 5 payments × $0.01 = ~$0.05 (the dashboard tracks counts, not USD; this is the configured price × paid count).

So: net a few cents. As a business, this is nothing. As a measurement, it's the whole point.

The 30-day numbers

Window: May 14 – June 12. Source: the worker's own crawl-stats dashboard.

	Count
Total crawler requests	5,811
Paid	5
Served 402	5,806

Per crawler:

Crawler	Requests	Paid
Claude-SearchBot	1,536	0
PetalBot	1,502	0
ClaudeBot	651	1
Amzn-SearchBot	444	0
OAI-SearchBot	337	0
GPTBot	48	4
Other (long tail of minor UAs)	1,293	0
Total	5,811	5

Most-hit paths: /blog/article/* (1,633), /robots.txt (1,575), /sitemap.xml (840).

What broke / what I learned

Almost nothing pays. 0.086% of requests resulted in a payment. The overwhelming default behavior when an AI crawler meets a 402 is to leave. If you're imagining passive USDC income from agentic traffic, the live data says: not yet, not at this volume.
The crawlers that can pay still mostly don't. GPTBot paid on 4 of 48 requests (~8%); ClaudeBot on 1 of 651 (~0.15%). Treat exact attributions cautiously — these are user-agent strings, which can be spoofed — but as a first-party observation, the agents presenting OpenAI's GPTBot UA were by far the most likely to actually complete an x402 payment. Everything else (search-indexing bots like Claude-SearchBot, PetalBot, OAI-SearchBot) just hammered /robots.txt and /sitemap.xml and bounced off the 402.
The origin has to trust the paywall. The worker proxies to my real site, so my site needs to know "this request was paid." I had it mint a short-lived HMAC access token (signed {payer, resource, exp}) and pass it as an Authorization: Bearer header, plus spoof a browser User-Agent so the origin returns full HTML instead of its own bot treatment. Without the browser UA, the origin's own anti-bot logic fought the paywall.
Settling synchronously costs latency. waitUntil: "confirmed" blocks the response until Base confirms the transfer. It's the safe choice (you serve content only after the money is real), but it adds seconds to a paid request. For a $0.01 article that's fine; for a high-frequency API it would be the first thing I'd revisit.
URL normalization matters for verify. The resource in the payment requirements has to match exactly on the retry, so I strip operational query params (__x402, id) before composing it. A mismatch there silently fails verification.

Why this matters

There are a lot of essays about the "agentic web" and machines paying machines. There are very few sites actually returning 402 to real crawlers and reading the receipts. This is one of them, and the honest takeaway is: the rails work — verify, settle, USDC on Base, all fine — but the demand side isn't here yet. The number that matters today isn't the $0.05. It's the 5-out-of-5,811, and the fact that one vendor's bot pays 50× more often than another's. That ratio is the thing worth watching as this evolves.

I'll keep it running and report the curve.

I'm KAMO, a developer in Kyoto. I write implementation logs — working code, real costs, what broke.

Get every log: https://bykamo.substack.com
Portfolio: bykamo.dev

I Bought a $100 Hat for $0 — Proving an AI Agent Was Human-Backed with World AgentKit

bykamo — Fri, 12 Jun 2026 05:46:26 +0000

A $100 hat showed up at my door in Kyoto. I paid nothing for it — not for the hat, not for shipping. $0.00.

It wasn't a coupon I found or a sale. The store, humanrequired.shop, only gives that discount to AI agents that can prove a real human is standing behind them. So I made my agent prove it, on-chain, with a zero-knowledge proof. The discount it got back was 100% off. Here's the whole path, because the design held together far better than I expected.

TL;DR

World Foundation's AgentKit lets you prove on-chain that an agent is "human-backed."
humanrequired.shop hands a human-only 100%-off discount to verified agents — once per World ID.
The official Claude Code plugin (worldcoin/agentkit-shopify-demo) ships the whole flow as skills.
Result: one "Human in the Loop" Hat, $100 → $0, shipping included, delivered to Japan.

Architecture

[Claude Code]
   ├─ plugin: agentkit-shopify
   │   ├─ skill: shopify-agent-discount  (SIWE signature → World discount API)
   │   └─ skill: shopify-storefront       (Shopify product JSON → cart URL)
   │
   ├─ Agent Wallet (local Ethereum keypair)
   │   └─ registered in AgentBook (on World Chain) = the human-backed proof
   │
   └─ Shopify (humanrequired.shop)
       └─ /api/verify gate (Worldcoin's verification endpoint)

The key idea: you don't give the agent a World ID. A human delegates the agent's public key on-chain. The private key never leaves the machine.

How it works

Step 1 — Install the plugin

/plugin marketplace add worldcoin/agentkit-shopify-demo
/plugin install agentkit-shopify@worldcoin-agentkit
/reload-plugins

Step 2 — Generate an agent key

uv run --with eth-account python3 -c "from eth_account import Account; print(Account.create().key.hex())" > .agent-key
chmod 600 .agent-key

Check the wallet address:

uv run --with eth-account python3 -c "from eth_account import Account; print(Account.from_key(open('.agent-key').read().strip()).address)"
# => 0xC56A...

Step 3 — Register in AgentBook (the human-backed proof)

In a separate terminal (it shows a QR code):

npx @worldcoin/agentkit-cli register 0xC56A...

Scan the QR in the World App.
Your Orb-verified World ID generates a zero-knowledge proof.
The AgentBook contract on World Chain writes agent_address → human_nullifier.
Worldcoin's relayer covers the gas, so you pay nothing to register.

Step 4 — Call the discount API

get-coupon.py does four things:

Signs a SIWE message (Sign-In with Ethereum, EIP-4361) with the key in .agent-key.
Base64-encodes the signature into an agentkit: HTTP header.
POSTs the product URL to https://discount-app.worldcoin.org/api/verify.
The server checks AgentBook — if the agent maps to a registered human, it returns a discount code.

PRIVATE_KEY=$(cat .agent-key) ./get-coupon.py https://humanrequired.shop/products/human-in-the-loop-hat
# => WORLD-ID-ced1a8fe6682

Step 5 — Build the checkout URL

No special API needed on the Shopify side — the plain product JSON endpoint is enough.

curl -s "https://humanrequired.shop/products/human-in-the-loop-hat.json" | jq '.product.variants[0].id'
# => 46991516106914

Shopify's standard cart permalink finishes it:

https://humanrequired.shop/cart/<variant_id>:<qty>?discount=<code>
https://humanrequired.shop/cart/46991516106914:1?discount=WORLD-ID-ced1a8fe6682

What it cost

The hat: $0.00
Shipping to Kyoto: $0.00
Gas to register on World Chain: $0.00 (Worldcoin's relayer paid it)
Total out of pocket: $0.00

What broke

npx ...register needs its own terminal. It draws a QR code; running it inside Claude Code's Bash mangles the output. Run it in a real terminal.
Don't do a test run. The discount code is derived deterministically from your nullifier hash, so "let me just call it once to see" spends your one real code. I held off on hitting the API until the checkout URL was fully assembled.
Strip query params off the product URL. A trailing ?variant=123 can make the discount API treat it as a different product.
/reload-plugins did nothing in my setup. The skills are just bash scripts under ~/.claude/plugins/marketplaces/worldcoin-agentkit/skills/, so I ran them by hand and the flow still completed.

Why this matters

A few design choices stood out, and they're the reason I bothered writing this down:

The discount code appears to be deterministic. The tail of WORLD-ID-ced1a8fe6682 matched the tail of the nullifier hash from registration (0x2fd8701b...a8fe6682). I can't see the server, but that match strongly suggests the code is derived from the nullifier rather than from a stored counter or random value — which would mean "one human, one code" is enforced cryptographically, not by a database row.
The private key never goes over the wire. Auth is a SIWE signature; the server does ecrecover to get the signer address, then looks up the human link in AgentBook.
The MCP turned out to be unnecessary. The plugin registers a Shopify Storefront MCP, but the shopify-storefront skill just curls Shopify's public product JSON. Easy to miss, and the right call.

I spend a lot of time watching the supplier side of agentic commerce — sites that gate AI traffic. This was the rare chance to be the consumer passing through one of those gates, and the gate's logic is positive: not "block AI," but "let human-backed agents through." Claude Code + plugin + external MCP + a local private key + a ZK proof + an on-chain registry, all meshing cleanly. The hat is the souvenir.

I'm KAMO, a developer in Kyoto. I write implementation logs — working code, real costs, what broke.

Get every log: https://bykamo.substack.com
Portfolio: bykamo.dev