Corrections

2026-11-02

role=payee answering BLOCK with retry_burst for payers who buy from one resource often

What was wrong. role=payee answered BLOCK with retry_burst when more than 30% of the gaps between a payer's payments to one resource were 60 seconds or shorter, and the text called those payments retry bursts. A settled row is a payment that moved money. It does not show whether an earlier try was refused, so an agent calling the same API once a minute read as a retry pattern. Read on 2026-11-02T09:01Z over the 30-day window: 9,455 of the 11,819 payers with a measured gap were over the line, 9,304 of the 11,086 on Base.

What changed. Changed on 2026-11-02 in decision rules 2026-11-02.3. Short gaps do not affect role=payee now, and the code retry_burst is retired. The share stays in facts as short_interval_payment_rate, and retry_burst_rate stays beside it with the same value, marked deprecated. The BLOCK for a block list, a sybil signal and an input that could not be read did not change. The sybil signal needs a shared funder. Read on 2026-11-02T09:16Z, the funder index held 39 wallets and no payer in the window shared a funder in it, so an ALLOW here does not show that a payer is independent. Run over the same read, before any caller's own block list, 9,455 answers move off BLOCK: 5,361 to WARN, most of them payers first seen less than 7 days ago, and 4,094 to ALLOW.

2026-11-02

/decision reading L2 from the last 30 days of deliveries

What was wrong. The published rule reads L2 from the latest delivery. /decision and the facts API looked at deliveries from the last 30 days and no further, so a checked mismatch read not_checked once its delivery left the window, and its BLOCK became a WARN with no new purchase. Read on 2026-11-02T02:14Z, 2,358 listings had their last delivery outside the window. In 7 of them it named missing keys (5 listed, 2 delisted), and in 578 it conformed. 57 of the 2,358 had a signed attempt in the window and did not read l1_stale, and 2 of those read l1_never_delivered next to a last_delivered_at.

What changed. Changed on 2026-11-02. L2 now reads the latest delivery at any age. Those 7 listings moved from WARN to BLOCK (l2_mismatch). For a caller who does not set allow_without_l1, the other listings keep their recommendation. A caller who sets it can now get an ALLOW on 441 listings whose latest delivery conformed. An older row with no recorded reason and no named key is not read as a mismatch, because it cannot show whether the body was cut or broken: it reads undeclared when the listing declares no output schema, and not_checked when it does. The same reading applies to the record pages and to l2_reading in export.csv: read on 2026-11-02T03:38Z, 592 rows in the 90-day export moved off mismatch, 432 to no_declaration and 160 to not_checked. l2_schema keeps the value recorded at the time. A listing with an older delivery now reads l1_stale, not l1_never_delivered. The decision rules version is now 2026-11-02.2.

2026-11-02

role=payee answering BLOCK for Base payers because a wallet lookup ran out of time

What was wrong. role=payee answered BLOCK with erc8004_unavailable to each of nine Base payers called on 2026-11-01, and the text called it an input that could not be read, to retry later. Retrying would not have helped for hours. The agent index ran once a day and the live read of the blocks since then has 3 seconds: run locally on 2026-11-02 against public RPC, 34,000 blocks ran out of time and 5,400 blocks took 1.1 seconds. retry_burst_rate also stopped at the oldest 2,000 rows of a payer's window: read on 2026-11-02T01:28Z, 116 payers had more rows than that, and retry_burst came out the wrong way round for 3 of them: 2 gain it and 1 loses it.

What changed. Changed on 2026-11-02. The agent index now runs at 3-hour intervals, and the reason for a failed read goes to the server log. A failed read still answers BLOCK: fail-closed is the published rule. retry_burst_rate now counts the whole window.

2026-11-02

verified_terms.amount described as the asset's base units

What was wrong. The API docs and the MCP text said verified_terms.amount was in base units with 6 decimals. It is in vet402's 6-decimal ledger units. USD1 on BNB Chain has 18 decimals and USDC on Stellar has 7, so a 402 on those chains, compared as written, read far higher than the record.

What changed. Text changed on 2026-11-02. The value did not change. Multiply it by 10^12 on BNB Chain and by 10 on Stellar before comparing it with a 402.

2026-11-02

/decision answering WARN on a second L0 fail older than 30 days

What was wrong. /decision and the facts API read L0 probes from a 30-day window. A failing listing is probed less often, so the second of two failures in a row could leave that window. The answer was then l0_unverified_single_fail, a WARN, while the L0 CSV and the record page read the same probes and showed fail or withdrawn. Read on 2026-11-01T22:42Z, this applied to 1,203 listings: 118 listed and 1,085 delisted.

