Corrections

2026-09-17

Counting a seller's refusal of a request we formed wrongly against the seller, because the seller refused before settling

What was wrong. Since 2026-09-05 we held a 4xx as inconclusive, but we applied that to settled payments alone. A seller that checks the request before it settles the payment answers a malformed request with a 4xx and takes nothing; that row was written as settle_failed with no transaction and published in the harsher bucket, next to sellers that charged for the same kind of request and were labelled inconclusive. The sellers who declined to charge us for our own mistake read worse than the ones who charged. Reading the public export (retrieved 2026-09-16T22:27Z, last 30 days): 2,487 paid attempts ended settle_failed, with no transaction and a 4xx other than 402 (400 x2,157, 422 x294, 404 x15, 401 x12, 403 x4, 405 x4, 415 x1), across 1,975 endpoints, against 266 settled attempts answered with a 4xx. Part of the cause was ours in a second way: we sent {} on a POST even when the seller's 402 declared the body it expects in extensions.bazaar.info.input.body, and our methodology said a listing does not tell us the body. A seller, api.insumermodel.com, reported both in public, with its own 2026-09-12 row as the example (github.com/kzmttkc/vet402/issues/29).

What changed. Changed on 2026-09-17. A paid attempt answered with a 4xx other than 402 and no settlement receipt is now held as inconclusive (reason unsettled_4xx), beside the settled case (settled_4xx): it does not count toward a BLOCK or against delivered, and it keeps its status and HTTP code on the endpoint's page. The label follows the reason, not whether money moved. Some of these rows do settle later, when a seller settles and still answers 4xx; the late-settlement recovery then moves them to settled, where they stay held. A POST now sends the body the seller's 402 declares, as declared, when it is a JSON object or array of at most 16 KB, and records which body it sent. The counts ship as l1.inconclusiveByReason on /api/v1/observatory/state, as inconclusiveByReason on the per-endpoint purchases API, and as the held_reason column of export.csv. The decision rules version is now 2026-09-17.1.

2026-09-17

Refuting two real Tempo settlements because our verifier read the memo from the wrong place

What was wrong. vet402 began buying on Tempo through MPP on 2026-09-17. The first two purchases settled on-chain: 0x0883890465be42c6309786c62defb67917e521c6a70252bc6bbeaede264112f5 (aviationstack.mpp.tempo.xyz, 0.005 USDC.e) and 0xbd1049edadb1b676fe51f65246b2b919ffb677ebff10a3d8a3ea6241aede95e8 (fal.mpp.tempo.xyz, 0.04 USDC.e). Each carries a TransferWithMemo from our payer to the recipient the seller's MPP challenge declared, for the exact amount, with the memo we signed. Our settlement verifier marked both settle_claim_refuted (our ledger records the check at 2026-09-17T18:45Z) with the reason nonce_not_used, which reads as the seller claiming a settlement that did not happen. The sellers were right and we were wrong: the TIP-20 event indexes the memo, so it arrives as the fourth topic of the log, and our verifier looked for it in the log data. The tests used a log shape we had assumed, not one read from the chain.

What changed. Changed on 2026-09-17 (UTC). The verifier reads the memo from the indexed topic, with the production receipt of the second purchase as a test fixture, and the settlement indexer declares the event the same way and no longer writes a row when a log decodes without an amount. When we read our ledger at 2026-09-17T21:30Z it held two Tempo purchase rows, these two. Once this change is live we put both rows back to settle_claimed so the corrected verifier checks them again, and we record the result in the public handoff log (docs/handoffs/CHANGELOG.md in the repository). The rows stay published with their transaction hashes, so the receipts can be read from any Tempo RPC with eth_getTransactionReceipt.

2026-09-17

Recording our own empty wallet as sellers refusing payment, 2026-09-13 to 2026-09-15

What was wrong. From the first batch of 2026-09-13 until a manual run at 2026-09-15T23:49Z, the Base wallet vet402 buys from had run out of USDC, and the runner kept signing. Sellers answered those payments with 402, as they should, and we recorded each one as settle_failed against the seller: 972 rows across 965 endpoints in the public export. 402 counts were 0 on 2026-09-12 and 314, 313 and 352 on the three days that followed. Some sellers answered the same unfunded payments with a 5xx instead, and those were recorded the same way: 60 rows across 60 endpoints (500 x50, 503 x8, 502 x2), 17, 27 and 17 on those three days against 0 to 11 on the days around them. 57 endpoints reached zero deliveries on three or more signed attempts in that state, which was then the condition for a BLOCK (since rules 2026-09-29.3 an L1 BLOCK needs a payment that settled without delivery, twice). Nothing checked the balance before signing, and nothing alerted on the change.

What changed. Changed on 2026-09-17. A 402 or 5xx with no transaction on Base from 2026-09-13T00:00Z to 2026-09-15T23:49Z is held as inconclusive with the reason payer_unfunded: it does not count toward a BLOCK or against delivered, it is no longer listed as a loss on /decisions, and the rows stay published. A 402 or 5xx outside that window still counts, because it says the seller did not accept our payment or failed to serve it. The runner now reads the payer's USDC balance on each chain before it signs, once per batch; when the balance is short or cannot be read it does not sign and writes no row, so the seller is picked again in the next batch, and the shortfall is logged. The counts ship as payerUnfunded in l1.inconclusiveByReason and as held_reason in export.csv.

