How vet402 measures

How vet402 buys, what it counts against a seller and what it does not, how grades are given, and how to check a signed record without trusting vet402.

Method v3 (2026-09-29) · report 2026-10-07 · purchases 2026-09-27 to 2026-10-07 (UTC) · change log

1. How vet402 pays for this

Grades come only from vet402's own purchases. vet402 also sells paid checks (paid in USDC on Algorand or Base); a paid check is a separate report and never moves a grade. No listing fee, no paid placement, no referral cut. The ranking reads only the purchase files listed in data/manifest.json, and on Algorand those purchases were paid from a different wallet than the paid checks. Call counts, payer counts and anything a seller reports about itself are not inputs, so a seller cannot buy a better place by paying itself (wash trading).

2. What is counted, and what is not

Counted = delivered purchases plus failures on the seller's side (payment settled, then 5xx, 402 again, no answer or an empty 2xx; or the seller's server answered 5xx). A settled payment followed by another 4xx is not counted: vet402 built that request from the seller's listing, so a fault on vet402's side is not ruled out. Paid on chain, answered 402, delivered nothing is counted on the seller's side, also when a facilitator error such as "already in ledger" came with it: the buyer paid and received nothing, and the seller chose the facilitator. Not when vet402's request carried a placeholder from the catalog instead of a value: then the 402 may come from that input, and it can't be told.

Not counted, shown as numbers: failures on vet402's or the facilitator's side, failures where the cause can't be told, endpoints that were not buyable, vet402's own skips (price cap, input it will not make up, duplicates) and refusals because payTo changed.

A failed purchase gets the first rule that matches, top to bottom. Only seller-side rules lower a grade.

  1. 1. can't tell · paid_then_402_placeholder · this report: 4
    vet402's payment settled, then the seller answered 402, and the request vet402 sent carried a placeholder from the catalog in place of a value (such as "string"). The 402 may come from that input, so it is not counted against the seller.
  2. 2. seller side · settled_not_delivered · this report: 8
    Paid on chain, answered 402, delivered nothing: vet402's payment settled on chain (a facilitator error such as "already in ledger" included), then the seller answered 402. The buyer paid and received nothing.
  3. 3. vet402 or facilitator side · paid_then_4xx_vet402_input · this report: 46
    vet402's payment settled, then the seller answered 400, 404 or 422, and the request vet402 sent was wrong: a placeholder from the catalog in place of a value (such as "string"), a parameter the catalog marks required left out, or no input while the seller's answer says the input was wrong.
  4. 4. can't tell · paid_then_4xx · this report: 38
    vet402's payment settled, then the seller answered 4xx other than 402 (400, 401, 404, 422, 429 …). vet402 built the request from the seller's listing, so a fault on vet402's side is not ruled out. Shown as a count, as in the signed records (UNCLEAR).
  5. 5. seller side · paid_not_delivered · this report: 55
    vet402's payment settled, then the seller answered 5xx, nothing, another non-2xx that is not a 4xx, or 2xx with an empty body.
  6. 6. vet402 or facilitator side · rate_limited_429 · this report: 605
    HTTP 429. vet402 bought many items from one seller within minutes; one ordinary purchase would not hit the limit.
  7. 7. vet402 or facilitator side · subcent_quota · this report: 363
    subcent_quota_exceeded: vet402's many sub-cent purchases used up the per-payer quota.
  8. 8. vet402 or facilitator side · payment_tx_rejected · this report: 31
    The payment transaction vet402 built was rejected before settling: simulation failed, BlockhashNotFound, already in ledger, validity window passed, facilitator unavailable.
  9. 9. seller side · server_error_5xx · this report: 60
    The seller's server answered 5xx and no settlement happened.
  10. 10. can't tell · timeout · this report: 20
    vet402's request timed out. A slow seller and a short vet402 timeout look the same.
  11. 11. can't tell · request_rejected_4xx · this report: 153
    The seller answered 4xx (400, 401, 404, 422 …) before any payment settled. vet402 made the input, so the cause cannot be told apart.
  12. 12. can't tell · payment_not_accepted_402 · this report: 68
    The seller answered 402 again after vet402 paid, with no reason that points to either side.
  13. 13. can't tell · answer_without_settlement · this report: 13
    The seller answered 2xx but no settlement of vet402's payment could be found.
  14. 14. can't tell · unclassified · this report: 0
    None of the above. Counted here so a new failure mode is visible and never lowers a grade.

