Free, automated reputation scores for x402-paid API endpoints — built for AI agents deciding whether an endpoint is worth paying.
Most reputation numbers online just ask you to trust the source. x402Score doesn't: every day's full scoring dataset is cryptographically fingerprinted, and that fingerprint is anchored on a public blockchain (Casper — currently testnet) — so if this data were ever quietly altered after the fact, anyone could catch it, without needing to trust us at all. See /transparency for exactly what this proves and how to verify a given day's data yourself.
x402Score crawls the public x402 Bazaar catalog, probes each listed endpoint on a schedule, and computes a 0-100 score / A-F grade from how it actually behaves in practice — not from anything the provider self-reports.
GET /leaderboard → HTML, every scored endpoint ranked by score
GET /leaderboard.json → JSON, the same data as above
GET /score/:endpointId → JSON { score, grade, sampleSize, confidence, scoreInterval, riskFlags, recommendation, catalogAgeDays, categoryPercentile, signature, lastUpdated }
GET /score/:endpointId?asOf=YYYY-MM-DD → historical, checkpoint-backed score for that UTC date — see /transparency
GET /score/:endpointId/full → paid ($0.005 USDC via x402), full audit breakdown + recent raw probes
GET /paid/score/:endpointId/history?days=30 → paid ($0.01), daily score history (up to 90 days) + weekly on-chain buckets
POST /paid/scores/full { items } → paid ($0.05), full breakdowns for up to 100 endpoints in one call
GET /paid → free, what can be bought and whether payment is live on this deployment
GET /calibration → JSON, is the scoring formula actually predictive?
GET /checkpoints → JSON, recent daily tamper-evidence checkpoints
GET /checkpoints/:date → JSON, one day's full snapshot + hash — see /transparency
GET /openapi.json → the full machine-readable API contract
POST /submit { url } → add an endpoint to be monitored (rate-limited, 5/hour/IP)
See /transparency for what the daily checkpoint mechanism proves and how to verify a given day's data yourself.
endpointId is the first 16 hex characters of SHA-256(endpoint URL) — deterministic, so
you can compute it yourself instead of looking it up.
A TypeScript SDK (x402score-sdk) and an MCP server exposing these as agent
tools both exist but aren't published anywhere yet — see GET /openapi.json for
the full contract in the meantime.
Scores are built from how an endpoint actually behaves over time: whether it responds correctly, how consistent that behavior is, and how it compares to similar endpoints — not a simple pass/fail on the most recent check. Endpoints with little history are scored cautiously rather than swinging to a perfect or a failing grade on a single lucky or unlucky probe. The exact formula and weighting aren't published, to keep the score meaningfully harder to game than a documented checklist would be.
The leaderboard shows a TRUSTED / CAUTION / HIGH RISK verdict alongside the numeric score and grade — TRUSTED means a score of 75+ with no catalog-gaming flag; anything flagged (see below) is never shown as TRUSTED regardless of score. Browse or search by vertical (Finance, DeFi, Crypto, Supply Chain, E-commerce, and others), inferred from each listing's own description — a coarse heuristic, not a real taxonomy, so expect some miscategorization.
See GET /calibration for an ongoing, aggregate check on whether higher
scores actually correspond to better real-world outcomes — that's published, since it's
a claim about the score's honesty, not a recipe for gaming it.
When configured, every score is signed (secp256k1/ECDSA — the same curve Ethereum and
Base use) at the moment it's computed. GET /score/:endpointId includes
signature, signedAt, and detailHash (all
null if signing isn't configured on this deployment, or for a score computed
before it was); the signing address(es) — current and retired, for keys that have been
rotated — are published at GET /.well-known/x402.
What a valid signature proves, precisely: authenticity of origin and integrity of transit — the data really was produced by x402Score and hasn't been altered since, whether it reached you directly or through a mirror, cache, or MCP tool result. What it does not prove: that the score is correct. A compromised deployment holding the real signing key could still sign false data — a signature attests "the holder of this key produced this," not "this is true." Every signed score is also appended to a write-only transparency log, so tampering (a score quietly changed after the fact) is detectable by anyone comparing history against what's public now, even though it can't be prevented in real time.
The x402score-sdk package includes verifyScoreResponse() so
consumers don't have to hand-roll verification.
recommendation on /score/:endpointId is a derived
convenience — "pay", "avoid", or "uncertain" — for
callers who want a single field to branch on instead of building their own threshold
logic. It's conservative by design: "pay" only when the credible interval's
lower bound already clears a C grade (not the point score), and any
riskFlags forces "avoid" regardless of score. It's recomputed
live from the other fields on the same response, not stored or scored itself — treat it
as a starting point, not a substitute for reading scoreInterval and
riskFlags directly if your use case needs more nuance.
The scoring formula's weights are deliberately not re-tuned casually. Changes are
driven only by the ongoing calibration process (see GET /calibration) and
require multiple consecutive weekly reports agreeing before anything ships — not a
single week's result, which could be noise. In practice this means a given endpoint's
score should not swing because the formula changed underneath it more than a
few times a year, and any such change will be reflected in this project's changelog.
Day-to-day movement in a score reflects the endpoint's own behavior, not the scoring
method shifting — that stability is what makes it safe to build automated
pay/avoid logic against recommendation or the raw score without
re-validating your thresholds on every call.
catalogAgeDays is how long x402Score has observed this endpoint
listed — a free proxy for operator/domain longevity that deliberately avoids a
paid WHOIS lookup, while still being hard to fake quickly: an operator can't
back-date when this project first saw their endpoint. categoryPercentile
places this endpoint's score against others in the same category
(0-100, higher is better) — null if the category has too few scored peers yet, or
the hourly cache hasn't populated. Both are informational fields on the response,
not inputs to the score itself.
riskFlags on /score/:endpointId (and the ⚠ badge on the
leaderboard) surfaces a separate signal from the score itself: whether a listing shares
its payout wallet or its exact description text with several other listings in the
catalog — a pattern more consistent with one operator dumping many near-identical
endpoints than independent, legitimate services. This does not currently affect the
numeric score or grade; it's an additional flag to weigh alongside it. The exact
thresholds aren't published, for the same reason the scoring weights aren't.
The free API is live and real. The paid tier (see GET /paid for the current list, prices,
and whether payment is live on this deployment) charges per call in USDC on Base via x402 — no account, no API
key. Until payment is enabled on a deployment, the paid routes return a clean "not configured" response rather
than a real payment challenge. The scoring algorithm's inner workings are not published; the paid breakdown
routes are the supported way to see more detail.