# Market402 > The verified index of the 402 economy. Every listing is scored by real probes - availability, latency, x402 spec compliance, and price integrity - not by self-reported or on-chain volume (which can be gamed). ## For agents - /index.json: machine-readable verified index with 402 Scores - /methodology: how 402 Score works (v0) - POST /submit {"resource": "https://your-service/endpoint", "declared_price_usd": 0.01 (optional)}: get listed (instant spec feedback + verified by next probe round). Declaring your base price makes price integrity measurable even before Bazaar lists you (v0.4) - POST /selftest {"url": "https://..."}: free x402 compliance self-test (402 challenge, accepts[] schema, network naming, EIP-712 extra) with machine-readable fixes. Also a human page at /selftest - /optin.json: sellers opted in to paid delivery probes (rules in /methodology) - /operators.json: operator-level aggregation (sub-domains grouped, shared hosting split per seller) - /reports: measured monthly statistics of the 402 economy (primary data; /reports/YYYYMM.json) - /status.json: when we last probed, how much, and what we spent (the verifier is verifiable) - /search.json?q=ocr : capability search over the probed census (multi-word AND; tags like ocr, document-parsing, web-extraction, company-data, verification). Every result is a real, probed resource - use this instead of guessing service names. Human page: /search - /llms-full.txt: everything above plus the full scoring methodology in one fetch Operated by Mart402 (https://mart402.com). Operator-provided services are flagged operator-provided and scored by the same automated rules. ## Current census (updated 2026-07-29T03:10 UTC) - endpoints probed: 14843 - operators: 1034 - spec-compliant endpoints: 6635 --- # Full methodology (also at /methodology) # 402 Score - Scoring Methodology (public document) Market402's credibility as a verification layer depends on the transparency of its methodology. This document is public; every change to the scoring logic is recorded here with a version and date. ## Principles 1. **Measured only.** On-chain volume and self-reported metrics are never used (both can be gamed). Every score derives from facts observed by Market402's own probes. 2. **Reproducible.** Every score can be traced back to the underlying observation records (timestamp, request, response code). 3. **Conflict of interest disclosed.** Services operated by our own operator (Mart402) are flagged `operator-provided` and scored by the same automated rules as everyone. Manual score adjustments are prohibited for all services. ## v0 - four axes (measurable with unpaid probes) | Axis | How it is measured | Points | |---|---|---| | Availability | Response success rate of weekly probes (402/200 = alive; timeout/5xx = failure), last 4 rounds | 40 | | Latency | p50 time to the 402 challenge. <500ms = full points, >5s = 0, linear in between | 20 | | Spec compliance | x402 schema of the 402 body (x402Version, accepts, payTo, amount, network) | 20 | | Price integrity | Listed price vs the live 402 challenge price; stability of the price history | 20 | - Displayed as 0-100 plus a grade (A >=85 / B >=70 / C >=50 / D <50) and the last-observed timestamp. ### v0.1 revision (2026-07-21) Spec compliance (20) split into three parts: base schema 10 + network name format 5 (v1 requires a plain name like `base`; CAIP-2 `eip155:*` is a v2 form that official v1 SDK clients cannot pay) + presence of the EIP-712 `extra` block 5. ## Probe conduct (v0.2, revised 2026-07-26) Revision note: unpaid probe frequency raised from "1-3 rounds/week" to the tiers below, to improve badge freshness and time-series density. Per-request behavior is unchanged (no payment attached, one request per probe, robots respected). - **Full universe** (every resource in the public Bazaar catalog plus self-submitted services): probed **weekly**. - **Index head** (Verified, opted-in, top-500 by score, and self-submitted services): probed **daily** (once per day per service - well below common uptime-monitor rates in this ecosystem). - Same-operator resources are probed serially, never in parallel, so providers with many endpoints see at most one concurrent request from us. - A weekly **census snapshot** of the full catalog (counts by network, method, price band; entries and exits) is retained as a public time series and feeds the monthly reports at /reports. - Paid delivery probes remain **at most monthly per service, <=$0.05 per probe**, opt-in prioritized, with a rotating monthly sample of the qualifying pool (seeded by calendar month, so the sample is reproducible), under a **$3/month hard budget cap**. - Explicit User-Agent: `Market402Probe/0.1 (+https://market402.com; verification probe)` (paid probes: `Market402PaidProbe/...`). - Unpaid probes attach no payment. A healthy x402 service returns 402 before any side effect; a design that performs side effects before the 402 is itself recorded as a compliance deduction. - Frequency is limited (1-3 rounds/week, a few requests per service). robots.txt and explicit probe opt-outs are respected; opted-out services are shown as "unverified". - Paid probes run under preset budget caps and identify themselves as test calls in the User-Agent. ## 402 Verified badge (2026-07-21) Three tiers, decided only by Market402's measurements - never by self-reporting: Criteria (v0.3, 2026-07-26 - delivery evidence required): - **verified**: 402 Score >=70, x402 spec compliant, >=5 observation rounds spanning >=14 days, price integrity >=90% (where measured), **and a successful paid delivery to the operator within the last 60 days** (we bought a listed endpoint at list price and a valid result was delivered; evidence bundle retained). - **verified-plus**: 402 Score >=85, correct v1 network name, EIP-712 extra present, price integrity >=95%, >=8 rounds spanning >=30 days, **and the operator's last 2 paid deliveries both succeeded**. - **none**: everything else (including compliant services not yet old enough or not yet delivery-proven). Notes on v0.3: - Delivery evidence is **operator-level** (we purchase one qualifying endpoint per operator per month) and **expires after 60 days** - the badge is continuously re-earned, never permanent. - We deliberately do **not** cap the number of badges. The criteria themselves bound it: a badge requires a recent real purchase, so the badge set can never exceed the operators our paid probes actually cover. - Transition: resources that held the badge under v0.2 on 2026-07-26 are exempt from the observation-span requirement until 2026-09-01 (the delivery requirement is NOT waived); they are probed with priority during the window. Distribution: the index page badge column, `GET /badge/{domain}` (live verification JSON), `GET /badge/{domain}.svg` (embeddable image), and `GET /verified.json` (an agent-facing allowlist). ### Displaying the badge (verified operators) Embed the badge on your site so visitors can verify your status with one click: ```html 402 Verified - measured by Market402 ``` Replace YOUR-DOMAIN with your operator domain (e.g. `example.com`). The image is generated live from the current scoring run: if the badge lapses (delivery evidence expires after 60 days, or checks fail), the URL returns 404 and the image stops rendering - the badge cannot be displayed stale. The link target returns the machine-readable verification (badge tier, score, methodology), so anyone can audit the claim. Badge benefit (2026-07-26): Verified holders are **guaranteed a monthly paid delivery probe** - their listing carries measured "we actually bought it" evidence at no cost to them. The benefit is earned by measurement; it cannot be purchased. Monetization policy: listing is free (neutrality). Any future paid offering will be of the form "guaranteed monthly re-verification" or "featured placement" - the badge itself is never for sale, because measured trust is the product. ## v1 addendum: the delivery axis (paid probes - rules published 2026-07-23) **Rules first, operation second.** We publish the measuring stick before we start using it. ### Definition - **delivery**: for requests actually paid via x402, the rate at which (a) HTTP 200 is returned and (b) the response is valid for the service's category (non-empty, type-consistent, passes hallucination checks). - Measurement: at most monthly per service, <=$0.05 per probe, read-only idempotent endpoints only. An evidence bundle (payment tx, receipt id, response hash, latency) is retained so every result is auditable. ### Scoring integration (v1 weights - only for services with delivery data) | Axis | v0 | v1 | |---|---|---| | Availability | 40 | 30 | | Latency | 20 | 15 | | Spec compliance | 20 | 20 | | Price integrity | 20 | 15 | | **delivery** | - | **20** | - **Scope (v1.1, revised 2026-07-26).** A paid probe is an ordinary customer purchase of a publicly listed API at its listed price. Like unpaid probes, paid probes therefore cover **every qualifying listed service** (read-only GET, <=$0.05, idempotent, valid input constructible from the listed schema); an explicit probe opt-out is always respected. Coverage tiers: - **Opted-in sellers** (`paid_probe_optin: true` via `POST /submit`, roster at `/optin.json`): guaranteed every month, probed first. The guarantee applies to **qualifying** endpoints; the `/submit` response reports your qualification status with a machine-readable reason and fix hint. If your listed schema is not probeable (non-GET, or placeholder example values), you may declare a safe `sample_input` ({method, queryParams, body}) in your opt-in - we will probe with your declared request instead. The per-probe price cap and the side-effect screen are never waived by declaration. - **402 Verified holders**: probed at the highest cadence the paid-probe budget supports - currently every month - as a badge benefit, earned by measurement and never for sale. (If the verified set ever outgrows monthly capacity, the cadence stated here will be updated rather than silently degraded.) - **All other qualifying services**: monthly rotation covering the full qualifying pool, processed in small daily batches to keep load polite. When the delivery axis is published, the observation count n is always shown next to it. (v1.0 said probes ran only for opted-in sellers; superseded because buying a listed public API at list price requires no special consent, and full coverage makes the axis fair rather than selective.) - **Disqualification.** Two consecutive observations of "payment settled, result not delivered" set delivery to 0 and revoke the 402 Verified badge. The listing is annotated with the observed facts (a record, not an accusation). The annotation is removed once a re-verification confirms recovery. - **Dispute procedure.** On a non-delivery observation: preserve the evidence bundle -> machine-readable notification to the service -> re-probe after 48 hours -> if still failing, apply the rule above. The procedure is published here precisely so that it cannot be applied arbitrarily. ### Self-assessment vs measurement (important) Passing the free self-test at `market402.com/selftest`, or the `instant_check` returned by `POST /submit`, has **no effect** on the delivery axis or the 402 Verified badge. Badges and scores derive solely from Market402's own scheduled probes. ## Operator-provided listings (v0.3.1, added 2026-07-26) Market402 is operated by the same company that runs Mart402 (mart402.com and its sandbox mart402.dev). Policy for those "operator-provided" listings: 1. **Same rules.** Operator-provided endpoints are discovered, probed, scored and ranked by the same automated pipeline as every other listing. No special treatment exists in the code, in either direction. 2. **Machine-readable disclosure.** Every operator-provided row carries `"operator_provided": true` in /index.json, /operators.json and /search.json, and an "operator" chip on human pages. 3. **No self-awarded badge.** 402 Verified requires delivery evidence from real paid purchases. For operator-provided services that evidence would be circular (the operator would be paying itself), so operator-provided listings are **not eligible** for the Verified badge regardless of their measured numbers. Their scores remain published, and anyone can reproduce them by probing the endpoints directly. A consequence: operator-provided rows never benefit from verified-first ranking. Reason for the change (2026-07-26): buyer-side experiments showed agents rely on this index when selecting services. Completeness requires listing our own endpoints; honesty requires that the one circular evidence path (self-paid delivery) can never mint a badge. This rule will be revisited if third-party attestation of delivery (e.g. on-chain attestations by independent verifiers) becomes available. ## Price integrity sources (v0.4, added 2026-07-26) Price integrity compares the amount actually demanded in the live 402 challenge against a published reference price. Reference sources, in priority order: 1. The listing's own `accepts[].amount` as published in the x402 Bazaar (unchanged - this has been the source since v0). 2. NEW: a price the operator declares at submission time. `POST /submit` now accepts an optional `declared_price_usd` (USD per call, the base price an unpaid probe should be quoted). The latest declaration per resource is used for every subsequent probe round. A mismatch against either source lowers the score in exactly the same way. Declaring a price is optional; resources with no reference price from either source keep `price_integrity: null` (unmeasured, 0 of 20 points - see "Score axes" below). Changelog reason (2026-07-26): self-submitted listings previously had no measurable reference price, which structurally capped them at 80 points. Declared prices give every self-submitted operator the same published-vs-actual honesty measurement that Bazaar-listed operators already face. ## Score axes visibility (v0.4, added 2026-07-26) Every resource row in /index.json now carries `score_axes`: `{"measured": [...], "unmeasured": [...]}` over the four axes (availability, latency, spec_compliance, price_integrity). An axis in `unmeasured` contributed 0 points because it could not be measured - not because the service failed it. Agents comparing scores should prefer rows whose axes are fully measured, or compare only over shared measured axes. ## Delivery watch (v1.2, added 2026-07-26) A paid probe that settles payment but receives no valid result ("paid, not delivered") is the single worst buyer outcome, so it gets its own flag, separate from the score (scores remain pure measurements; we do not mix penalty points into them). - Entry: an operator has at least one paid-not-delivered event in the last 60 days, with no successful paid delivery after it. - Cure (automatic): a later successful paid delivery, or 60 days elapsing, or the operator fixes the endpoint and a later paid probe succeeds. Entry and cure are both decided only by recorded probe evidence - there is no manual judgement in either direction. - Effects: 1. `delivery_watch: true` (with evidence: date, resource, amount) on the operator in /operators.json and on each of its rows in /index.json and /search.json. 2. Ranking: pages sort Verified > clean > delivery-watch. A watch-flagged operator never outranks a clean operator regardless of score. 3. Badge: watch implies no current successful delivery, so the operator is ineligible for 402 Verified until cured (this restates the v0.3 delivery requirement explicitly). ## Ranking tiers and tie-breaks (v1.3, added 2026-07-26) List pages (/ and /search) and /operators.json rank operators in four tiers: 1. **402 Verified** (badge holders). 2. **Operator-provided, criteria met**: operator-provided listings (see "Operator-provided listings") are never awarded the badge, but the same automated badge algorithm is still evaluated on them, shadow-fashion, with no other differences. If it passes, the listing ranks directly below all badge holders and above listings without the badge, marked `verified_criteria_met` (machine-readable) instead of a badge. The delivery evidence used for this evaluation comes from the operator's own disclosed calibration purchases (real on-chain settlements, published in the spend ledger), which is exactly why it earns a rank position but never the badge. 3. **Clean**: everything else. 4. **Delivery watch** (see "Delivery watch (v1.2)"). Within a tier: score median, then number of verified endpoints, then number of endpoints. The verified-endpoint tie-break (new in v1.3) keeps an operator with 7 verified endpoints above one with 1 verified endpoint at equal score; total endpoint breadth alone no longer wins ties in the Verified tier. Transitional badges: badges whose observation-period requirement is satisfied only by the published 2026-09-01 transition roster are marked `badge_transitional: true` and annotated "transitional until 2026-09-01" on list pages. The delivery requirement is never waived. Path-template listings: some catalogs list route templates (URLs containing `:param` or `{param}` segments) rather than callable URLs. Probing them can only produce artifacts (typically 404), so from v1.3 they are marked `unprobeable: "path_template"` and excluded from operator score aggregates (median, range). They remain visible as endpoints. ## Probe vantages (v1.4, added 2026-07-27) Market402 probes from more than one network location ("vantage") to report latency as agents in different regions would experience it. Vantages: - **eu-central** (Falkenstein, DE): the primary and historical vantage. Every score and every historical observation is measured from here. - **us-east** (Ashburn, US): a secondary vantage added 2026-07-27, head-probe only (no payment), for supplementary US-perspective latency. Rules that protect the time-series (the point of a verified index): 1. **Scoring uses only the eu-central vantage.** The 402 Score, badges, and all historical continuity derive from eu-central observations exclusively. Adding a second vantage never changes a score. This keeps the time-series unbroken. 2. **US latency is supplementary, not scored.** Resources carry an optional `latency_p50_ms_us` field alongside `latency_p50_ms` (which stays eu-central). Agents can compare US-vs-EU latency; neither is a scoring input beyond the existing eu-central latency axis. 3. **Every observation records its `vantage`.** Machine-readable, so the source of each latency figure is auditable. 4. If the eu-central box is ever lost and the index is promoted to us-east (see operational recovery), the vantage change is announced here with a date, because a verifier that quietly changes how it measures is not a verifier.