3. What "settled" and "came back with an answer" mean

Settled: on Solana, Tempo and Base the runner checked vet402's payment on chain before recording it as settled. On Algorand, settled means the facilitator returned a successful settlement receipt with a tx id (the paid field of the vet402-algorand census); vet402 has not read those payments back on chain.

Came back with an answer = vet402's payment settled, then the seller answered 2xx with a non-empty body. vet402 did not check that the answer is what the listing promised; whether its keys matched what the seller declared is a separate column. The same test on every chain, except the Tempo census purchases (tempo/ledger), whose runner kept no body: for them it means settled, then 2xx. The Tempo re-purchases (remeasure) record the body size and are tested for an empty body.

Separate column, never part of the grade: whether the answer's keys or shape matched what the seller declared. Checked only where the runner compared them (Algorand census, Solana census) and the seller declared something.

4. Grades and rank numbers

95% Wilson score interval of delivered / counted (z = 1.96).

Each page is graded from its own chains' purchases only: the first page from Solana, Tempo and Base, the Algorand page from Algorand. A rank number needs at least 10 counted purchases on at least 2 different UTC days on that page's chains. Below that the seller is listed as "measuring", with no grade and no number.

A: lower bound ≥ 0.9. B: lower bound ≥ 0.75. C: lower bound ≥ 0.5. D: upper bound < 0.5. Otherwise undecided. Even 10 deliveries out of 10 have a lower bound of 0.72 (grade C); an A needs about 35 out of 35.

Sellers with a rank number: lower bound desc, then delivered rate desc, then counted purchases desc, then seller name. Equal values share a number. Measuring sellers follow by name.

Fixed (display only, never part of the grade): the latest 3 or more purchases vet402 paid for all came back with an answer, on 2 or more UTC days, and the 2 or more purchases just before them all failed on the seller's side, on 2 or more UTC days. A later purchase that does not come back, whoever was at fault, removes the mark.

This report:
Solana, Tempo and Base: A 0 · B 77 · C 21 · D 2 · ? 1 · … 119
Algorand: A 6 · B 14 · C 2 · D 0 · ? 2 · … 55
Robinhood Chain: A 0 · B 0 · C 0 · D 0 · ? 0 · … 0
Arbitrum One: A 0 · B 0 · C 0 · D 0 · ? 0 · … 0

5. How vet402 buys

From method v2 on: at most 5 purchases per seller in one run, at least 60 s apart. Amounts, payTo checks and money caps are unchanged. The 2026-09-27/28 Algorand runs predate this and bought up to ~500 items of one seller in under an hour. Rebuy plan from UTC day 2026-09-29, with no end date: two runs a day on Solana and one on Tempo, each buying again from the Solana and Tempo sellers whose earlier payment settled, to the same payTo and at no more than the earlier price. Spending is capped per calendar month (70 USDC on Solana, 30 USDC.e on Tempo); a chain that reaches its cap buys nothing more until the next month. The ledger allows one purchase per recipient per slot per UTC day, so where several sellers share one payTo, one of them is bought. Which sellers were bought again is decided by the rows in data/remeasure/, and a correction can change them. Base sellers have been bought once.

Through 2026-10-07, the data holds 1657 purchases bought again from 132 sellers on 9 UTC days (Solana 1393, Tempo 264).

Seller = hostname. When one host fronts several catalog services that each pay their own recipient (a proxy), each service is its own seller: host#service. payTo changed = the same chain and URL asked for a different recipient in a later run, or vet402 refused to pay because the recipient differed from the one it had recorded. One recipient per chain is not a change. Shown as a flag; it does not change the grade.

6. vet402's own record in this report

Out of 4292 tries where vet402 sent a payment (1831 settled on chain, 1148 with a settlement receipt on Algorand), 1045 failed on vet402's or the facilitator's side and 296 had no clear cause. None of them lowered a grade. 2951 purchases were counted: 2828 came back with an answer.

chaintriessettledcame backas de­claredbody test
Algorand235611481138577/672yes
Solana15901489143870/75yes
Tempo338335245–265 of 338
Base877–yes

