Collection method · updated 3 October 2026
A notebook of observations. With its limits attached.
Pulse periodically asks public APIs what they return before payment. We preserve daily summaries and publish fingerprints so you can check whether an export agrees with its original commitment.
How endpoints enter the sample
The registry combines a small seed list with an hourly selection from the facilitator’s Bazaar catalogue. The current selector takes up to 150 resources, preferring those with published prices, then resources with unknown prices, in returned catalogue order. New automatic admissions stop at 1,000 known endpoints; existing history is never evicted to make room. Anonymous status checks return a result without adding to the archive. Paid checks can also contribute observations, so the admission cap is not a total storage guarantee. Several seeds are our own services and are labelled as self-observations.
This is a changing, biased sample—not a representative census of x402. The tracked-endpoint total can include previously discovered endpoints and is not the number probed in one sweep. Catalogue ordering, availability and changes in selection can affect comparisons.
What a probe means
The default scheduler starts a sweep every ten minutes, with four concurrent GET requests. Configuration, restarts, request timeouts and overlapping sweeps can leave gaps. A result describes that request at that moment; it is not continuous uptime monitoring. A POST-only service may reject our GET even when its intended workflow works.
Automatic paid purchase loops are disabled. These observations do not test purchase settlement or paid content. Passive recognition of a draft-0.2.0 x401 proof-request header is kept only as a small allowlisted summary in recent probes. It does not validate credentials, establish adoption or enter the timestamped daily archive.
Probe change on 3 October: from the hardening release, redirects are reported without following them, and connection-time DNS answers must be public unicast. Earlier probes followed redirects. This change can affect results within 3 October; it does not change record encoding or by itself establish record integrity.
Three collection eras
56 historical days do not reproduce their original record commitments. The original roots remain preserved. They are disclosed as unverifiable, not rewritten to manufacture a match.
2 October 2026: repair transitionThe replay defect was repaired during this day. Even if its final records match, it contains observations from both sides of the repair and is excluded from fully repaired-day examples.
3 October 2026: collector compatibility incidentA mismatch between the production runtime’s built-in HTTP client and our connection guard produced false network failures. Original records remain preserved, but this day is excluded from usable evidence.
4 October 2026 onward: repaired candidate days4 October can first be checked after it closes at 00:00 UTC on 5 October. A day counts only after its exact record root and count, authenticated issuer, intact commitment chain and externally sourced Bitcoin timestamp pass the reference checks. A pending timestamp is not a pass.
Reproduce the checks
Use the free reference checker with the actual UTC date and an explicitly selected completed-day window. Keep the downloaded evidence. Do not overwrite earlier captures. Missing records, unknown endpoints and pending proofs must remain insufficient evidence.
The canonical format remains version 1; this explanation does not change historical commitments. The cross-language test vector is synthetic test data, not a verified production day. Retention uses the current persistent disk without automatic expiry; it is not a guarantee of permanent availability.
Live integrity report · Machine-readable methodology · Reference checker source