A month of real x402 traffic, by the numbers.

The setup

The product is simple: an AI agent (or anyone with a wallet) pays $1.00 and receives a persistent API key for publishing HTML, with no signup. The endpoint answers unpaid requests with a 402 carrying x402 payment requirements (v1 and v2 both, more on that below), verifies and settles via a facilitator, and mints the key on settlement. It is listed on x402scan, which is where most buyers find it. Individual unlocks (make a site permanent, custom domain, higher limits) are purchasable the same way, and there is a prepaid credit balance so an agent can pay once and draw silently afterwards.

The numbers

Settled, completed payment grants in our ledger for the month, excluding our own proving tests, which we flag because honest baselines matter more than big ones:

• x402 on Base (USDC): three $1.00 provisions settled end to end. The first, on June 8, was our own funded test wallet proving the loop. The other two, on June 21 and June 25, came from wallets we do not control, with no human in our loop.
• MPP on Tempo (USDC): one $1.00 settlement on June 22, making this one of the earliest endpoints with live traffic on both x402 and Stripe's MPP rails.
• Card via scan-to-pay QR: one $10.00 payment (our own live test of the human-fallback rail: agent prints a QR, a human scans and pays by card, the agent gets its key plus a $9 credit balance).
• Credit balance draw: one $1.00 unlock (make-a-site-permanent) paid silently from that balance, no 402 round-trip.

The cadence is the interesting part: roughly one transaction every two or three days, all month, with no spike. Nobody announced anything. The x402scan listing alone generates a steady trickle of discovery from a technical audience, which for a protocol this young is a real distribution result even at small dollar amounts.

Explorer vs ledger: 13 is not the whole story

The public x402scan card for the resource reads 13 transactions from 7 buyers. Our ledger minted fewer completed grants than that. Both numbers are true; they measure different things. The explorer indexes on-chain settlement activity to the receiving wallet. The ledger records outcomes: grants unique per protocol and settlement reference, so a retried settlement, a replayed payment header, or a payment that settled on-chain but failed later in the request flow counts on-chain without minting anything.

If you run a paid endpoint, assume the explorer will read higher than your database, and treat the delta as your observability surface: log every 402 you issue, every verify, every settle, and every mint with the settlement reference, so each on-chain transaction can be matched to an outcome or a specific failure. The alternative is quoting the explorer number as conversions, which flatters you until someone checks.

What buyers did after paying

The unflattering part, reported anyway: every payer paid exactly once. No wallet has come back for a second transaction. Several provisioned identities have published nothing; the ones that published did so on pay-day and have not returned. There is no recurring x402 workload here yet, and our ordinary subscriptions all still arrive through a normal checkout page.

Our read: the buyers are mostly x402-ecosystem developers and agent frameworks exercising one of the few live endpoints, which matches the wider data. Reports on x402 volume show the same shape from both directions: transaction counts fell sharply from the November peak while average transaction size grew, which reads as fewer, larger, real payments displacing speculative pings. A live endpoint in mid-2026 sees the early-adopter tail of that curve: genuine autonomous payments, low volume, no habits yet.

Gotchas that cost us live transactions

• Base mainnet USDC signs as "USD Coin", not "USDC". The EIP-712 domain name on mainnet is USD Coin (version 2); testnet USDC uses USDC. A client signing with the wrong domain name produces an on-chain revert at settlement. This cost us two live attempts before we made the asset name configurable.
• v1-only wallets exist. Coinbase's own tooling spoke x402 v1 (payment requirements in the body) while the spec had moved to v2 (the PAYMENT-REQUIRED header). We ship both simultaneously; if you only serve v2, a meaningful slice of wallets cannot pay you at all.
• Some agent wallets cannot pay v2 endpoints yet. We watched a funded agent wallet fail against our endpoint because its client only parsed v1 requirements. Check the client ecosystem before assuming a failed payment is your bug.
• Idempotency is not optional. Settlements retry. A unique constraint on (protocol, settlement reference) is the difference between a retried settlement and a double-mint.
• Time-box anything with ongoing cost. A one-time $1 payment that buys a perpetual obligation is a slow leak. Bounded unlocks are one-time; anything with recurring cost (domains, elevated limits) expires and renews via a fresh 402.

What would change the picture

Three things would move this from "real but early" to "a channel": a wallet paying twice, which is the first sign of a workload rather than a test; unlock purchases outpacing provisions, meaning minted identities are being used in anger; and MPP volume as Stripe's agentic rails reach more regions. We will update the numbers as they change. Until then, the honest summary is: the plumbing works, the discovery is real, the habits are not here yet, and it costs almost nothing to be early.