Home
>
Blog
>
blog post
November 3, 2026

Covering x402: a field guide for blockchain data teams

There's no list of x402 payments. No registry, no flag on the transaction, no single contract to watch. If you want to cover them in an analytics product, you have to build that list yourself.

The market is already paying attention. Chainalysis has tracked the growth of agentic payments on Base, and TRM Labs has questioned how much of it really comes from AI agents. Both are about measuring the market. This post is about the other half: what it takes to build that coverage yourself.

We've spent the past months building that list for x402 Radar. This is what the work looks like, step by step.

Six steps to track x402 payments on-chain: from finding agents to multi-chain coverage

What is the x402 protocol?

x402 is an open payment protocol that uses HTTP status code 402, "Payment Required", to let software pay for things on its own: an API call, a dataset, a piece of research. It's now maintained under the x402 Foundation.

It was made for software that pays without a human in the loop, which makes it one of the main rails for agentic payments. Payments are often tiny. On Base, a typical one is around a cent.

What an x402 payment looks like on-chain

On EVM chains, the flow has four steps:

  1. A client requests a resource, for example a paid API endpoint.
  2. The server replies with 402, stating the price, the token (usually USDC) and where to pay.
  3. The client signs a payment authorization and sends the request again with it attached. Typically that's an EIP-3009 transferWithAuthorization on USDC. The other route is a Permit2 signature.
  4. A facilitator verifies the authorization and settles it on-chain, usually submitting the transaction and paying the gas. Sometimes the payer submits its own authorization instead. The server then returns the resource.
How an x402 payment works on EVM chains: client, server, x402 facilitator and USDC settlement

Two consequences for anyone indexing this:

  • The payer is in the USDC Transfer event, not necessarily in tx.from. The transaction is usually sent by the facilitator. Read the payer from the transfer, not from the transaction sender.
  • On-chain, an x402 payment is just a USDC transfer. Nothing in it says "x402" or "agent". Everything that makes it an agent payment has to come from somewhere else.

What does an x402 facilitator do?

An x402 facilitator is a service that verifies a client's signed payment authorization and settles it on-chain on the server's behalf. It usually submits the transaction and pays the gas, so its address, not the payer's, shows up as tx.from.

That works because of EIP-3009: transferWithAuthorization lets a token holder sign a transfer off-chain and anyone holding the signature submit it. The payer signs, the facilitator broadcasts.

How to track x402 payments on-chain: 6 steps

If you've ever added a new chain to an analytics product, most of this will feel familiar.

Step 1: Decide what you're counting

This sounds trivial and isn't. There are at least two reasonable definitions:

  • Spec-correct x402 payments: transfers that match the protocol exactly, settled through the expected rails.
  • Payments made by AI agents: all transfers from wallets you can tie to an agent, including ones that only partly follow the spec, or don't use it at all.

Public trackers mostly count the first. In x402 Radar, we count the second, because that's the flow a compliance team cares about. The two can tell very different stories. That's why public x402 figures vary so much, and why any number you show customers needs its definition next to it.

Even the largest analytics providers draw this line differently. Chainalysis identifies agentic payments by wallets interacting with the x402 protocol and counted well over 100 million of them on Base through Q1 2026. TRM Labs started from settlements by known facilitators, filtered out self-payments, bulk flows from a handful of payers and sellers with very few buyers, and estimated that only 0.6% to 7.5% of what remained looked like AI agents.

Over the summer, the two measures moved in opposite directions in our own data. Same market, opposite trend, depending only on what you count. That's why every number needs its definition next to it.

Step 2: Find the agents

If you count agent payments, you first need to know which addresses belong to agents. There's no single source:

  • On-chain agent registries. ERC-8004 is the biggest one we've found, at least on some chains. It gives you agent identities, owners and the wallets they point to. We cover what's in it in Know Your Agent on-chain.
  • Service catalogs. Facilitators publish lists of paid resource, each entry gives the endpoint, its price, the network and token it accepts, and the address that receives the payment. Coinbase's Bazaar is the largest.

Each source works differently and covers a different slice. Merging them, and keeping them in sync as new agents register every day, is a pipeline of its own.

x402 Radar: an AI agent on Base identified from two sources, the ERC-8004 registry and x402 settlement data

Step 3: Classify the settlement rail

Once you have agent wallets, every USDC transfer they're part of needs a label for how it was settled:

  • through a known x402 facilitator, recognized by the addresses that submit its settlement transactions on chain,
  • as an authorized transfer (EIP-3009 or Permit2) submitted by an address that isn't on any facilitator list,
  • as a plain USDC transfer, sent by the payer itself.

