
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.

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.
On EVM chains, the flow has four steps:
transferWithAuthorization on USDC. The other route is a Permit2 signature.
Two consequences for anyone indexing this:
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.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.
If you've ever added a new chain to an analytics product, most of this will feel familiar.
This sounds trivial and isn't. There are at least two reasonable definitions:
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.
If you count agent payments, you first need to know which addresses belong to agents. There's no single source:
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.

Once you have agent wallets, every USDC transfer they're part of needs a label for how it was settled:
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.
For each payment, record at least four addresses separately:
Transfer event),tx.from, often a facilitator),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 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.
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.
tx.from as the payer. With facilitators in the middle, it usually isn't.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.
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.
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.
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.
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.
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.
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 →
