This week the x402 ecosystem got a storefront. Agentic.market — a directory of x402-enabled services, operated by Coinbase and presented as an "app store for agents" — now headlines 2,980 services. We are in it. So instead of arguing about it from the outside, we queried its public catalog and checked our own row, field by field, against our live 402. What that exercise shows is a clean line between two things that both call themselves a marketplace: an index, and a market.
What it is, pinned to the source
- Agentic.market describes itself as "a directory of x402-enabled services that agents can call with pay-per-request pricing in USDC," with "no registration, no API keys, no rate limits."
- Its footer is explicit about ownership: x402 is owned by the Linux Foundation, and the marketplace itself is operated by Coinbase and is not an official x402 Foundation product.
- There is a read-only public catalog:
GET https://api.agentic.market/v1/servicesand.../v1/services/search?q={query}, both documented inhttps://agentic.market/llms.txt. - The network figures — roughly 69,000 active agents, 165M+ cumulative transactions, $50M volume, ~85% settling on Base — are self-reported by Coinbase (CDP engineering lead Erik Reppel) and carried by several outlets. We did not independently verify them, and neither should you.
Note the actor: the storefront is the protocol steward's own commercial product, built on a standard it governs through a foundation. That is fine to build — but it means the storefront's incentives and the standard's neutrality are not the same thing.
Our own row, measured
GET /v1/services/search?q=minia2a returns exactly one record — minia2a-uk, domain minia2a.uk, network eip155:8453 — carrying 20 endpoints. We probed all 20 against our live challenges on 2026-10-03:
| check | result |
|---|---|
| endpoints indexed | 20 |
answer 402 with a payment challenge |
20 / 20 — no dead links |
| indexed price equals our live 402 amount | 18 / 20 |
| indexed price differs (their snapshot is stale) | 2 (loan, hash: index says 0.01 USDC, live is 0.5) |
| service category in the index | empty string |
| service description in the index | empty; endpoints show auto-generated "minia2a service: x402-<id>"
|
| submission path to fix any of the above | none documented on the site or in llms.txt
|
Two things are true at once, and it is worth keeping them apart. First, rail-level interoperability is real: every endpoint answers their crawler with the standard challenge, so a wallet configured for their storefront can mechanically pay ours. That is the protocol working as intended.
Second, the row is thin. No category, no description, two prices frozen at a value we stopped charging, and duplicate entries for several services (the index carries both /x402/hash and /x402/x402-hash; both resolve, because the gateway tolerates one doubled prefix — duplicates, not breakage, but each keeps its own counters and nothing merges them). The two stale prices are not our error: our catalog and our live challenge agree with each other for both endpoints. Their figure is a snapshot from the last observation, and it ages at its own pace. We cannot edit it, because an index has no provider-facing edit surface.
What an index does, and what a market does
This is not a criticism of indexing. Indexing is a hard job — crawl a federation of facilitators, normalize wildly different endpoints into one schema, at scale. 2,980 services is real work. But an index and a market answer different questions, and conflating them is how buyers get hurt.
| question a user actually has | index | curation / market |
|---|---|---|
| Does a service with this capability exist? | yes, best effort | yes |
| Is this price the price I will be charged right now? | only as fresh as the last crawl | checked against the live challenge |
| Can I try it before paying? | no concept of a trial | trial path is a first-class rule |
| Who answers when a row is wrong? | nobody; the row is auto-derived | a named operator, with the row under a check |
| Is there a category I can trust? | only if the crawler inferred one | set by the listing's own metadata |
The difference is not engineering quality. It is who answers for the row. An auto-derived listing can only ever be as good as its crawl, and no crawl knows whether a price moved, whether a seller is reachable, or whether two entries are the same service behind a path alias. Those are exactly the questions a buyer has.
If you build on top of any index: treat the row as a lead, not a contract. Fetch the live
402before you commit a payment decision. The challenge is authoritative; a directory entry is a memory of one.
What this changes for us
Not much about the rail — we settled on the same one and it works. What it sharpens is why a curated, agent-first storefront exists next to a very large index: not to be bigger, but to be answerable. Every price we publish is the price our own live challenge returns; if it drifts, a check fires rather than a user discovering it. Trials are a rule, not a row attribute. When a service goes stale, the remedy is on our side of the table.
The honest summary of the week is not "an index launched and threatens us." It is that the layer everyone is racing to own — discovery — has at least two shapes, and only one of them can be held to a number. We would rather be small and answerable than large and unaccountable.
Measurement note: the Agentic.market figures were read live on 2026-10-03 from api.agentic.market (our row) and from public reporting for the network-wide numbers, which are marked self-reported. Our own prices were compared against our live 402 challenges and our catalog, which agree. No end-to-end settlement through a third-party facilitator was tested for this post, and we make no claim that we did.
Top comments (0)