What machine commerce claims — and what actually happens

Some machine-payment routes are presented through a gateway: a company that lists routes carrying other organisations’ names on its own hosts and returns the payment terms for those routes — x402.orthogonal.com/<name>/… or <name>.mpp.tempo.xyz, for example. Of the 16,118 routes on the September route list (on 1,950 hosts), 1,315 on 91 hosts sit under four gateways — Orthogonal (965 routes on 3 hosts), Locus (240 on 67), Tempo (96 on 17) and Sponge (14 on 4) — most of them carrying another organisation’s name in the route’s address. The quotes, catalogue fields and supplier replies point to the same limitation: the company name on a gateway route does not identify who controls the quoted payment address, or what commercial relationship sits behind the route.

675 of the 1,315 routes returned a valid payment challenge containing a payable quote — the machine-readable response showing that a price was offered, not that anything was paid — on at least one reading between 4 and 30 September.

• On Locus, Tempo and Sponge, all 134 quoting routes used gateway-level payment addresses, whatever name the route carried: one address across Tempo’s 67 quoting routes, one across Sponge’s 14, and one per payment rail across Locus’s 53.
• On Orthogonal, 541 quoting routes under 54 names quoted 42 addresses. No name used two addresses; four addresses were shared between names. Neither the quotes nor the catalogues say who controls them.
• No quoting route on any of the four gateways changed its payment address during the window. Most of Orthogonal’s routes are read weekly (906 of 965, two to four readings each in the window); the rest of the layer is read daily (about 27 readings each).

Between 16 September and 1 October we wrote to 59 suppliers whose names appear on gateway routes, asking whether the route, its price or its payment address was theirs. 55 messages were delivered and ten suppliers replied:

• Six wrote that they had not set the routes up or do not offer machine payments at all — one after an internal engineering review, two qualifying their answers, one answering just that it has no machine-payment setup.
• One wrote that the price and the payout address were the gateway’s, and that it was checking how the integration had been arranged.
• One, whose name a fifth gateway carries, wrote that the gateway is its partner, by the supplier’s own arrangement, and that the payment address is the gateway’s.
• Two others: one wrote that it was unsure whether the routes carrying its name were its own, and one asked what our message referred to.

The replies include a listing its supplier arranged and listings suppliers say they did not set up; neither the route nor its quote discloses which of the two a buyer is paying. On one route carrying the name of a supplier that wrote that it does not operate the route, a $0.005 payment settled to the quoted address and a response came back on each of four weekly calls, two of them after the supplier’s statement. These are each supplier’s statements about its own arrangements, not a measurement of authorisation; two other suppliers on Orthogonal show Orthogonal’s logo on their own home pages (read 2 October).

The listings moved; the payment addresses did not. Orthogonal’s x402 routes in the Bazaar, on its two x402 hosts, fell from 460 in the complete read of 8 September to 127 in the read of 10 September, and stood at 145 on 30 September. Of the 328 Orthogonal routes in our list that the Bazaar carried on 5 September and not on 30 September, 325 were read after they left, and all 325 still returned a valid payment challenge on their latest reading; Sponge’s 11 departed routes did the same.

The 640 routes that gave no price on any reading are outside the payment-address findings above. Our reads were unpaid requests with no body or key, and most of those routes answered with an error (HTTP 400 or 404).

In September, health labels and catalogue listings changed sharply. Among endpoints we independently read, many continued to return valid payment challenges across those changes.

Observability providers (e.g., 402index, PulseFeed, vet402) publish health labels and counters that agents can use to choose a route. Their figures, from our dated reads of their published surfaces, with one comparison of ours:

• 402index’s labels moved by tens of thousands in two days. Its health document, which we capture daily, read degraded 43,554 and down 17,051 on 7 September, and degraded 13,070 and down 54,741 on 9 September, while its total grew 0.8% (105,267 to 106,115). Its own daily series shows the same break (degraded_endpoints 39,295 → 13,619 → 13,048 on 7, 8 and 9 September). Neither the document nor the series carries a note saying what changed. On 30 September it labelled 41,286 endpoints healthy, 15,771 degraded, 58,874 down and 478 unknown, of 116,409.
• 402index’s labels against our readings. This is a cross-period comparison, not a same-time error rate: the labels are from 2 October and the readings from 4–30 September. We compared the 14,346 endpoints we graded in September with the labels 402index’s public search returned on 2 October. For 11,065 a single label could be matched: 2,475 were labelled degraded or down and 8,590 healthy. Of the 2,475, 1,664 (67%) returned a valid payment challenge on every reading we took — a median of 25 readings each; 718 of them were read on all 27 days, and 598 fewer than five times. Of the 8,590, 76 (0.9%) never returned one. The other 3,281 had no single label to match: 2,690 on hosts where its search was still returning rows when our read stopped, 498 on hosts whose rows disagreed, 81 not listed and 12 unknown.

The Bazaar’s complete daily read held 16,162 routes on 5 September and 19,111 on 30 September (+18%). Between those two reads, 496 hosts carrying 2,694 routes disappeared, 737 hosts carrying 7,472 routes appeared, and the hosts listed on both dates carried 1,829 fewer routes. Four operators each lost more than 300 routes:

