Corrections

CORRECTION #9 — 2026-09-17 What happened: Until today this site published a single figure it called an error rate: "29.6% — 143 of 483 published agents carry a verdict our own evidence does not support." The arithmetic was right and the 143 addresses were correctly identified. The label was wrong. Every one of those 143 came from one test: a verdict of REAL-SERVICE where our sample found a single paying customer. That is not evidence contradicting a verdict. It is very little evidence for one. We had been telling readers we were demonstrably wrong about 143 addresses when what we could actually show is that 143 rest on the thinnest evidence we accept. Why: The measurement runs four tests and adds up everything they catch. Three of them look for genuine self-contradiction — a loop verdict on an address that sent nothing out, a verdict passed on a zero-size sample, an address in scope for a registry of paid agents with no payment recorded. Those three caught nothing among published addresses. The fourth flags the single-payer case, and the note written beside it in our own code says plainly: "It may still be real — but it is the weakest possible evidence." That sentence describes thin evidence. The headline above it said "how often we are wrong". The word on the total had drifted from the thing being counted, and because one test supplied the entire total, nobody looking at the number could see it. What changed today: The figure is now published as two, on the homepage and on the methodology page: Self-contradiction rate (lower bound) .... 0 of 483 ..... 0.0% Thin-evidence verdicts .................. 143 of 483 .... 29.6% Nothing was removed and no address was re-graded. 0 plus 143 is the same 143 published yesterday, and the same 143 addresses are still flagged, still published, still resting on one sampled payer. The part we want read twice: The zero is not good news and is not an accuracy claim. It means only that no verdict we publish is refuted by evidence already sitting in our own store — the weakest test in this building to pass. It cannot see an agent we wrongly excluded, because excluded addresses are not measured. It cannot see a verdict that is wrong in a way our record is internally consistent about. Splitting a number must never be a way to make a site look better than it did, so the page now says this beside the zero rather than leaving a reader to assume the opposite. The fix: the two figures are derived in one place in the code, and any test not explicitly marked as thin evidence counts as a contradiction, so a test added later cannot quietly dilute the harsher number. The generator emits both, and the previous field names are kept so nothing reading the JSON breaks.

CORRECTION #8 — 2026-09-17 What happened: Correction #6, published on 2026-09-12, said the eleven days of 19 to 29 August had been recomputed from the settlement record and were complete. For three of those days that was not true. The recomputation itself read the record incorrectly, and 19, 20 and 21 August were published short by $1,095,700 across 122 addresses. Those are the three largest days of the whole outage — the days with the most to read, and therefore the days with the most to miss. The understated figures were live for two days, under a notice that called them complete. Why: The recomputation walked the settlement record in pages and asked for page after page without saying what order the rows should come in. A database given no ordering returns rows in whatever order is cheapest at that moment, so pages overlapped and skipped. The bigger the day, the more pages it took, and the more there was to lose — which is exactly why the three largest days were the three that broke. This is the same fault as Correction #5, in a different place. That one was found in August, in the code that counts an agent's payers, and fixed there. The identical unordered walk was sitting in the rollup and nobody looked for it. Fixing a fault where it is found is not the same as fixing it everywhere it lives. What was NOT affected: The settlement record itself, which was complete and correct throughout — this was a fault in reading it, never in capturing it. Received, retained and the lifetime totals are computed from that record directly and did not change. No verdict was affected, and none has been reconstructed for those days; as Correction #6 said and this one repeats, a verdict records what could be verified on the morning it was written, and those days carry none. The fix (repaired 2026-09-14): the three days were recomputed by a walk keyed on the settlement primary key, which cannot skip or double-count, and the figures now published are that walk's result. The cause was fixed at source: the read orders on that key, and a read that reaches its limit now writes nothing rather than a partial sum. A partial sum that looks like a total is worse than no answer, because nothing downstream can tell the difference. The record: our discipline requires that a recomputation and its public notice be a single act. This notice is filed on 2026-09-17, three days after the figures were repaired. That gap is itself a departure from the rule, and it is recorded here rather than quietly closed. The repair was made on 2026-09-14; the disclosure is today.

