This page documents how x402 Counterparty Score computes every field it sells, what data it reads, and where its limits are. A service that sells trust judgements must itself be verifiable: every rule below is deterministic (graph rules over public data — no LLM inference anywhere in scoring), so any third party with the same public data can recompute and check a score.
The score measures economic authenticity: how much of a
counterparty's settlement volume comes from real, independent buyers after
filtering wash trading. It is a 30-day statistical judgement, not a
real-time liveness monitor and not an audit of the counterparty's code or
team. A trusted verdict means the on-chain evidence is
consistent with real demand; it is not a guarantee of future delivery.
Three public data feeds enter each score:
Two deterministic graph rules mark settlements as washed:
Deliberate strictness: rule 2 also catches legitimate refunds, which are then misclassified as wash trading. We accept this false-positive bias — deterministic and verifiable beats generous and unfalsifiable for a trust metric. Known limitation: multi-hop funding loops (three or more wallets) are not yet detected; the wash-trading ratio is therefore a lower bound.
wash_trading_ratio = washed settlement volume / total
settlement volume, rounded to 4 decimal places.
real_buyer_count = number of distinct buyer wallets
remaining after wash filtering.
repeat_buyer_rate = share of real buyers with two or more
purchases.
avoid: the 402 handshake probe completed and failed (paying
would not produce delivery), or wash_trading_ratio ≥
0.5 (the majority of
nominal volume is fake).
trusted: requires all of — settlement data present, the
handshake probe completed with the endpoint reachable and its pay-to
address matching the catalog, wash_trading_ratio ≤
0.1, and at least
5 distinct real buyers.
Missing any input feed caps the verdict at caution.
caution: everything else.
confidence is an objective data-completeness measure — a
fixed weighted sum of which input feeds were available for this subject,
never self-reported by an LLM or any other model:
0.1
0.6
0.3
A score computed from all three feeds has confidence 1.0; a score with
settlement data missing can be at most 0.4. Low confidence means missing
data, and missing data never convicts: it caps the verdict at
caution rather than forcing avoid.
trusted). Base
settlement data is read on a rolling schedule paced by the upstream
free-tier quota, so per-subject refresh times vary; a score is sold only
if refreshed within the past 24 hours, and a settlement history too
large to read completely in one pass is treated as missing for that
subject — never sold as a partial slice.
No commercial API data is resold; no raw data is forwarded — only judgements computed from it are sold.
Every score carries its computation time in updated_at, and
answers older than 24 hours are never sold. Scores reach that freshness
bar by two paths. A recurring batch schedule keeps frequently requested
subjects warm; it processes the catalog in bounded batches, so on its own
it covers only part of the catalog at any moment. When a paid request
names a subject whose stored score has aged past 24 hours, the score is
recomputed on the spot for that one subject and served at zero age — the
same rules, the same sources, no improvised answer. Such scores carry an
on-demand marker in the source field.
Coverage limits are still real and stated plainly. On-demand recomputation
is offered only for subjects already present in our catalog-derived shelf,
and its settlement coordinates come from the subject's live 402 handshake
— so it applies to x402 endpoint URLs, not to bare pay-to addresses. A
subject outside those limits gets the
ANSWER_UNAVAILABLE envelope (503 semantics, with a
machine-readable retry_after) rather than a guess.
The pipeline is fail-closed: if an upstream feed fails validation, the affected scores are delisted rather than re-served with a fresh timestamp. When any error envelope is returned, no payment is settled — an unavailable answer is never charged for.
To verify that a counterparty can deliver today, this service probes catalogued endpoints in three layers, acting as a buyer over the public protocol:
0x0033cE3c8E1eA57439a5c15f106EF4274c07A5Ee
— the independent, small-balance wallet used for L3 probe purchases.
Probing disciplines: probe purchases are self-marked in our own data and
are not counted toward the target's real_buyer_count; probe
responses are handled as untrusted input; and this service will never
probe-purchase its own tools.
The x402 Bazaar only indexes a service after its first successful
settlement. To be discoverable at launch, this service will perform a
single disclosed bootstrap settlement: one real x402 payment to
score_x402_counterparty from a wallet we control. This is the
only transaction of its kind, and it is governed by five published
disciplines — violating any one of them would make it wash trading:
real_buyer_count, and our public score honestly shows the
bootstrap transaction's existence.
0xAcf3944E771Ea8e662b2c2c9622D8B5299eBf1d3
0x9b29f10ffd9ac21136da31fa0780cdbed5ade48d2e58028bcb60ca4ab4b66b97
The wallet address was published ahead of execution; the transaction hash above was filled in the same change that executed the bootstrap settlement on 2026-07-10 (discipline e: no transact-first, disclose-later). It settled $0.02 USDC on Base mainnet and is the only transaction of its kind, ever.
This service's own pay-to address is in its own catalog data, so it scores
itself by the same rules. Scores about ourselves carry a
;self=true marker in the source field, the
bootstrap settlement is excluded from our own
real_buyer_count, and a low real_buyer_count on
our own score is an honest state, not an error.