Six operators grew from nothing, or from a single route, to 300 or more routes each: syntexa, rallylive, edge-agents (the one from a single route), saylorinnovations, openverbs and unykorn (3,915 routes on 30 September). magentlab’s 844 routes left the catalogue on 8 September, and all 844 were listed again by 30 September.

Of the 3,153 daily-read x402 routes in our list that the Bazaar listed on 5 September and not on 30 September (on 864 hosts), 2,732 were read after they left. 2,383 of those (87%) still returned a valid payment challenge on their latest reading, and 2,176 did so on every reading after leaving (a median of ten). Of the daily-read routes listed on both dates, 4,426 of the 4,522 read (98%) did.

Across every cadence, 6,140 routes in our list left the catalogue between the two reads, on 904 hosts; 1,883 of them were not read again before 30 September — most of them monthly-read rows, which include nearly all of the two largest exits. Neither catalogue read says why any route left. Separately, on our read of 2 October no Bazaar entry’s last recorded call (lastCalledAt) was older than 30 days (the oldest of 22,016: 29.97 days).

Our September paid calls carried no inputs. Each was one fixed request — the route’s URL, with no query string and no body — sent once a week for four weeks to a published panel of 400 x402 GET routes priced at or below $0.05 (at most two per host, a third chosen as top sellers), drawn on 6 September from 4,308 quoting endpoints on 705 hosts; 366 were called in all four weeks. What the record establishes is about request handling and settlement order, not a delivery rate.

132 routes answered a paid call with HTTP 400 (486 calls). 126 of them declare the missing input in their own payment challenge — 94 mark it required in the challenge’s schema, 32 carry it in the example call. Four more named in the error an input their challenge never declares, and two needed a payment identifier the challenge does declare. Because the paid panel sent no inputs, it does not establish how these 132 routes would answer a request carrying every declared input.

Of the 141 routes that never answered with content and whose errors trace to an input our request lacked, 132 never settled a payment and nine settled before returning the error (35 calls). These 132 are a different set from the 132 HTTP-400 routes above: that set is counted by status code, this one by outcome. One of the nine sent the payment back within a block each time (4 calls).

Of the remaining 225 routes called every week, 194 returned content on every call (for six of them our reader could not decode the settlement notice in the response; the transfer is on chain), and 18 returned content on some of the four calls but not all. Seven never returned a usable answer, for reasons not attributable in the record to an input declared in the payment challenge: three failed upstream, two demanded an API key their challenge never declares — after taking the payment — one answered empty by policy, and one took the payment and asked for it again. Six more were never paid by us or could not be assigned an outcome from the retained record.

For 54 of the 889 payments we found on chain, no transaction identifier could be read from the response; they sat on 19 endpoints, 18 of which never gave one in four weeks. A buyer reading the response alone could not confirm that money had moved.

vet402, which buys from listed routes to grade them, publishes 11,278 paid attempts, 6,022 settled and, of those, 5,397 delivered — by its own definitions (read 2 October). Its corrections log records that from 17 September it stopped counting against a seller a refusal of a request vet402 had formed wrongly; its 30-day export to 16 September held 2,487 paid attempts ending with no transaction and a 4xx other than 402 (2,157 of them HTTP 400), on 1,975 endpoints.

A facilitator verifies a buyer’s payment and settles it on chain on the seller’s behalf. The leaderboard figures below are x402-trust’s own, as computed on 5 October over its trailing 30 days, on our capture of that day. x402-trust revised its figures for 20 of the 32 facilitators it tracks between our captures of 2 and 3 October — its own all-time totals for them fell; these are its figures after that revision. The shares are our calculation over its rows; the discovery-surface and seller-disclosure figures come from our own dated reads.

• The leaderboard tracked 32 facilitators and attributed at least one settlement in its 30 days to 19 of them. It declares its Base and Solana coverage complete and its Polygon coverage backfilling, and counts every USDC transfer whose transaction sender is a known facilitator settler address; that is its definition.
• On x402-trust’s own figures, Coinbase carries 55.7% of the volume30dUsd summed across those 19 ($950,681, our sum), and Coinbase, FluxA and Meridian together 89.9%.
• Dollars and settlements30d sit with different facilitators: PayAI carries 33.2% of the leaderboard’s settlements30d and 4.5% of its dollars, Figment 28.8% and 3.1%; Meridian carries 14.7% of the dollars and 0.1% of the count.

On our anonymous reads of 5 October, nine of the 19 answered at their own discovery surface with a list of what they support, from 2 payment kinds on 2 networks to 162 on 84; four list a scheme other than exact (upto, batch-settlement and escrow among them). A list is what a facilitator advertises, not a claim that a payment on it would settle.

On 30 September, 50 of the 1,478 hosts that quoted a price carried a facilitator-related identifier — a fee payer, facilitator address or facilitator URL — in the payment option at the head of their challenge. Of the 26 distinct identifiers, 20 resolve to Coinbase in the public facilitator registry, one to PayAI and five to no registry entry. Among the 21 that resolve to a registry entry, 20 resolve to Coinbase. The undisclosed share is unknown, not Coinbase.