2026-09-05

Naming named companies as having taken payment without delivering, when the failing request may have been ours

What was wrong. Every settled purchase whose paid response was not 2xx was published as settled-and-not-delivered, and the endpoint badge distributed that as a sentence a reader takes as a verdict on the seller. Reading the public export on 2026-09-05: of 1,669 settled rows, 180 answered 4xx or 5xx, and 157 of those 180 (87%) were 4xx — 400 x109, 422 x33, 401 x11, 404 x8, 403 x4. A 4xx means the request that arrived was not one the server would accept, and we buy with an empty JSON body and no API key of the seller's, because a catalog listing declares a URL, a price and a payee and nothing about the body or the credential. The 401s are almost certainly us sending no key. So api.exa.ai/search was carrying a vet402 badge reading '10/10 settled · 0 delivered' — a named company, in our own words, taking money and returning nothing. We could not show that. Our own methodology already held the right rule and we had applied it too narrowly: it said a 400 from a URL we could not have formed correctly is our limitation and not the seller's failure, but only for URLs still carrying an unfilled path parameter.

What changed. Found in our own review and changed the same day. The methodology rule now reads on the request rather than on the URL — body and authentication header included — and settled attempts answering 4xx are published as inconclusive: held, out of the denominator for delivered, and not counted against the seller. Nothing is deleted and nothing is hidden: every row keeps its status and HTTP code on the endpoint's page, the count ships as l1.inconclusive on /api/v1/observatory/state and as inconclusiveCount on the per-endpoint purchases API, and the receipt badge now shows it beside settled and delivered. 5xx is deliberately not covered — a server fault is not something the shape of our request explains. deliveryRatePct is now delivered over settled minus inconclusive, so the attempts we cannot judge no longer weigh as if we had judged them.

2026-09-05

Describing our purchases as covert when they were never covert

What was wrong. The methodology page, the observatory state page, the FAQ and the machine-readable vocabulary all said L1 purchases were made covertly. The implementation never did that. Every request in the pipeline — the unpaid L0 probe, the unpaid read of the 402 challenge, and the paid request itself — has always sent a User-Agent naming vet402 and linking to the methodology page (vet402-observatory-l0/1.0, vet402-observatory-l0-recheck/1.0, vet402-observatory-l1/1.0, each with +https://vet402.com/observatory/methodology). There is no rotation and no override. Three further things would have given us away independently in any case: the payer addresses are one hop from the tx_hash column of our own public export.csv, 44% of purchases land in the same UTC hour, and the priority host list and the sweep window are published on the methodology page by name.

What changed. Found in our own review and changed the same day: the word is gone from every public surface, replaced by what the code does. Naming ourselves is the harder test, not the easier one — a seller that knows exactly who is watching and still takes the payment without delivering has been measured under the best conditions it will ever get. Anyone who wants to check the claim can: the User-Agent is in the request, and the strings are in src/lib/observatory/l1-runner.ts and src/lib/observatory/l0-probe.ts.

2026-09-05

How strong the evidence behind our own settled count is

What was wrong. The observatory published one settled number, as if the 1,629 rows behind it rested on the same evidence. They do not. Signature-nonce binding shipped at 2026-09-04 12:00 UTC; the 1,558 rows that settled before it were confirmed on amount, payee, asset and chain, with nothing tying the transaction to the purchase it was offered for. A seller holding several catalog entries at the same price and the same payee could have answered with a transfer it had already received. We stated the binding as a property of settled without saying when it started.

What changed. Found in our own security audit (S-4 / S-17) and disclosed the same day. The count is unchanged: no row was demoted or removed, because demoting one asserts that its transfer was not the purchased one and we hold no evidence for that. What changed is that the strength is now printed beside the count — settledNonceBound and settledAmountPayeeOnly on /api/v1/observatory/state, summing to l1.settled, with the same split per chain and on the state page. The retroactive check we can run is the clock: of the 1,629 settled rows, 1,589 carry a settlement block time, and those ran from 1 second before the attempt to 62 seconds after it, none outside a -5/+15 minute window. Duplicate settlement transactions across rows: 0 (1,634 distinct hashes over 1,634 rows). Figures are the 2026-09-05 reading; the live ones are on /observatory/state.

2026-09-02

This site's own description of how often endpoints are probed

What was wrong. The landing page and the observatory said every catalog-listed endpoint was "probed daily." That was not true. What ran daily was the catalog fetch; probes ran on a rolling schedule, and on 2026-09-01 only 2,750 of 14,662 active endpoints (18.8%) carried a probe from the previous 7 days. The claim and our own published counter contradicted each other on the same page.

What changed. Found in our own adversarial audit and changed the same day (commit a62072c, 2026-09-02 03:51 UTC). The wording now states the mechanism and prints the measured share: the catalog is re-fetched daily, endpoints are probed on a rolling schedule, and the page carries the current percentage of active endpoints with a probe in the last 7 days. We also raised the cadence: that share was 68.8% of 15,312 active endpoints on 2026-09-04 (reading at 09:00 UTC). That figure is a single reading and moves; the live one is on /observatory/state, and it is printed here with its timestamp rather than left to read as a standing property. An independent observatory, probe402, published the same finding on 2026-09-03 from a 2026-09-01 reading. Their reading was correct.