2 Oct 2026
corr_2026-10-02_001 · acknowledged
Claim
Nobody raised this. We found it reading our own Facilitators page. From 28 September the page counted three facilitators, `three.ws`, `open.x402.host` and `facilitator.openmid.xyz`, among those where our record and the settlement leaderboard differ. We had never sent any of them a request. Every row we hold for the three is an absence we filed, so the difference the page counted was a gap in our own record.
Finding
Measured on 2 October against our own archive. None of the three endpoints holds an observation at any depth: every row is `Not probed`. For `three.ws/api/x402-facilitator/supported` the host's robots.txt refuses the path, on every row since the row was added on 1 October and on all seven daily checks of the same address from 25 September to 1 October; `open.x402.host/supported` and `facilitator.openmid.xyz/supported` have rows since 26 August and none of them is an observation, and every row of the seven days we read back is filed because the host's robots.txt could not be read, so no request followed. The page compared the newest row in its two-day window with the leaderboard. A row with no answer in it fell into the case for a facilitator that was read and did not come back with a listing, and was counted as a difference; for `three.ws` the page also said no answer had reached us, when no request had been sent. All three were in the leaderboard's active population from its 27 September reading, so all three were counted from the moment the page began comparing the two records, on 28 September at 01:40 UTC. On 2 October the page read: For 7 of the 18 active facilitators the two records differ. Three of the seven were these absences. Two more were Meridian and Dexter, read on the rows `corr_2026-10-01_001` already scopes; that record covers them. The rows themselves are correct as recorded.
Remedy
Fixed forward on the page, and nothing stored is edited. The page now keeps an absence of ours out of the comparison: a facilitator whose newest row is an absence we filed, with no answer in the window that came back with a listing, is counted with the facilitators we have no reading for, and the page says so as our gap. A daily check that was never sent is read the same way. The page also reads a facilitator on the row that continues its series where a correction replaced one. After the change the page reads: For 2 of the 18 active facilitators the two records differ, and for 3 more we have no reading of our own to compare. Every row on these three endpoints stays in the archive as recorded; this record is how the page's earlier count is to be read.
How to read the affected rows
Read every row on these three endpoints as recorded: an absence we filed, never a reading of the facilitator, and never a difference with the settlement leaderboard. `three.ws` (ep_1aafc569edcb1118): its robots.txt refuses the path, and no request was sent. `open.x402.host` (ep_7af5e283b8d31e0c) and `facilitator.openmid.xyz` (ep_2a761122d539c9ad): no request has reached either since its row was added; on every row we read back, its robots.txt could not be read. The Facilitators page counted all three as differing from the leaderboard from 28 September until the change this record describes. None of the three says anything about whether the facilitator was settling; the leaderboard is the channel that does.
3 endpoints
24 Sep 2026
corr_2026-10-01_001 · acknowledged · Restates corr_2026-09-24_001
Claim
Nobody raised this. A red-team read of our own facilitator lane on 2026-09-22 and a second-channel read on 2026-09-24 found that three of the nineteen facilitator availability readings we hold are readings about our reader, not about the facilitator. Two of the three are our own address error: for `api.mrdn.finance` the lane appended the specification's `/supported` to the registry's base URL and has recorded 404 on every read since 2026-08-26, while the operator's surface answers 200 at `/v1/supported`; for `facilitator.dexter.cash` every read since 2026-08-26 recorded a 308 redirect and never a body, because our prober does not follow redirects by policy, and the operator's own redirect target `x402.dexter.cash/supported` answers 200. The third is a reading we labelled wrongly: `api.thirdweb.com` answers 401 to an anonymous client on every read, which is the documented behaviour of a facilitator whose own client sends a credential, not an availability failure.
Finding
Measured 2026-09-24 against our own archive and one read of each address with an identified research user agent, at least four seconds apart. `api.mrdn.finance/supported`: 404 on every archived read since 2026-08-26; `api.mrdn.finance/v1/supported`: 200, a body of 2,771 bytes naming 47 payment kinds over 25 networks. The same operator settled 19,219 payments in the 30 days to 2026-09-24 per the signed settlement leaderboard we derive the lane from, so a reader of our series who took the 404 as the facilitator's state was wrong about a facilitator carrying 26% of the rail's 30-day value. `facilitator.dexter.cash/supported`: 308 on every archived read since 2026-08-26, the `Location` header naming `x402.dexter.cash/supported`, which answered 200 with a body of 9,623 bytes; the operator settled 31,865 payments in the same window. `api.thirdweb.com/v1/payments/x402/supported`: 401 on every read, unchanged on the second channel; the row's own notes already say the series records the documented path as an unauthenticated client sees it, and the wrong reading was in treating that 401 as no answer. The population is bounded by the three endpoint ids in scope; every other facilitator row was re-read on the second channel and its reading stands or is a genuine candidate about the facilitator (`api.polymer.zone` 404 with 400 at two other paths, `acpx.virtuals.io` 404, `open.x402.host` no connection, `facilitator.openmid.xyz` 503), which this record does not annotate because none of those is our instrument. Read again on 2026-10-01 against our own archive: the corrected addresses were read once a day from 2026-09-25 to 2026-10-01, seven reads each. `api.mrdn.finance/v1/supported` answered 200 with 2,771 bytes on all seven. `x402.dexter.cash/supported` answered 200 on all seven, with 9,623 bytes through 2026-09-27 and between 10,937 and 10,959 bytes from 2026-09-28. Of the three further facilitators read the same way, `x402.treasure.lol/facilitator/supported` answered 200 with 123 bytes on all seven and `api.figment.io/x402/supported` answered 401 with 81 bytes on all seven, the documented answer to an anonymous client; `three.ws/api/x402-facilitator/supported` was never requested, because that host's robots.txt refuses the path and we sent nothing on any of the seven days.
Remedy
Fixed forward in two steps, and nothing stored is edited. Step one is done: from 2026-09-25 the corrected addresses were read once a day, so that no further day at the right address was lost. The second step is made on 2026-10-01 in the seed change of that date. Two rows at the corrected addresses continue the two series: `ep_ee3683721aa9f7cb` at `https://api.mrdn.finance/v1/supported` and `ep_5afff6fd076c0f41` at `https://x402.dexter.cash/supported`, each recorded as succeeding the row it corrects and each read every six hours. The two rows at the wrong addresses, `ep_112e54ff2d484c87` and `ep_eda1bbb5bf0c1345`, are retired by that change: from the collection cycle at which the collector begins running on it they are no longer requested and each files its own exclusion, with the earlier record of this correction named as the reason. Until that cycle they keep recording the 404 and the 308, and this record covers those readings. A retired row's identity is its URL, so the old series ends and a new one begins rather than one being rewritten. The row for `api.thirdweb.com`, `ep_2d3e2f5fb21d63bc`, is unchanged: its 401 is the correct reading of that path for an anonymous client, and its notes say so. The three further facilitators whose addresses the lane had failed to derive have rows in the same change; the row for `three.ws` records that operator's published refusal and no request is sent to it. Every observation these three rows recorded stays in the archive as recorded; this record is how they are to be read.
How to read the affected rows
Read every reading on these three endpoints from 2026-08-26 as a reading about our reader, not about the facilitator. `api.mrdn.finance` (ep_112e54ff2d484c87): the address we read does not exist on the operator's surface; what the operator's actual surface answered on any day before 2026-09-25 cannot be recovered, so no reading is substituted. Its series continues at `ep_ee3683721aa9f7cb` (`https://api.mrdn.finance/v1/supported`), and from the collection cycle at which the collector begins running on the seed change of 2026-10-01 this row records its own exclusion rather than a 404. `facilitator.dexter.cash` (ep_eda1bbb5bf0c1345): the 308 is the operator's redirect and our policy of not following it; what the redirect target answered on any day before 2026-09-25 cannot be recovered. Its series continues at `ep_5afff6fd076c0f41` (`https://x402.dexter.cash/supported`), and from that same cycle this row records its own exclusion rather than a 308. `api.thirdweb.com` (ep_2d3e2f5fb21d63bc): the 401 is the documented answer to an anonymous client and is the correct reading of that path, before and after the seed change; the error is in any presentation of it as an availability failure, and the row's notes already carried the caveat. None of the three says anything about whether the facilitator was settling; the signed settlement leaderboard we archive daily is the channel that does.
3 endpoints
3 Sep 2026
corr_2026-09-03_002 · resolved · Restates corr_2026-09-03_001
Claim
Nobody raised this. We found it in our own archive: probe402 published 509 observations of 136 MPP endpoints as `Answered, no quote` - alive, asking to be paid, not saying how much - when every one of those endpoints had said exactly how much, in the same response header, one base64url hop away. The price was inside the challenge's `request` parameter and our parser only read the flat parameters beside it. MPP is the rail no competitor archives, and we were blind on it from our first tick to this one.
Finding
Measured 2026-09-03, read-only, against our own retained captures. Of 525 `WWW-Authenticate: Payment` challenges across 384 archived capture blobs and 162 hosts, 519 carry the charge inside a base64url `request` parameter and 4 carry the flat `amount`/`recipient` auth-params `parseMppChallenge` was written for. Nine payment providers publish the encoded form - tempo (412 challenges), evm (68), stripe (21), solana (4), x402 (4), exact (4), lightning (2), asterpay (2), usdc (2) - and every one of the 519 decodes to an object carrying an amount. The parser looked in the one place the ecosystem does not use, found nothing, and filed `no-amount-or-recipient`. EVERY affected row was then re-read against its own archived capture: all 509 of them, on 136 endpoints across 42 hosts, yield a quote - the transition is uniformly `Answered, no quote` -> `Quoted`/R14d, and none of them remains unreadable. The population is bounded by the archive's own record: a row can move only if its stored `quote_parse.mpp` is true, because the changed function returns early when no `Payment` challenge is present. THERE IS A SECOND, LARGER CLASS AND IT IS NAMED HERE RATHER THAN LEFT OUT. When a quote parses, the classifier returns early with a fixed sub-code list, so a row whose x402 arm quoted and whose MPP arm failed carries NO trace of the failed MPP parse at all. Measured: 4,188 further rows on 881 endpoints. Their outcome and their price are correct and unchanged - x402 stays the primary quote - but they record the endpoint as serving ONE rail when it serves two (rule R14a/R14b/R14c where the corrected reading gives R14e, dual-rail). On an evenly spaced sample of 188 of those 881 endpoints, 188 of 188 promote and none is unchanged. They are NOT in this record's scope because their exact enumeration needs the full re-derivation of the archive, which is queued; scoping 881 endpoints from a sample would publish an inference as a measurement. A second record follows that run.
Remedy
FIXED FORWARD, NOT REWRITTEN. The parser now reads the `request` parameter in the one place a quote is read, and the payment method the challenge names - tempo, stripe, lightning and six others - is recorded as the quote's scheme. A `request` we cannot decode is recorded as an ATTEMPTED parse that failed, never as an endpoint that published no price: the distinction is the whole point, because reading an unreadable challenge as an absent one is how this defect published a statement about 136 operators that was really a statement about us. The rubric version moves 5 -> 6 so the boundary is visible in the archive itself and not only in a changelog; the decision behind the change is recorded there, as what it decided, and is named in this record's method-change reference. NO STORED OBSERVATION IS EDITED and the archive is not migrated, under the standing rule that a stored observation is never edited and a correction annotates it: the affected rows still say what they said, under the rubric version that actually graded them, and this record is how they should be read. Re-deriving the archive under the corrected parser reproduces every other row byte-for-byte; these rows are the declared exception.
How to read the affected rows
Read these rows as `Quoted`. The endpoint answered with a payment challenge carrying a price, and our instrument could not see it. The grade understates the endpoint; it is not a fact about the endpoint at all. Rows on these endpoints from the corrected collector onward carry the quote directly and need no annotation, which is why the range closes rather than staying open. The second class described in `finding` is not annotated here: those rows are correct about the outcome and the price, and what they understate - the rail set - needs the queued re-derivation to enumerate exactly.
136 endpoints
24 Aug 2026
corr_2026-08-24_002 · resolved · Restates corr_2026-08-24_001
Claim
Nobody raised this. We found it in our own archive: probe402 sent these two endpoints a POST with NO REQUEST BODY, and then published the endpoints' rejection of that malformed request as an observation of the endpoints' state. It is the artefact 402index reads as `degraded` across 61% of MPP, reproduced by us, in our own record.
Finding
Measured 2026-08-24 against captures taken 2026-08-21T08:00:21Z, in the endpoints' own words. ep_5bfb57c12c2b3548 (api.statemind.ai/mcp) answered HTTP 200 with {"jsonrpc":"2.0","id":null,"error":{"code":-32700,"message":"request body is not valid JSON"}} and was graded `Answered, no quote` / R19 [http-200]. ep_46652289eaf2c57b (govlaws.ai/api/mpp/search) answered HTTP 400 with {"error":"invalid_json","message":"Request body must be valid JSON"} and was graded `Answered, no quote` / R19 [http-400]. Both seed rows carry method POST with request_body: null, so the prober sent a bodyless POST on every tick from collector-live onward. Neither grade is a fact about the operator; both are facts about our request. Seven of 29 seed rows share the shape (A8, C2, M1, M2, M3, M4, M5); these two are the ones where the endpoint stated the cause explicitly, so they are the ones this correction scopes. The other five answered in ways that do not establish our request as the cause and are NOT annotated here - an unproven annotation would be its own instrument error. CLOSED 2026-09-08, against the live archive, without writing to it. The fix-forward landed inside the collection cycle t20260824T110000Z: the last row of either endpoint derived from a bodyless POST is 2026-08-24T10:01:33.933Z, and from that cycle onward every row of both endpoints is `Not probed` with sub-code `no-request-body` - 76 consecutive rows each over the week that followed, and four each on 2026-09-07, with no observation between. So the open range this record was filed with has outlived what it was for by fifteen days: it formally annotates rows that already say what it asks them to say.
Remedy
FIXED FORWARD, NOT REWRITTEN. The prober now refuses to send a body-bearing method with no body and records `Not probed` with sub-code `no-request-body` - our gap, on our side of the line, recorded as ours under our published honest-absence rule. No stored observation is edited: the affected rows still say what they said, and this record is how they should be read. NO BODY WAS INVENTED. Our published method permits deriving one from a catalogue input example and there is none to derive from - measured, 402index's rows carry price, network, health_status and latency and no input schema, and the Bazaar row for api.statemind.ai carries prose and no input block. A body we made up would be a guess at another operator's API contract published as a grade of them, which is worse than the defect it replaces because the guess would be invisible in the record while `request body is not valid JSON` is right there in the capture. Restoring these two endpoints to a real series therefore needs an input contract we do not have; until we do, `Not probed` is the honest reading and the series stays absent rather than wrong. THIS RECORD RESTATES ITS PREDECESSOR AND CLOSES ITS RANGE; nothing else about it moves. The claim, the measurement, the annotation and the endpoints are its predecessor s, word for word. What changes is scope.to, which was left null because the collector kept running until the corrected prober was deployed and a date we had not reached would have been a claim we could not make. We have reached it, and the archive says which cycle it was. The predecessor stays served, as filed, at its own address: a correction is appended and never rewritten.
How to read the affected rows
Every observation of these two endpoints in this range was derived from a POST we sent with no request body. The endpoints rejected the REQUEST; they did not report their own state. Read these rows as `Not probed - no-request-body`: an absence of ours, never a grade of theirs. The range CLOSES at the collection cycle t20260824T110000Z, from which both endpoints file that absence themselves - measured against the archive on 2026-09-08 and unbroken since. Rows from that cycle onward need no annotation, because the record already says of itself what this note asks a reader to say of the rows before it.
2 endpoints