CORRECTION #7 — 2026-09-12 What happened: Until 2026-09-12, 67 of the 420 addresses published on this site carried a statement about their evidence that was weaker than the evidence we actually held. Seventeen of them published the grade "none", which on this site means we looked for x402 provenance and did not find it. Fifty published no grade at all. For every one of those 67, our own settlement record held reconstructed x402 payments. One held 273. Another held 636. The largest held 125,098. ONE OF THEM IS A NAMED INDIVIDUAL WHOSE PAGE SHOWED $57,780 OF VOLUME AND NO PROVENANCE BESIDE IT. Why: Two instruments were describing the same thing and only one of them was being shown. The grade came from a sampler that examines up to SIX of an address's payments and reports what it finds — a cheap, deterministic measurement, and a reasonable one. The settlement record is the whole history, every payment we have reconstructed. When an address adopted x402 after the six sampled payments, or paid through a route the sampler did not sample, the sampler correctly reported "I did not find it" — and the page printed that as though it were a finding about the address rather than a limit of the sample. An independent audit of these grades in August found no error in them, and that audit was right: it checked whether each grade followed correctly from its six payments. It could not ask whether six payments were enough, because it was handed the same six. What was NOT affected: No money figure. Received, retained, volume, payment counts and every daily total are computed from the settlement record and were correct throughout. Nothing was overstated and no agent was credited with revenue it did not receive. What was wrong was what we SAID ABOUT THE EVIDENCE beneath a correct number. The fix (deployed 2026-09-12): the pages now LEAD with the settlement record — "x402 confirmed, N settlements on record" — and the sampler's grade is shown beneath it, labelled as an indication drawn from a small sample. Where the two disagree, the settlement record wins, because it is the whole record and the sampler is a sample of it. Where an address has no settlements at all, the page now says that this is a limit of what we have captured rather than a finding about the address. And a check now runs before every publish that REFUSES TO SHIP ANY PAGE ASSERTING AN ABSENCE THAT OUR OWN STORE CONTRADICTS. The record: per our data definitions, the pages as published stand as written — history is never rewritten. This note is the correction.

CORRECTION #6 — 2026-09-12 What happened: For eleven days — 19 to 29 August 2026 — the daily in-and-out figures on this site showed nothing for the SETTLED half. The payments themselves were never lost: they were in our settlement record the whole time, captured and stored. What was missing was the daily summary built from them, and a reader looking at those eleven days would have seen an empty measure where there was real activity. Each of those days in fact carries between 471 and 582 settled payments. Across the affected window the daily record held 16,497 rows where it should have held 19,462. Why: Collection stopped for part of that period, and when it recovered it caught up on the payments but not on the summaries. The job that builds the daily summary only ever looks three days back — a sensible limit that keeps a nightly run cheap — and by the time collection had recovered, those days were already older than three days. Nothing was watching for a day that had payments but no summary, so the gap sat there, permanent by construction, waiting for someone to look. What was NOT affected: No money figure anywhere else, and no verdict. Received, retained and the lifetime totals are computed from the settlement record directly and were correct throughout. Importantly, NO VERDICT HAS BEEN RECONSTRUCTED for those eleven days and none ever will be: a verdict records what could be verified on the day it was written, so those days still carry none — exactly as the methodology says. The fix (deployed 2026-09-12): the eleven days have been recomputed from the settlement record. Separately, the summary job now looks for any day that has payments but no summary and fills it, oldest first, instead of only ever looking three days back. The same hole cannot open again silently. The record: our discipline allows history to be COMPLETED when recovered evidence proves a published figure incomplete — but only if the recompute and this public notice are a single act, never a quiet repair. That is why this note exists. The published pages for those eleven days stand as they were written; the record beneath them is now complete.

CORRECTION #5 — 2026-08-12 What happened: From 2026-08-04 to 2026-08-12, one agent page published a self-funding figure that was wrong, and — more seriously — that was not STABLE. The page read "9 of 38 payers — 23.7% — $1,940.00". The true figure, measured directly, is 9 of 44 payers — 20.5%. Running the very same code against the very same database on a second machine, in the same hour, produced "0 of 12 payers — 0.0% — $0.00". Both published versions were wrong, and both looked entirely reasonable. The figure was live for eight days. Why: To count an agent's payers we read them from the database in pages of a thousand. That walk asked for page after page WITHOUT EVER SAYING WHAT ORDER THE ROWS SHOULD COME IN. A database given no ordering is free to return rows in whatever order is cheapest at that moment, and it does — so pages overlapped and skipped, and they overlapped and skipped DIFFERENTLY ON EVERY RUN. What we called paging was closer to sampling. The comment written above that function claimed the opposite discipline in plain words: "every set is fetched to its exact count". It took no count and checked nothing. A comment is not a guard. What was NOT affected: The money. Received, retained, settled totals, the daily archive and every verdict are computed from on-chain settlements by a different path, and none of them used this walk. The defect touched counts of payers and the shares derived from them. The fix (deployed 2026-08-12, verified): two guards, because either alone is not enough — the code now REFUSES to page at all without an explicit order, and it takes the exact count first and refuses a short read. The ordered walk returns 50,951 rows with zero duplicates, and the rebuilt page reads 9 of 44. On 2026-09-12 the same defect was hunted across the whole codebase rather than at the two places it had surfaced: every paging helper now demands an ordering that is genuinely unique, and refuses one that merely looks ordered. How it was found: by running the identical code on a second machine. No test on a single machine could have found it, because the defect is a number that changes when nothing has changed. The record: per our data definitions, the pages as published stand as written — history is never rewritten. This note is the correction.

