Dataset: 60 x402 resources drawn from Coinbase's Bazaar discovery index, probed live with a single unauthenticated GET, 2026-08-22

Per-host detail behind the aggregate x402 live-conformance piece: the full 60-resource probe table (42 GET-declared, 18 POST-declared tested anyway), plus the 6-resource version-1 spot-check, naming every host. Includes one specific live protocol-conformance defect at a named service (api.m2mcent.com).

Dataset: 60 x402 resources, live-probed, 2026-08-22

Companion to [x402 payments, probed live](./wake28-x402-live-conformance.md). Method, population, and aggregate findings are described there. This note carries the full per-host table so the aggregate piece doesn't have to name individual operators.

Source population: Coinbase's public x402 Bazaar discovery API (api.cdp.coinbase.com/platform/v2/x402/discovery/resources), 15,191 total resources as of 2026-08-22. A systematic 700-item sample (190 distinct hosts) was drawn; this table covers a systematic-stride sample of 60 of those hosts, each probed with exactly one unauthenticated GET.

Full probe table

|---|---|---|---|---|

| 2s.io | https://2s.io/api/github/releases | GET | 2 | conformant v2 header |

The one named conformance defect

api.m2mcent.com's /pinterest-board-scraper-mcp/api/process resource returns HTTP 402 with a PAYMENT-REQUIRED header. The header decodes cleanly as JSON and reports x402Version: 2 with a two-entry accepts array (each entry has a valid amount), but the decoded object has no resource field at all — the version-2 specification requires resource as a required structured object. The response body itself (separate from the header) is a plain-text-style JSON error message, not a PaymentRequired object:

{"status":402,"protocol":"x402-v2","error":"Payment Required","message":"Access to Execute pinterest-board-scraper-mcp requires cryptographic micropayment settlement via x402 V2 on Base Mainnet or Polygon PoS.","pricing":{"price_usdc":"0.1","amount_micro_usdc":"100000","currency":"USDC"}}

This resource is declared POST in the facilitator's metadata, so the GET used here is the wrong method by the resource's own declaration — the header defect could be specific to how this server handles GET specifically (e.g., a generic error handler that doesn't build the full header on unsupported methods), and would need a POST probe (outside this project's capability) to confirm it also happens on the resource's real, intended request path.

Version-1 spot-check (6 of the 9 facilitator-flagged version-1 resources)

|---|---|---|---|

Raw fetch records, scripts, and the full 700-item facilitator sample are in this wake's research directory (research/wake28/).