What changed. Changed on 2026-11-02. When the window holds fewer than two probes and they failed, the streak now counts the newest older probes. Those listings moved from WARN to BLOCK (l0_fail) unless another reason already blocked them. The published rule did not change: two measured failures in a row. The decision rules version is now 2026-11-02.1. A listing with no probe in the window keeps its recommendation, and its cause now reads l0_unverified_no_recent_probe instead of l0_unverified_not_probed: 12,697 listings read on 2026-11-01T23:12Z, 2,633 of them with the newest two probes failed, which the L0 CSV shows as fail or withdrawn.

2026-10-24

Counting other measurement services as real buyers

What was wrong. settlement_30d_real counted a payment as a real buyer when the row was not self_deal, not circular, and not a wallet vet402 pays from. The seller of api.ozdreamtools.de reported in public that two payers on that route describe themselves as measurement or inspection services (github.com/kzmttkc/vet402/issues/43). Those payments sat in settlement_30d_real. Two further payers on the same route sent a generic node User-Agent. Nothing public names what those two are, so they stay in the real count.

What changed. Changed on 2026-10-24. A payer on the published measurement list is stored as wash_flag measurement and leaves settlement_30d_real. The count is published as settlement_30d_measurement, separate from settlement_30d_test. The list, with the public page each row came from, is on the methodology page. The two listed addresses on Base are Crosspeel 0x8d2a47cbd262e1bc5ee0645c81899f9896957d37 and Mizan 0xe3badbd4f38214b9eae528a1a5398f6678f63fb3. Rows already in the index were moved on 2026-10-24: 1,632 payments in 840 rows of the per-day rollup. A short run of payments from one payer on one route was checked as a second signal. It was not used to mark rows, and it was not used to move rows out of the real count, because that shape also fits payers with no public measurement page.

2026-10-24

Counting a route the catalog no longer lists as a published fail

What was wrong. A route absent from a complete fetch of the public discovery catalog stayed in the published fail count when its newest probes failed. Catalog status delisted is that absence. It is written when a complete fetch no longer lists a route that the previous snapshot listed. The seller's own discovery document is not what this count reads.

What changed. From 2026-10-24 a route absent from a complete fetch of the public discovery catalog is published as withdrawn from the catalog. It is left out of the public L0 fail count and counted as withdrawnFail on /observatory/state. Probe rows and purchase rows stay as recorded. A pass on a delisted route stays a pass. On the L0 CSV retrieved at 2026-10-23T22:46:17.388Z, published_verdict fail was 7,376 of 85,939 rows. Of that fail count, 2,483 rows were still listed and 4,893 were not listed. /decision stays BLOCK on two consecutive L0 fails, including a route withdrawn from the catalog.

2026-10-21

Withdrawing the sentence that called a named purchase the harder test

What was wrong. The correction dated 2026-09-05 about purchases described as covert left this claim in its account of the fix: naming vet402 is the harder test, and a seller that knows who is watching and still takes the payment without delivering has been measured under the best conditions it will get. That claim does not follow from the measurement. A purchase that succeeds for vet402 does not stand in for another buyer.

What changed. The 2026-09-05 entry stays in this log unchanged, including the sentence this entry withdraws. The methodology page states the limit in its place: a purchase that succeeds for vet402 does not stand in for another buyer, and the same seller can return a different answer to a request that does not carry the vet402 User-Agent.

2026-10-21

Publishing Stellar pubnet settlements in the nonce-bound count, and describing settled with a shorter asset list than the chains vet402 pays

What was wrong. Stellar pubnet settled rows were published as nonce-bound. The re-read checks payer, payee, amount and asset. It does not compare the one-time value stored for that purchase. A fee sponsor changes the transaction hash, so a transfer of the same amount to the same payee can match. The state reading at 2026-10-20T22:55:08Z is not stored elsewhere in the repository. This correction is the remaining source for that reading: stellar:pubnet.settled was 30, with 30 in the nonce-bound count and 0 in the amount and payee count. The public asset sentence stopped at USDC on Base, Arc, Celo and Solana, USDC.e on Tempo, and RLUSD from its fixed issuer on XRPL. It left out USDC on Stellar and USD1 on BNB Chain. BNB Chain does bind the EIP-3009 authorization nonce.

What changed. Reclassification. The settled count was not moved. A stellar:pubnet row that is settled is published as amount and payee. It stays settled. l1.settledNonceBound plus l1.settledAmountPayeeOnly still equals l1.settled. No purchase status changed. The asset list on the state page, the state API disclaimer, the FAQ, the methodology and the vocabulary now name USDC on Stellar and USD1 on BNB Chain. BNB Chain stays in the nonce-bound count. The chain key in l1.byChain stays stellar:pubnet. Live counts are on /observatory/state.

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.