CORRECTION #3 — 2026-08-11 What happened: From 2026-08-04 to 2026-08-11, six agent pages on this site published a DECLARED PRICE that was wrong by a factor of one million. A service whose operator declares five dollars per call was shown as "5000000 per call". The other five read 54001, 100000, 100000, 1000 and 1000 where the correct figures are $0.054001, $0.10, $0.10, $0.001 and $0.001. The figure was displayed for seven days. Why: The x402 specification defines a resource's price in ATOMIC UNITS of the asset — for USDC, millionths of a dollar. Our directory reader stored that integer exactly as published and never recorded WHICH asset it belonged to, so the unit could not be recovered afterwards. The page then printed the stored number beside the words "per call". Nothing in the pipeline compared the figure to a unit, because nothing held one. The number was correctly transcribed, correctly formatted, and a million times too large. A second, smaller misstatement was found and fixed at the same time: an address may publish MANY priced endpoints — one publishes 1,556, ranging from $0.01 to $100 — and we stored only the first price we encountered and presented it as "the" declared price. It was sometimes the cheapest, sometimes the dearest, and nothing recorded which. What was NOT affected: No measured figure. Every number AQUIX itself produces — retained, received, settled, payment counts, verdicts, the daily archive — is computed from on-chain settlements and was never involved. The declared price is not a measurement; it is a quotation of what an operator published elsewhere, and only that quotation was misprinted. No verdict, no ranking and no money figure moved. The fix (deployed 2026-08-11): the asset is now stored alongside the price, and the page converts only where that asset is a recognised six-decimal stablecoin — exact arithmetic, never inference. Where the directory names no asset, the raw figure is shown and explicitly labelled as an unconvertible smallest-unit value, because an unlabelled number a reader takes for dollars is worse than no number at all. Prices declared in testnet currency are converted but marked as a testnet, not presented as revenue. Where an address publishes several priced endpoints the page now shows the RANGE and how many. A test now asserts every published price against its asset's decimals and fails if the raw atomic figure ever appears again. How it was found: the founder asked that the site be navigated as a visitor rather than read as code. The defect was invisible in the data and obvious on the page. The record: per our data definitions, the pages as published stand as written — history is never rewritten. This note is the correction.

CORRECTION #4 — 2026-08-10 What happened: From 2026-08-07 to 2026-08-10, the filters on the registry page did nothing. Choosing "service", "wallet", "circular flow" or "conduit", or typing in the search box, changed which rows were counted but never removed a single row from the screen. The counts did not even fall as you filtered — they GREW, because paging through the list revealed more rows than were visible at the start. A reader who filtered for one kind of agent was shown every kind, under a heading that said otherwise. The controls were live for three days. Why: Each row was marked kept-or-rejected and the page was then redrawn. The redraw set visibility on two groups of rows — those in the conduit lane, and the survivors of the filter. A REJECTED ROW WAS IN NEITHER GROUP, so nothing ever set it to hidden and it simply stayed where it was. The flaw was created by a correct decision: when the registry was consolidated from two tables into one on 2026-08-07, every row moved into a single lane, and that removed the only code path that had been hiding anything. Nothing failed, nothing threw an error, and every automatic check passed, because the code did exactly what it said — it just no longer said enough. What was NOT affected: No figure. Every number on the page — received, retained, payment counts, verdicts, the daily archive — was computed from on-chain settlements and was correct throughout. Nothing was misclassified, and no agent was shown a verdict it had not earned. What was broken was a control, not a measurement: the page told the truth and would not let you sort it. The fix (deployed 2026-08-10): rejected rows are now hidden explicitly rather than by omission, and a test drives each control and COUNTS the rows left visible, so a filter that stops working fails the build. The same five filters that returned 39, 47, 58, 66 and 30 rows now return 30, 13, 13, 10 and 1. How it was found: the founder reported it three times. It was not believed the first two times, because the code had been read and the code looked correct. The lesson recorded that day was that a test asserting "no error was thrown" is not a test of behaviour — you have to work the control and count what happens. The record: per our data definitions, the pages as published stand as written — history is never rewritten. This note is the correction.

