标签：#x402

What a penny from a stranger taught us about how agents actually find things. At 02:59:06 UTC on August 25, a wallet we had never seen paid our verification service one cent over x402. Four and a third seconds later, Coinbase's service catalog refreshed our listing. Nothing else we had ever done moved that listing. Deploys did not move it. Metadata edits did not move it. Validation runs did not move it. Money moved it, in under five seconds, every time. The transaction is public: 0x5e9bd3c9c61d7556b1ffb1a5b936591efccd765af94a81da435432e1f62ff52a on Base. This article is the story of what that penny bought us, which was not revenue. It was a map. Where we were standing ScrapeCheck is an independent verification service for web data. You send a URL and the value you believe is on that page. We re-fetch the page from our own infrastructure and return a signed pass, fail, or unverifiable. Never a guess. Every verdict is ed25519 signed and verifies offline against our published key, so whoever holds it can check it without trusting us. We listed on the x402 Bazaar, Coinbase's machine-readable catalog of paid services, on August 14. The catalog held a little over fifteen thousand rows. Listing is permissionless. Then we noticed something about discovery: the catalog's own API defaults to a curated view. A client that browses the normal way is shown roughly 110 hand-picked rows out of fifteen thousand. The two largest curated providers hold about 44 percent of that shelf between them. Everyone else, us included, is in the warehouse but not in the front window. So we did what we do to web pages: we instrumented our own listing and started reading it back, on a schedule, with timestamps. What moves a row The catalog publishes freshness fields on every row. We recorded ours across every kind of event we could produce. The pattern was absolute. Our row was created one second after our registration payment settled. It was crawled five seconds after a later settlement. It refres

Honestly, when I saw Cloudflare's announcement, my first reaction wasn't "oh cool, something new"—it was "there goes another giant company proving the thing I've been saying all along." What Cloudflare Actually Did On August 4, Cloudflare (yes, the infrastructure giant that blocks traffic and runs CDNs for half the internet) launched "Cloudflare Wallets" and something called cloudflare.pay. It gives AI agents three things they didn't have before: An identity —a recognizable wallet handle so others know exactly which agent is paying A wallet —funded with stablecoins, so the agent can actually pay A spending cap —and this one is enforced by Cloudflare's infrastructure itself The structure here is what I think matters most. You (the human) hold an Account Wallet where the funds live; then, through an API key, you grant a limited slice of spending power to individual Virtual Wallets that your agents actually use. Here's the analogy that makes it click: the Account Wallet is your company's master account, and each Virtual Wallet is a prepaid card with a spending limit that you hand to one of your AI employees. The only difference is these "employees" are AI, and the limit on the card isn't managed by a credit card company's risk engine—it's written directly into Cloudflare's infrastructure. Payments run through the now widely-discussed x402 protocol: an agent wants to buy a service, and it pays for that one transaction on the spot with stablecoins. I should be upfront about something: it's not fully usable yet. As of August 5, it's in a "launched, you can reserve your cloudflare.pay name" state. The real funding, Virtual Wallets, and programmatic spend controls are, per Cloudflare, coming "over the next few months." So this is a clear directional statement, not a mature product you can fully adopt today. Why I'm Not Reading This as "One New Product"—I'm Reading It as an Industry Consensus If this were just Cloudflare doing its own thing, I wouldn't bother writing about i

A few weeks ago I wrote up what agents were paying for on NetIntel , my platform of pay-per-call APIs settled in USDC over x402 — no signup, no API keys, no accounts. An agent hits an endpoint, gets a 402 Payment Required , pays a fraction of a cent, and gets structured data back. That's the whole loop. Since then the dataset has grown, I've instrumented every settled call into a proper database (payer wallet, endpoint, price, latency, transaction hash), and I've launched a second settlement rail. So this is the rewrite with real numbers instead of eyeballed ones — and the findings didn't soften. They sharpened. The setup 2,646 settled paid calls from 194 distinct paying wallets, across 101 live endpoints , over six weeks of instrumented production data. Every call in this dataset is a real on-chain payment with a transaction hash — no test traffic, no estimates. Settlement runs on Base, and as of this month on Solana too. This is still one platform's data in a young ecosystem — the caveats are at the bottom, and one of them is bigger than it looks. But the shape has now held for six weeks straight, and it's the same shape I flagged the first time. Finding 1: revenue is absurdly concentrated — and it stayed that way Five endpoints drive 69% of all revenue. One of them — a text-to-structure endpoint that takes messy input and returns strict typed JSON — is 42% by itself . The rest of the top five are all in the same family: translation, structured LLM inference, and one domain-intelligence report. The other 96 endpoints split the remaining 31%. Thirty-five of the 101 have never been paid for once. Not "underperformed" — zero settled calls, ever. When I first published this pattern I wondered if it was an artifact of a small sample. The dataset has since more than doubled and the concentration ratio barely moved. I now treat it as the market talking, not noise. Here's the part I'd want to know if I were reading this: that 42% endpoint is essentially one buyer — a wall

