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.

Per crawler:

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

What broke / what I learned

1. 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.

2. 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.

3. 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.

4. 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.

5. 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