settled: read back on chain on Solana, Tempo and Base; a facilitator's settlement receipt with a tx id on Algorand. body test: purchases tested for an empty body.

Algorand rows come from vet402-algorand, a separate project; they are graded on their own page.

The numbers on the Check page

The numbers on the Check page add up every page, and all start from a payment that settled ("paid calls"): 3046 settled, 2894 came back with an answer, 152 settled with nothing usable back. By page: Solana, Tempo and Base: 1831 settled, 1690 came back, 141 settled with nothing usable back, out of 1936 tried (2026-09-28 to 2026-10-07); Algorand: 1148 settled, 1138 came back, 10 settled with nothing usable back, out of 2356 tried (2026-09-27 to 2026-09-28); Arbitrum One: 58 settled, 57 came back, 1 settled with nothing usable back, out of 67 tried (run of 2026-09-30); Robinhood Chain: 9 settled, 9 came back, 0 settled with nothing usable back, out of 14 tried (run of 2026-09-30). In all, vet402 tried 4373 purchases; the tries whose payment never settled are counted on each page and in section 6, not on the Check page. Sellers are hosts with a settled payment, counted once across pages.

Settled is not the same on every chain. On Solana, Tempo, Base, Robinhood Chain and Arbitrum, vet402 read its payment back on chain. On Algorand, settled means the facilitator returned a settlement receipt with a tx id; vet402 has not read those payments back on chain. The Check page adds both kinds into one number.

On Robinhood Chain and Arbitrum, a result held until the seller is told is counted as tried only, and in none of the Check page's numbers.

Came back with an answer = vet402's payment settled, then the seller answered 2xx with a non-empty body. vet402 did not check that the answer is what the listing promised; whether its keys matched what the seller declared is a separate column.

Verify a record

