I was chasing a new host in the Coinbase CDP discovery index — a provider-named x402 subdomain under a billing-infrastructure platform that had appeared overnight — and what I found instead is a better signal about where agent payments are going than the single endpoint I'd gone looking for.
That subdomain belongs to a billing-infrastructure provider. Their agent-readable catalog (llms.txt) lists ~43 brand-name APIs — frontier LLMs, a 10-billion-entity knowledge graph, independent web search, speech-to-text, browser automation, SEC filings, security and sanctions lookups, sales-intelligence enrichment. The kind of catalog that a year ago would have taken a dozen separate integrations.
And then the part that matters: the same catalog is published three times, once per payment protocol.
The catalog index has three parallel sections, each pointing at the same providers with the same descriptions:
| Rail | How the agent pays | Account needed |
|---|---|---|
| x402 Services | Base USDC, pay-per-call | None |
| MPP Services | Tempo machine-payment protocol | None |
| Wrapped APIs | The provider's own on-chain wallet | None |
Every provider file exists at three paths — /x402/, /mpp/, and a wallet-wrapped path — with byte-for-byte the same service description. A buyer who wants the knowledge-graph endpoint can reach it over x402 with USDC, over MPP with a Tempo payment, or through the provider's own wallet rail. Same capability, three settlement mechanisms.
On top of those three "no-account" rails sit two more product layers over the same catalog: a metered-credits layer for platforms that re-price the catalog for their own users, and a non-custodial agent wallet with spend limits. Five ways to consume one catalog.
For the past year the x402-versus-MPP question has been framed as a standards competition — which payment protocol wins. What a billing layer like this shows is a third outcome: nobody has to win, because the billing layer absorbs the choice.
When one operator can expose the identical catalog over x402, MPP, and its own wallet with the same effort, the protocol becomes an implementation detail — like choosing a database driver. The buyer's agent doesn't care which rail settled the payment; it cares that the capability is reachable, the price is legible, and the endpoint answers.
This is the rails-commoditization thesis made concrete. Settlement, the 402 challenge, wallets, gasless facilitators — all of it is becoming infrastructure that a billing layer can just offer three versions of. The parts that don't commoditize are the ones on the other side of the payment:
The payment rails are being solved — fast enough that a single billing layer can now sell the same catalog three ways at once. That means the durable differentiator in the agent-payment stack isn't "which protocol do you speak" but "how does an agent find a live endpoint, try it, and trust what it gets back." Discovery, trial, and verification don't have three interchangeable versions.
That's the problem minia2a works on: an open catalog where an agent can discover a pay-per-call API, try it before it pays, and get back a real 402 with a real price — regardless of which rails keep commoditizing underneath.
Build agents that discover, try, and pay for APIs per call.
Explore minia2aData: the provider count and the three-rail catalog structure are read directly from the billing provider's agent-readable llms.txt (fetched 2026-08-29), which lists ~43 unique providers on the x402 rail and mirrors the same list under MPP and wrapped-API sections. The ~2.6%/day discovery-churn figure is from my own consecutive-daily observer of the Coinbase CDP discovery endpoint.