Endpoint Trust Score methodology

How an append-only probe history becomes a reproducible verdict, and what a single identified vantage cannot see.

Methodology: Payfetch · Trust Score · Token Safety

This is the methodology behind the Endpoint Trust Score. The score is a pure function of an append-only history of periodic probes: same history slice in, same score out, forever. It is served as one x402 call, GET /v1/trust/score?url=<endpoint> ($0.005) at api.forum-labs.com, with /v1/trust/report adding the underlying history detail for $0.02. The weights, bands, and gates below are frozen and versioned (thresholdsVersion: p2t-score-1.1.0) and stamped on every score, so anyone holding the same history can recompute the same number. A rating you cannot recompute is marketing.

What we measure

Every score is built from what the prober actually observed, cycle by cycle: whether the endpoint answered, how fast, whether its advertised terms held, and whether it presented a well-formed payment challenge. Most of this comes from the endpoint's unpaid x402 handshake (the HTTP 402 challenge), which costs nothing and reveals the advertised terms.

ComponentWeightWhat it captures
Availability0.50Does it respond over time, from confirmed observations only, weighted by wall-clock time.
Latency0.15p50/p95/p99 from raw timings; the score bands the p95 tail an agent pipeline actually feels.
Terms stability0.20Advertised-price drift, plus a change of payment recipient (custody), which is flagged, never averaged away.
Challenge integrity0.15Does it present a well-formed, parseable payment challenge.

Today's score comes from the unpaid handshake above. A capped, fully-paid settlement spot-check, paying the advertised price like any customer, is on the roadmap; until it ships, the score says so about itself (see the single-vantage disclosure).

How the score is computed

The four components combine on a 0-to-100 scale at the weights above. The parts that make the score honest rather than a rolling average are the availability weighting, the rating gate, and the caps.

Time-weighted availability

Availability is weighted by wall-clock time, not by probe count. Each observation is integrated over the interval it represents, so a long outage counts as the days it lasted, not the handful of times we polled during it. A failure on our side (network, timeout, rate-limiting) is recorded as ours and excluded; an endpoint is never marked down for our infrastructure. An endpoint that is confirmed down or gone drives availability toward zero, so it cannot coast on a stale average.

The rating gate: enough evidence, or unrated

An endpoint is only rated once its confirmed history is decisive enough to carry a verdict. The gate is a Jeffreys (Beta) 95% confidence interval on the observed success fraction, so a lucky handful of good probes cannot earn a reliable rating. Too little history returns unrated with a reason, never a fake-neutral number. When the evidence is decisively bad, an endpoint can be rated unreliable early (marked provisional) rather than sitting unrated while a known-bad endpoint looks unjudged.

Caps that a high average cannot override

The bands, so you can recompute

The latency and terms-stability components map their raw inputs to a 0-to-1 sub-score through frozen bands. They are published here so a third party holding a history slice can reproduce a score exactly:

Latency (p95, ms):   ≤500 → 1.0 | ≤1500 → 0.85 | ≤4000 → 0.6 | ≤8000 → 0.3 | else 0.1
Terms drift (count): 0 → 1.0 | 1 → 0.8 | 2 → 0.6 | ≤4 → 0.3 | else 0.1

These bands are not evadable in any way that helps a seller: the only way to improve a latency band is to be faster, and the only way to improve terms stability is to actually stop churning your price and recipient. The score rewards behaving well, which is the point.

Verdicts

From the capped score:

VerdictRule
reliablescore ≥ 80
mixedscore ≥ 50
unreliablebelow 50
unratedtoo little history to judge, or the operator opted out; no score, never a fake-neutral number

The endpoint always answers. When history is thin, the score endpoint returns unrated with the reason. It does not hide a missing verdict behind an error or a paywall, and it does not invent a middling number to fill the gap.

What a single vantage cannot see

Every score carries the standing disclosure single_vantage_identified_probe. We probe from one region (us-east-1) with an honest, self-identifying User-Agent and, today, without paying. That means the score cannot by itself detect an endpoint that deliberately serves our identified prober differently than it serves real paying buyers (targeted discrimination or cloaking). We deliberately do not disguise or rotate the prober's identity. That would break the good-citizen commitment and is an unwinnable single-vantage arms race. The real differential is the paid settlement spot-check on the roadmap: a probe-healthy-but-paid-failing endpoint is exactly the gamed case, and a failed paid delivery caps the score. Latency, likewise, is a single-region measurement and is labeled as such; multi-vantage is future work.

Operators

The monitor identifies itself honestly (User-Agent forum-labs-trust-prober) and is a good citizen: conservative cadence, exponential backoff, and it honors 429 / Retry-After. We probe only endpoints publicly listed on public directories, in the manner they advertise for consumption.

Re-probe, correction, or opt-out: email ops@forum-labs.com. Opt-outs are honored within 24 hours and return unrated; corrections are appended to the record (append-only; we never silently edit it).


Forum Labs · Payfetch · Trust Score · Token Safety · Methodology · GitHub · ops@forum-labs.com · @shopforumlabs
© 2026 Forum Labs. Not financial advice. Metrics are informational and mechanical.