This list of facilitators and their signer addresses comes from a public list and from the facilitators' own declarations; it changes over time. It's also what lets you separate spec-correct x402 from the rest when a customer asks.

Step 4: Separate the roles

For each payment, record at least four addresses separately:

  • the payer (from the Transfer event),
  • the receiver,
  • the submitter (tx.from, often a facilitator),
  • the agent's owner at that block, if the payer is a registered agent.

The last one needs point-in-time data. Agents change owners, sometimes minutes after they're created, so today's owner isn't necessarily the one who controlled the agent when it paid.

x402 Radar: a real x402 payment on Base, split into payer, receiver and the Coinbase facilitator that settled it

Step 5: Backfill, then stay live

x402 activity started months ago, so the first job is reading history: registry events from the start, and every transfer of every agent wallet since. After that, the index has to stay close to the head of the chain, wait for enough confirmations to be safe from reorgs, and keep catching up when RPC providers rate-limit reads, which they do.

The two jobs compete for the same infrastructure. Getting backfill and live indexing to coexist without gaps is the unglamorous part that decides whether the data can be trusted.

Step 6: Go multi-chain

x402 runs on several networks. We cover Base, Ethereum and Polygon today, with Solana coming up next. Each chain brings its own registries, facilitators and indexing quirks, and non-EVM chains don't use EIP-3009 at all, so the rails look different. Treat each new chain as its own integration, not a config change.

Common pitfalls when indexing x402 payments

  • Using tx.from as the payer. With facilitators in the middle, it usually isn't.
  • Treating all volume as demand. Chainalysis traced a surge in late 2025 largely to PING, a pay-to-mint meme coin where every mint was an x402 payment. TRM points out that scripts, load tests and self-dealing leave the same on-chain record as an agent. Volume isn't adoption.
  • Assuming the registry is complete. Registration is voluntary, and not every agent is in a registry.
  • Trusting self-declared metadata. Agent names and descriptions say whatever their authors want.
  • Thresholds built for humans. With payments around a cent, anything tuned for human-sized transfers will miss what's happening.

How x402 Radar covers x402 payments

The biggest players have research teams that can take this on. Most analytics providers don't, and their customers will ask the same questions anyway.

Meanwhile it's the same work we've been doing for the past five years, for Elliptic among others, across more than 56 chains: new sources, completeness checks, attribution and continuous monitoring. x402 is just a new kind of payer to apply it to.

x402 Radar is where we've put it together. It finds agents from registries and catalogs, follows their wallets, classifies how each payment was settled and separates payer, receiver, submitter and owner, on Base, Ethereum and Polygon. You can use it as a data source via API, or we can build the same capability into your own stack.

FAQ

What is x402?

x402 is an open payment protocol that uses HTTP status code 402, "Payment Required", to let software pay for APIs, data and services on its own, usually in USDC. It's maintained under the x402 Foundation and is one of the main rails for agentic payments.

How does an x402 payment work on-chain?

A client requests a paid resource, the server replies with 402 and the price, and the client signs a payment authorization, typically an EIP-3009 transferWithAuthorization on USDC. A facilitator verifies it and settles it on-chain, usually paying the gas. On-chain, the result is a plain USDC transfer: the payer is in the Transfer event, and tx.from is usually the facilitator.

What is an x402 facilitator?

A service that verifies a client's signed payment authorization and settles it on-chain on the server's behalf. It usually submits the transaction and pays the gas, so its address, not the payer's, appears as the transaction sender.

What is EIP-3009 transferWithAuthorization?

EIP-3009 is a token standard, implemented by USDC, that lets a holder authorize a transfer with an off-chain signature. Anyone holding that signature can submit it on-chain by calling transferWithAuthorization. That's how x402 facilitators settle payments and pay the gas on the payer's behalf.

Why do x402 payment statistics differ so much?

Because they count different things. Some trackers count spec-correct x402 payments, others count all payments made by AI agents, and they filter noise differently. Chainalysis counted well over 100 million agentic payments on Base through Q1 2026, while TRM Labs estimated that only 0.6% to 7.5% of filtered x402 settlements looked like AI agents.

Which chains support x402?

x402 is designed to work across chains. It runs on EVM networks such as Base, Ethereum and Polygon, and also on non-EVM chains such as Solana, where settlement works differently because there's no EIP-3009. x402 Radar covers Base, Ethereum and Polygon today.

Want to walk through the pipeline with the engineer who built it? Book a 20-minute demo of x402 Radar →

Did you find it interesting? Schedule a call with one of our experts and discover tailored solutions designed specifically for your needs.

November 3, 2026