CORRECTION #2 — 2026-07-19 What happened: Our daily archive published days as "final" while a significant share of on-chain settlements had not yet been captured. The nightly settlement scan runs against a time budget; blocks beyond the cutoff were not reached before days were stamped — and our coverage measurement only counted the blocks the scan did reach, so the gap was invisible to us. A full re-sweep of every published day has now recovered 921,973 settlements across 2026-07-07 → 2026-07-12. Several days were missing between 20% and 53% of their settlement records: 07-07 (+240,723), 07-09 (+173,292), 07-10 (+245,803), 07-11 (+137,312), 07-12 (+123,983), 07-08 (+860). Separately, on 2026-07-15 our database provider's resource limits caused a day-long outage; all of that day's captures were subsequently recovered from the chain. A sentence we retract: Correction #1 stated "Settlement receipts (the daily archive) — zero loss, all days captured." That was written in good faith about that incident's scope; as a general claim it was wrong, and we retract it. This correction replaces it with measured numbers. What was NOT affected: Verdicts, lifetime per-agent figures, and the headline totals — computed by full-history enumeration and independently reconciled against the chain to the cent. Most recovered records belong to already-quarantined bot-loop wash; recovering them completes the forensic record without inflating any verified-revenue figure. The error was confined to per-day settled figures in the daily archive. The fix, already live: "Final" is no longer a calendar claim. A coverage watermark now records exactly which blocks have been contiguously scanned, and a day is only stamped final once the watermark has provably passed its end. Days we haven't fully seen now wait, visibly, instead of publishing. Every publication since 2026-07-17 has run under this proof. The completions: Per our data definitions, history is never silently rewritten — it may be completed, flagged and disclosed. The affected days are being recomputed with the recovered settlements, each flagged late_write. The before → after figures append to the table below as each day completes (all within ~24 hours of this notice):

What remains open, honestly: (1) A small tail of settlements from facilitators that have since gone inactive cannot be recovered by our standard re-sweep — including, notably, the three settlements ($7) whose discovery opened this incident — see the Final Update below, where the chain's precise figures correct this description. A historical-trust re-sweep to recover them is scheduled and its results will be disclosed here. (2) Our daily archive measures the standard x402 rail (transferWithAuthorization). A second settlement path — account-abstraction (ERC-4337) routed payments — exists and is under investigation; lifetime figures already include it, daily figures will state their basis until it is measurable per-day. The record: Original values remain permanently visible here. Every recovered settlement is individually verifiable on Basescan.

CORRECTION #2 — FINAL UPDATE, 2026-07-23: the open items, resolved The inactive-facilitator tail — recovered. As disclosed above, some settlements from facilitators that later went inactive could not be recovered by our standard re-sweep. We have now completed a historical-trust re-sweep: each affected day was re-scanned using the facilitator set as it stood on that day, reconstructed from chain evidence. Result: 877 additional settlements recovered across 2026-07-07 → 2026-07-13. The affected days were recomputed once more (flagged late_write); the updated figures are in the table below (total +$6,983.64).

The settlements that started this — home, and our own number corrected. This incident began when our founder noticed missing settlements on one agent. Above, we described them as "three settlements ($7)." The chain's precise answer, now that they are recovered: two settlements were missing — $1.00 and $2.00, totaling $3.00 — alongside one $1.00 settlement we had always captured; the agent's day held three settlements totaling $4.00. We are correcting our own earlier sentence to match the chain. Precision applies to our legends too. Still open, as stated: the account-abstraction (ERC-4337) settlement path remains under investigation; daily figures state their basis until it is measurable per-day. This closes the incident opened 2026-07-08. Every figure above is verifiable on Basescan.

CORRECTION #1 — 2026-07-14 What happened: From 2026-07-12 to 2026-07-14, this site UNDERSTATED the verified x402 economy on Base. The in-scope count showed 59 verified services (~$39.2M volume) when the true figure was ~94-96 (~$45M+). 37 genuinely real agents were wrongly excluded. Why: Our scope check — the test deciding whether an agent belongs to the x402 economy we measure — sampled each agent's OLDEST transactions. Agents that adopted x402 after their wallet's creation could fail this test falsely. A safety cache masked the flaw until 2026-07-12, when the cache's database query exceeded a URL length limit as the tracked-agent count grew, FAILED, AND THE FAILURE WAS SILENTLY IGNORED — so every agent was re-tested by the flawed method at once. The excluded agents' recent on-chain activity was verified directly: their payments are genuine x402. The rails never changed; our ruler misread them. What was NOT affected: Settlement receipts (the daily archive) — zero loss, all days captured. Real/bot verdicts — correct throughout; all daily anchors passed. Money figures per agent — computed from receipts, correct. The error was confined to one label (in-scope/out-of-scope) for two daily snapshots. The fix (deployed 2026-07-13, verified 2026-07-14): the scope check now samples recent AND oldest transactions; the cache query was rebuilt to be size-proof; and any such failure now halts safely and loudly instead of silently mass-flipping agents. The record: per our data definitions, the 07-12 and 07-13 snapshots stand as written — history is never rewritten. This note is the correction.