For every purchase that came back with an answer, and for other results once the seller has been told, vet402 publishes a signed record (EIP-712, vet402's observation key). Each UTC day's records form a Merkle tree; the day's root is written in a Solana memo by vet402's anchor wallet, and also in a Tempo memo when the records index names one, so a record cannot be added to or dropped from a day later without the root changing.

All signed records, by day · each record page shows how to check it.

npx -y @vet402/check verify obs_2026-09-28_000164

Checks the bytes against the records index, the key, the signature, that the verdict follows from the recorded checks, the Merkle proof, the payment on chain and the memo. A copy of the root kept in a Solana program, for other programs to read: solana-program/README.md. Other ways to verify

7. Mistakes and corrections

A seller who thinks a row is wrong opens a GitHub issue with the URL or tx. vet402 checks it against the chain and the raw result; a wrong row is fixed and the fix is noted in the change log.

GitHub issues · each seller page has a prefilled link.

8. Limits

9. Reproduce

git clone https://github.com/kzmttkc/vet402-delivery
cd vet402-delivery
npm ci
npm run rank -- --data data --offline --out /tmp/rank
npx tsx scripts/build-site.ts --report /tmp/rank/rank-2026-10-07.json --out /tmp/site

The same inputs give the same rank.json (apart from generatedAt) and the same pages. The run only reads files; nothing is signed or sent. Each input and its sha256:

10. Compared with catalog order

Per page, like the grades.

Solana, Tempo and Base

CDP Bazaar order vs vet402

Among ranked sellers the catalog lists (78), "high" = top 39 by l30DaysTotalCalls (sum per host). "High but never delivered" = high and 0 delivered out of every counted vet402 purchase. "Low but always delivered" = not high and every counted vet402 purchase delivered. Counted = delivered or failed on the seller's side.

78
sellers in both
0
high in catalog, never came back (0 after a settled payment)
35
low in catalog, always came back
0.16
rank correlation
High in the catalog, never came back with an answer

none

Low in the catalog, came back every time
  1. tick.twzrd.xyz
    catalog #76 (1 calls/30d) · vet402 #2: 17/17 came back 2o565UXd…KRcKEK
  2. midax402.com
    catalog #75 (1 calls/30d) · vet402 #2: 17/17 came back 2XhoZQpi…xTmZgJ
  3. api.groundtruths.xyz
    catalog #73 (1 calls/30d) · vet402 #2: 17/17 came back 4ZPUDB3A…EZG536
  4. aijobsboom-x402.sonofgus.workers.dev
    catalog #72 (1 calls/30d) · vet402 #2: 17/17 came back 5pQV8X87…Myuupu
  5. x402-crypto-data.vercel.app
    catalog #70 (4 calls/30d) · vet402 #2: 17/17 came back 4Cntt9Fy…FB29bk
  6. kaisha-api.hp-vladic.workers.dev
    catalog #69 (4 calls/30d) · vet402 #2: 17/17 came back 2eNM68A6…9Bj85v
  7. ip402.xyz
    catalog #68 (4 calls/30d) · vet402 #2: 17/17 came back 5TK5FzBg…quhozc
  8. read.lonestaroracle.xyz
    catalog #66 (6 calls/30d) · vet402 #2: 17/17 came back 5isWhMJP…4Udy8e
  9. api.tcgapi.dev
    catalog #63 (7 calls/30d) · vet402 #2: 17/17 came back 295uYyAG…zotDxq
  10. content.hugen.tokyo
    catalog #62 (8 calls/30d) · vet402 #2: 17/17 came back 3hbKu14Z…cGWBwJ

…and 25 more in the JSON.

Mercator order vs vet402

Among ranked sellers the catalog lists (19), "high" = top 10 by best search rank (1 = first). "High but never delivered" = high and 0 delivered out of every counted vet402 purchase. "Low but always delivered" = not high and every counted vet402 purchase delivered. Counted = delivered or failed on the seller's side.

19
sellers in both
1
high in catalog, never came back (1 after a settled payment)
9
low in catalog, always came back
0.29
rank correlation
High in the catalog, never came back with an answer
  1. modal.mpp.tempo.xyz
    catalog #2 (best rank 1) · vet402 measuring: 0/8 came back 0xd8073d…4e011e
    tempo · paid not delivered · sent/http 500
    https://modal.mpp.tempo.xyz/sandbox/exec
Low in the catalog, came back every time
  1. mpp.orthogonal.com#orth-andi
    catalog #14 (best rank 7) · vet402 #79: 10/10 came back 0x1b0e80…d4ce8e
  2. coingecko.mpp.paywithlocus.com
    catalog #19 (best rank 13) · vet402 measuring: 1/1 came back 0x5cb10f…f9d677
  3. groq.mpp.paywithlocus.com
    catalog #18 (best rank 10) · vet402 measuring: 1/1 came back 0x2f3cdd…da3beb
  4. alphavantage.mpp.paywithlocus.com
    catalog #17 (best rank 9) · vet402 measuring: 1/1 came back 0xdb4fbc…faa776
  5. mistral.mpp.paywithlocus.com
    catalog #16 (best rank 8) · vet402 measuring: 1/1 came back 0x235fbb…d5f77f
  6. deepgram.mpp.paywithlocus.com
    catalog #15 (best rank 8) · vet402 measuring: 1/1 came back 0x9a2866…52b85a
  7. edgar-search.mpp.paywithlocus.com
    catalog #13 (best rank 7) · vet402 measuring: 1/1 came back 0xc41cd0…df4a0b
  8. perplexity.mpp.paywithlocus.com
    catalog #12 (best rank 6) · vet402 measuring: 1/1 came back 0xadece5…77750a
  9. openweather.mpp.paywithlocus.com
    catalog #11 (best rank 5) · vet402 measuring: 1/1 came back 0xd2c0ed…e0300d

Algorand

CDP Bazaar order vs vet402

Among ranked sellers the catalog lists (7), "high" = top 4 by l30DaysTotalCalls (sum per host). "High but never delivered" = high and 0 delivered out of every counted vet402 purchase. "Low but always delivered" = not high and every counted vet402 purchase delivered. Counted = delivered or failed on the seller's side.

7
sellers in both
0
high in catalog, never came back (0 after a settled payment)
2
low in catalog, always came back
0.41
rank correlation
High in the catalog, never came back with an answer

none

Low in the catalog, came back every time
  1. api.agentwork.run
    catalog #6 (6 calls/30d) · vet402 measuring: 6/6 came back LKUE5V4D…37JRDQ
  2. midax402.com
    catalog #7 (1 calls/30d) · vet402 measuring: 2/2 came back 2GGS6HT4…PVP2HA

Robinhood Chain

No seller on this page is in a catalog with an order.

Arbitrum One

No seller on this page is in a catalog with an order.

Change log