How PulseFeed audits the x402 ecosystem and computes trust · Observatory · State of x402
PulseFeed is an independent trust & safety layer for x402 agent payments. We don't take a listing's word for it — we probe every endpoint ourselves, verify the payment receiver on-chain, and track behaviour over time. This page explains exactly how, because a trust oracle you can't inspect isn't one.
We continuously crawl x402 catalogs (Coinbase CDP Bazaar and 402index), then independently probe each endpoint: a live GET that expects an HTTP 402 with a well-formed accepts[] payment requirement (scheme, network, asset, payTo, amount). An endpoint counts as live only if it returns a valid x402 challenge — not merely if a catalog says so. Probes rotate across the pool daily, always re-checking known-live services and exploring new candidates.
For a probed endpoint we combine independent signals:
| Signal | Effect |
|---|---|
| Live & valid x402 challenge | base of the score; dead/invalid caps it low |
| Uptime / history of past probes | consistent liveness raises trust |
| Cross-source (listed by ≥2 catalogs) | corroboration raises trust |
| Response latency | fast, healthy responses add a little |
| Receiver stability over time | a stable payTo raises trust; a volatile one lowers it |
| On-chain receiver profile | a battle-tested receiver adds; a fresh/unproven one subtracts |
| Security flags (below) | a high-severity flag overrides everything → avoid |
The score maps to a verdict: safe (≥70, no serious flags) · caution (works, but incomplete data or minor flags) · avoid (dead, invalid, or a serious security flag).
Beyond "is it alive", we scan for reasons not to pay:
| Flag | What it catches |
|---|---|
payto_changed | the receiver address changed vs a stable history — possible takeover/hijack |
payto_missing | zero/absent payTo — funds would go nowhere (honeypot/misconfig) |
price_bait_switch | the endpoint charges far more than its listed price |
price_rising / price_high | price crept up over time, or is unusually high per call |
asset_not_usdc / network_asset_mismatch | payment demanded in an unexpected token or on a mismatched network |
payto_unverified_onchain | the payTo has no on-chain history of receiving USDC — unproven by payments |
Flags are network-aware (EVM and Solana) and self-correcting: a receiver that rotates addresses by design is distinguished from a one-off swap once enough history accumulates.
We check the advertised payTo directly on Base: is it a contract or EOA, does it hold USDC, has it actually received USDC payments, and how old is it as a receiver. This yields a profile — established (holds/receives USDC), active, dormant (no USDC held), or fresh (unproven) — a signal no catalog provides.
We record what each catalog claims (e.g. 402index's health_status) and compare it to our independent probe. The gap — services listed as "healthy" that don't actually return a valid x402 challenge — is published live on the State of x402 report. Typically only about half of listed-healthy endpoints truly work.
Every probe appends to a per-endpoint time series (verdicts, payTo changes, price changes) and a daily ecosystem snapshot. This history cannot be reconstructed after the fact — it is why longevity strengthens the oracle rather than commoditising it.
Use it: free cached verdict GET /verify?endpoint=<url> · live deep check GET /trust?endpoint=<url> · track record GET /trust/history?endpoint=<url> · drop-in guard npm i pulsefeed-x402-guard.
Machine-readable: /status.json · /reports.json · /openapi.json · /llms.txt