Methodology

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.

What the score claims — and does not claim

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.

Scoring rules

Three public data feeds enter each score:

• the x402 Bazaar catalog (the subject roster and declared terms),
• on-chain settlement transfers for the subject's pay-to address (30-day window),
• a daily 402 handshake probe of the subject's endpoint.

Wash-trading detection

Two deterministic graph rules mark settlements as washed:

1. Self-dealing (one-node loop): the paying wallet is the seller's own pay-to address.
2. Funding-loop (two-node loop): the seller has transferred funds to a buyer wallet at any point in the window; all purchases from that buyer are counted 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.

Metrics

• 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.

Verdict thresholds

• 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

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:

• catalog entry (always present — every scored subject comes from the catalog): 0.1
• settlement data readable: 0.6
• handshake probe completed: 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.

Data sources and licensing basis

• x402 Bazaar catalog — read via the CDP Bazaar discovery API: the official public discovery layer, no API key required, designed to be machine-read.
• On-chain settlement transfers — public blockchain data, read via the CDP SQL API free tier. Honest current state: Base settlement data is read daily; Solana settlement data is not yet queried (the dataset's column structure is not publicly documented) — for subjects settling on Solana the settlement feed is treated as missing, confidence is discounted accordingly, and the verdict cannot reach trusted.
• 402 handshake responses — public HTTP responses of catalogued x402 endpoints, equivalent to reading a public web page header; no technical protection is circumvented.

No commercial API data is resold; no raw data is forwarded — only judgements computed from it are sold.

Freshness, coverage, and failure honesty

Scores are recomputed on a recurring schedule and carry their computation time in updated_at. Answers older than 24 hours are never sold. The catalog is processed in bounded batches, so coverage is partial: a subject that has not yet been scored gets the ANSWER_UNAVAILABLE envelope (503 semantics, with a machine-readable retry_after), not an improvised answer.

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.

Probing disclosure

To verify that a counterparty can deliver today, this service probes catalogued endpoints in three layers, acting as a buyer over the public protocol:

• L1 — 402 handshake probe (active): free, daily, checks availability and the declared price/schema. Responses are treated as untrusted input (size- and time-capped).
• L2 — free-teaser test call (planned): where the target offers a free tool, call it to verify the real response format. No payment involved.
• L3 — paid spot-check (planned, not yet active): real purchases verifying delivery, hard-capped at $2/month, targets picked from observed demand.

Probe wallet address

TBD — the independent, small-balance wallet used for L3 purchases will be published here before L3 activates.

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.

Bootstrap settlement disclosure

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:

1. The bootstrap wallet address is disclosed on this page and the transaction hash is published here once executed.
2. Our own score self-marks it: the transaction is excluded from our own real_buyer_count, and our public score honestly shows the bootstrap transaction's existence.
3. It happens once and is never repeated. Staying indexed requires real third-party settlements; if none arrive, we accept delisting rather than repeat a self-purchase.
4. The transaction is never used in any claim of existing sales or adoption.
5. The transaction executes in the same change that publishes its disclosure — no transact-first, disclose-later.

Bootstrap wallet address

0xAcf3944E771Ea8e662b2c2c9622D8B5299eBf1d3

Bootstrap transaction hash

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.

Scoring ourselves

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.