42,748 Paid Agent Endpoints Are Listed. 7,866 Have an Outside Buyer.

You picked paid agent endpoints for a workflow by reading what each one does. The listing page said 42,748 paid endpoints are available. That number is not the market you are buying from, and the gap between the two is large enough to change which services you pick.

Of those 42,748 listed paid endpoints, 7,866 have been paid by more than one distinct entity. That is 18.4%. The rest have a single payer or none, and a single payer is ordinarily the operator calling their own service.

This is not a claim that the other endpoints are fake. A service listed last week has had no time to acquire a second buyer, and a genuinely good new endpoint starts in exactly that position. The single-buyer tier contains legitimate new entrants alongside listings that will never find a customer, and the measurement cannot separate them. What it tells you is narrower and still useful: 18.4% of the listed market has been chosen and paid for by someone other than the person who built it.

What the settlement layer looks like

In the trailing week, 294,985 USDC transfers landed at agent payment addresses across 1,305 distinct services. The single largest recipient accounts for 32.5% of all those transfers.

That measurement comes from Coinbase telemetry we ingest, not from our own probe, so it reflects their view of settlement on their own network. Treat it as a floor on real activity rather than a census, and do not read it as broad-based: 32.5% of measured flow reaching one recipient is the opposite of broad.

The operational consequence is correlated failure. If several endpoints in your workflow settle through the same concentrated path, a repricing or an outage at that recipient moves all of them together. Your service count says you diversified. Your settlement exposure may not have.

The proxy you can actually check

We do not publish per-entity transfer volumes, so you cannot look up which tier a given endpoint settles in. Any guide claiming otherwise is selling you precision that does not exist in the data.

What is checkable is provenance. Every endpoint in the index carries the source registry that listed it, and registry concentration runs in the same direction as settlement concentration: the largest single source registry accounts for 27.4% of all indexed resources. Registries are not neutral directories. They tend to sit alongside the payment rails and operator relationships of whoever runs them, so endpoints sharing a registry are more likely to share infrastructure beneath it.

So the audit is: for each endpoint your agent depends on, record the source registry. If your distinct vendors all trace back to the same source registry, or to a pair of them, you have correlated exposure that your vendor count concealed. Fixing it means deliberately sourcing from a different registry, accepting that the alternative registries are smaller and the selection is thinner.

Where this leaves the selection problem

Two filters, applied in order, carry the bulk of the work.

First, narrow to endpoints with evidence that someone other than the operator has paid them. 2,259 hosts carry at least one verified on-chain payment in our index. An endpoint outside that set is not disqualified, but it is unproven at the payment layer, and you should treat it as a candidate you are testing rather than a dependency you are trusting.

Second, spread the survivors across source registries. This is the step that gets skipped, because registry provenance reads like metadata rather than risk. It is risk.

Neither filter tells you whether an endpoint is good at its job. They tell you whether it is real and whether your dependencies are genuinely independent of each other. Capability assessment is a separate exercise and no measurement substitutes for calling the thing and reading what comes back.

The listing count will keep growing faster than the paid-by-a-stranger count, because listing is free and earning a second buyer is not. Price your expectations against 7,866, not 42,748.