How a dormant HTTP status code and a $500 billion valuation fight tell the same story: money is finally becoming native to the internet. For three decades, the HTTP specification carried a status code that did nothing. Code 402 — "Payment Required" — was reserved in the 1990s for a future in which the web would have money built in. That future never arrived. Payments were bolted on instead: card forms, PayPal buttons, checkout redirects, subscription walls. On July 14, 2026, that changed formally. The Linux Foundation announced the operational launch of the x402 Foundation , the open-governance body that now stewards the x402 protocol — the standard, contributed by Coinbase, that turns HTTP 402 into a live payment negotiation layer. Forty organizations have joined. The premier member list reads like a peace treaty between industries that spent a decade fighting each other: Visa, Mastercard, American Express, Stripe, Adyen, Fiserv, Google, AWS, Shopify, Coinbase, Circle, Cloudflare, Ripple, MoonPay , plus the Solana, Stellar, and Monad foundations. When card networks, cloud providers, and crypto issuers all sign the same governance charter, something structural is happening. That something is AI agents — and the question of how they pay for things. From press release to protocol The x402 story started in September 2025, when Coinbase and Cloudflare announced their intent to create a foundation around a simple idea: if AI agents are going to consume APIs, data, compute, and content autonomously, they need a payment method that works the way machines work — inside the HTTP request itself, with no account signup, no card form, and no human in the loop. The mechanics are deliberately boring. A client, typically an AI agent, requests a paid resource. The server responds with status 402 and a machine-readable header describing what it wants: the amount, the asset (usually a stablecoin like USDC), the network, and the payment scheme. The agent signs a payment authorization,

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 ): Payment

If you build agents on Base, two things landed recently that are worth connecting. First: Base shipped its own Agent Skills. There's now a base/skills repo with consolidated skills that teach an AI agent to connect to Base, deploy contracts, authenticate wallets, and run nodes — installed with one command via Vercel's npx skills CLI. Second: that CLI is part of a fast-growing, cross-agent ecosystem most crypto devs haven't clocked yet. So this post does two things — explains how npx skills and skills.sh actually work, and shows where the payment layer in Base's skills stops and how to extend it with x402 pay-per-call and batch disbursement . What npx skills actually is npx skills is an open CLI from Vercel Labs for installing "skills" — modular SKILL.md files that teach an agent a specific capability without stuffing everything into its context window. A few things make it different from what crypto devs usually expect: GitHub is the registry. There's no central package server. Any public GitHub repo with a SKILL.md at its root is a valid, installable skill. Install with npx skills add owner/repo . It's cross-agent. The same skill installs into Claude Code, Cursor, Codex, GitHub Copilot, Goose, Windsurf, Gemini, and dozens more. You write once; it works across the agent you (or your users) actually run. skills.sh is the directory + leaderboard. It ranks skills by real install counts pulled from telemetry, with all-time, trending, and hot lists. There's no editorial submission step — you publish by putting a skill in a repo, and installs surface it. The format underneath — SKILL.md — is an open spec, which is why Base, Vercel, Anthropic, and a long tail of independent devs all use the same files. Here's Base's install, for reference: # Base's official agent skills npx skills add base/skills --skill build-on-base npx skills add base/skills --skill base-mcp build-on-base is a consolidated Base dev playbook; base-mcp wires up a Base MCP server that gives an agent a wall