How Paddock measures agent commerce.

The field share_of_volume in the market summary (API, the get_market_summary tool, the market page) has always been each category's share of categorized transactions, not of USDC volume. No figure changes. The field is renamed share_of_transactions; share_of_volume is served with the same value until 2026-12-31 and then removed.

Windowed settlement figures on /s/[domain] service pages and /charts, and the single-night picks behind verify_before_pay's settlement block and get_best_value_provider, included nights whose recipient data was not measured that night. From 2026-09-25 every one of these readers counts measured nights only, through the same shared predicate the entry of 2026-09-21 introduced. The monthly report's captured-basis clause now names the nearest measured night inside its window.

Measured on production data on 2026-09-21: the /s/laso.finance 7-day settled tile (2026-09-14 to 2026-09-20) read 48 transactions and $43,196.28 before and 24 transactions and $27,333.66 after; the 30-day tile ending 2026-09-20 read 399 transactions and $213,366.81 before and 375 transactions and $207,433.29 after. verify_before_pay's settlement block for the same domain moved by the same amounts, and its last_observed_settlement_date moved from 2026-09-20 to 2026-09-21. get_best_value_provider for the payments category picked 2026-09-20 before and 2026-09-21 after.

The nightly snapshots themselves are unchanged.

Window sums on /leaderboard, get_provider_revenue, get_category_detail and get_changes counted nights the writer had carried forward from the prior night (serversSource prior_kept) or marked failed as measured days. From 2026-09-21 those nights are excluded. Affected nights to date: 2026-06-13, 2026-06-14, 2026-06-15, 2026-08-31, 2026-09-07, 2026-09-15, 2026-09-18, 2026-09-19, 2026-09-20. Figures for any window containing those dates changed.

The August report presented a two-point comparison (Aug 1 vs Aug 31) as a headline finding. The figure is unchanged; it now appears below the fold, labeled as a two-point comparison. Headline findings are 7-day rolling or full-month figures.

Logged under the corrections log's fifth scope entry, not its first: no published figure's value moved, its meaning did not change, and nothing was retracted. What changed is where the figure renders and how it is labeled — a presentation and categorization correction, not a value correction.

The coverage sentence was hand-typed and never revisited while the feed grew — our own integrity record shows TrustBench going from 261 domains to 932 in fifty days. It is no longer typed: both counts are now read from that record at build time and published with the date they were read, so a figure that lags says which night it is from rather than reading as current.

Paddock reads x402scan's seller list one page at a time. RECIPIENTS_MAX_PAGES capped that walk at 100 pages, and because the upstream ignores the page-size parameter and serves 10 rows per page regardless, that was 1,000 recipients a night. The cap was set on 2026-06-12 against a live measurement of the full list at ~517 pages / ~5,170 sellers, on the reasoning that 1,000 rows captured about 97% of listed volume and walking the rest would cost ~90 seconds of cron time for under 3% more.

Re-measured on 2026-09-09, the full list is 146 pages / ~1,455 recipients. The cap was dropping 455 recipients carrying 455 transactions and $179.01 — every one of them a one-transaction seller, 3.0% of the day's listed transactions. THE DROPPED TAIL IS IMMATERIAL TO VOLUME and that is stated rather than implied: $179.01 against a listed universe of 15,134 transactions, all of it from sellers with a single transaction that day. It is quantified from ONE measurement on 2026-09-09, not a nightly average, and it is not presented as one. What the tail is NOT immaterial to is the DISTINCTION between a count and a lower bound, which is exactly what coverage.list_complete asserts and what the monthly report prints verbatim.

The cap is now 250 pages, which clears the live list with about 70% headroom, and hitting it is loud rather than silent: the walk reports why it stopped and raises an alarm when the budget runs out with the upstream still offering more.

The second change is the one that could have corrupted a figure rather than merely bounding it. The walk treated a null response — which its fetch helper returns for a network error, a non-2xx and an unparseable body alike — identically to a page that came back legitimately empty, and both set the list complete. A transient upstream failure on page 40 therefore published a night truncated at an arbitrary point as an EXHAUSTED list, with list_complete: true riding into the report's basis clause. The walk now distinguishes an exhausted list from a capped one from a failed one, stores the reason as coverage.list_stop_reason, and never reports a failed walk as complete.

WHICH NIGHTS THE SECOND DEFECT TOUCHED IS UNDER AUDIT; DATES TO FOLLOW. No date is named here until that audit reports, because naming one on today's evidence would be a guess. What can be said about its shape: a mid-walk failure is only invisible where the cap would have truncated the night anyway, so the auditable population is the nights whose coverage.list_complete reads TRUE — on those, a true could mean an exhausted list or a failure indistinguishable from one. An earlier draft of this entry called that irrecoverable, which was too strong and is corrected here. The first defect — the cap — was in force on every night from 2026-06-12 to 2026-09-08, and coverage.list_complete has read false on every night since 2026-06-28, so that bound was at least disclosed in the field.

The discontinuity is recorded in ADR-0002 §15 on the same footing as the 2026-06-12 cap raise in §1. A separate and unresolved question sits behind the numbers: the same walk that returned ~5,170 sellers in June returned ~1,455 in September. That is a fall in the upstream's 24-hour seller count, not an effect of this change, and it is being investigated before anything is said about it.

verify_before_pay decodes every recipient the live 402 names. Until 2026-09-06 it compared them against the caller's ?pay_to= when one was given, and against nothing at all when one was not. A caller asking only about a URL got the endpoint's live challenge decoded on one side of the response and Paddock's stored attribution for that domain on the other, with no comparison between them and nothing saying so.

The failure that matters is a compromised host. An attacker who changes only the recipient in the live challenge leaves everything our attribution is built from untouched — the domain, its settlement history, its facilitators, its circular standing are all still ours and all still clean. The response therefore carried Paddock's full endorsement of a seller while the money went to an address Paddock had never observed. Our stored attribution vouched for a wallet it had never met.

Reported by a design partner on 2026-09-06, from a live seller endpoint exhibiting the shape. The endpoint is not named here: a live recipient we have not attributed is also exactly what an honest wallet rotation looks like, and naming a host beside the word takeover would assert something this check cannot establish.

From 2026-09-06 the comparison runs on every call. checks.contract.attributed reports the wallets Paddock attributes to the domain, whether a live recipient is among them, and which live recipients are unattributed. target.pay_to_checked_against_live now means a comparison actually ran — against the caller's wallet, against our attribution, or both — where before it meant only that the caller had typed a wallet, which verified nothing.

The divergence is FLAGGED AND DOES NOT REFUSE, and that is a deliberate limit rather than caution. A seller that rotates its recipient wallet produces exactly this shape, because our attribution is built from settlement we have already seen and a rotation is by definition a wallet we have not. An independent census (Melchiorre Oliva, x402-measure, recomputed by us) found 37 of the 765 hosts present in both its 2026-08-10 and 2026-09-04 collections had moved payTo — 4.8% in three and a half weeks. Refusing here would refuse roughly one honest seller in twenty, which is the failure corrected on 2026-09-03 in the other direction, with the caller's money attached. The refusing control remains the caller's own ?pay_to=.

So the honest statement of what this buys: a caller who names no wallet is now TOLD when the endpoint is asking to be paid somewhere we have never seen, and is still not stopped. That is the strongest claim available without per-wallet destination history, which is #192 and which does not exist yet.

A seller's self-declared x402 config — the one surface where a seller states, under its own domain, what it charges and where the money goes — exists in the wild under two spellings: /.well-known/x402.json and /.well-known/x402. Paddock fetched the first and only the first, so a seller using the second was indistinguishable from a seller publishing nothing at all.

ReturnCheck (returncheck.m-angelmartinez-fer.workers.dev) is the case that surfaced it, reported by its operator in the x402 working group on 2026-09-03. An unpaid GET to its suffixless path the same day returned a complete v2 config: the payment resource, a Base mainnet accept with amount, asset and recipient, and the locations of both its HTTP and MCP payment endpoints. The .json path on the same host returns HTTP 404. Paddock's probe that day reported self_declared: unavailable for a seller that publishes all of it.

Both spellings are now fetched, concurrently under one timeout budget, and whichever serves a parseable config is the one judged. self_declared.source names the URL actually fetched rather than a fixed path, so a reader can see which spelling answered. The .json spelling keeps precedence in the case — not yet observed anywhere — where a seller serves both.

Nothing about how the config is JUDGED changed. self_declared remains advisory on exactly the terms set on 2026-09-03 earlier the same day: a divergence on payTo alone is flagged and does not refuse, a divergence on network, asset or price refuses. Finding a config where none was found before does not on its own move a verdict; it can move one only by disagreeing with the live 402, which is the check working.

The absence being corrected is the kind this log exists for: it was not a wrong number, it was a confident report of nothing where there was something. A bounded read-only sample of 60 CDP Bazaar seller domains the same day found zero publishing a parseable config at either spelling, which is the honest context — unavailable is the overwhelmingly common and correct answer, and that is exactly what made one false instance easy not to notice.

verify_before_pay takes ?endpoint_url= (the resource an agent is about to pay) and ?pay_to= (the wallet it is about to pay). It probed the endpoint, decoded the live 402, and compared the decoded contract against the caller's expected network, asset, seller and price. It did not compare it against pay_to. That parameter resolved the wallet to a domain through Paddock's own attribution and was echoed back under target.pay_to, and that was all it did.

So the narrowest question the tool can be asked — is the wallet I am about to pay one this endpoint is currently asking to be paid? — was the one question it did not answer, on the field where the caller has already committed. An x402 settlement is an EIP-3009 authorization that SIGNS the recipient. A buyer who read a stale challenge, or whose seller rotated addresses between their read and ours, got route: true and a signature addressed to a wallet the endpoint no longer named.

From 2026-09-03 the caller's pay_to is compared against every recipient the live challenge names, across every accepts[] entry rather than the one entry the response reports as `observed`. A wallet the endpoint offers on another entry — a different chain, typically — is reported and NOT refused; refusing there would repeat the multi-chain defect corrected on 2026-08-31, this time with the caller's money attached. A wallet the endpoint names nowhere is a refusal: route is false, pay_to is in mismatched_fields, and the summary names the recipients the endpoint does ask for.

One verdict moves the other way, and it is recorded here rather than left as a quiet loosening. A seller whose own published config (.well-known/x402.json) named a different payTo than its live 402 was refused. That refused the honest rotating seller every time — a published config is a snapshot, a challenge is live, and an address rotation puts the two out of step by design. A divergence on payTo ALONE is now flagged and does not refuse; a divergence on network, asset or price, or on payTo together with any of them, refuses exactly as before. The buyer is not less protected: the check that replaced it tests the caller's own stated recipient, which is a stronger claim than the seller's document about itself.

A third case was returning a clean answer about something nobody had looked at. Asked about a URL with no ?pay_to=, the circular-settlement check needs a wallet, and Paddock's attribution supplies one only when the domain maps to exactly one. A domain mapping to several — a provider rotating payTo addresses, which is ordinary — selected none, fell through, and could return status: pass, meaning “not flagged” asserted about a wallet that had never been examined. It now returns not_assessed, names the candidate wallets, and tells the caller to re-ask with the recipient they intend to settle to.

Found while scoping how Paddock should handle sellers that rotate payTo addresses, after a field report of one endpoint serving three addresses across twelve calls in a minute. The handling of rotation itself — a destination-churn note built on per-wallet history — is not built and is blocked on a series that does not exist yet. These three are the parts that needed no history: they were answerable from a single read all along.

A CDP Bazaar resource advertises a list of payment options — its accepts[] array — one per chain and asset it will take. A resource offering twelve chains has twelve entries. Paddock read the FIRST entry only and counted that as the resource's chain. So each resource counted once, under whichever chain its seller happened to list first, and the published figure was a function of array ORDER rather than of what sellers actually offer.

6,024 of the 14,590 resources in the catalogue (41%) offer more than one chain, so this was not a marginal distortion. Recounted over every accepts[] entry on 2026-08-31: Solana 5,732 against 259 published, Polygon 2,268 against 0, Arbitrum 2,176 against 1, BNB Chain 911 against 1, Optimism 577 against 0, Stellar 548 against 0. Base moved from 14,176 to 14,357 — barely at all, which is precisely why the defect survived: the one chain anybody spot-checked looked right.

The trend fields were worse than the levels. endpoint_change_pct and trend were deltas of an accepts[0] count, so a seller REORDERING its accepts array moved an endpoint from one chain to another with no change in anything it offered. "Solana +48% growing" and "Base −8% declining", served on 2026-08-31, were partly artifacts of array ordering.

The counting unit is now stated on every row rather than left to be inferred: one resource counts once per distinct chain it offers, so the rows do not sum to the resource total and are not meant to. The question the figure answers is "how many resources can I pay on this chain", which is a buyer's question. Testnets are excluded, as before.

This was found while auditing how Paddock parses a 402 challenge, after a cross-measurer parsing failure was raised in the x402 Slack. It shares its root cause with three defects fixed in verify_before_pay the same day: treating accepts[] as one offer rather than an offer set. One reading error on two surfaces — a live tool and a sold figure. The tool's version of it produced a visible refusal and got attention; the sold figure just looked plausible, which is the more dangerous of the two failure modes and the reason this log exists.

The corrected series begins 2026-08-31. The discontinuity is recorded in ADR-0002 §11 as a step change on the same footing as the servers[] boundary of 2026-06-12, and the guard is in code rather than in a note: any window spanning the date returns a null change and a trend of "basis_change_unavailable".

Both tools compared against LISTED prices: the advertised minimum a seller publishes to Bazaar. verify_before_pay divided the price on the live 402 by the median advertised price of providers in the category; get_best_value_provider normalised each provider's advertised minimum against the highest advertised minimum in the category and gave that 30% of the composite. Both now use SETTLED prices — USDC actually paid, divided by settlements actually counted, summed across a provider's payTo wallets before dividing.

The objection came from a design partner and it is the right one: a median over listings is what sellers hope for, a median over settlements is what buyers agreed to. An advertised price is a seller's own declaration, which is the exact class of number this product exists not to take at face value. A settled price is arithmetic over transfers an upstream already indexed, and no seller can move it by editing a listing.

The direction of the change is not uniform and can reverse a reading. An endpoint asking $0.20 in a category whose providers advertise a $1.00 median scored 0.2× — read as suspiciously cheap. The same endpoint against a settled median of $0.10 scores 2× — ordinary. Which of those is right depends entirely on which number the category actually transacts at, and only one of the two is a measurement.

Where no settled price exists, the answer is that it does not exist. verify_before_pay returns status not_assessed with price_basis “unavailable” and no ratio; get_best_value_provider scores that provider neutral on price and marks the row price_basis “unavailable”. Neither falls back to the advertised figure. Substituting a seller-declared number for a missing measured one would reintroduce the defect being corrected, and would do it invisibly.

Nothing was removed from either response. listed_price_median_usdc and listed_vs_median_ratio are still returned by verify_before_pay and still mean what they meant; price_usdc is still returned per provider by get_best_value_provider. The schema version is unchanged at verify_before_pay/0.1 because the change is additive: price_basis and settled_vs_median_ratio are new fields, and a shadow-mode integration logging the old ones keeps getting them.

get_best_value_provider's published formula string is updated in the route and in the docs to name settled_price_usdc, because a formula that does not describe what the code computes is worse than no formula.

Four governance documents — the index methodology spec, the rebalance calendar, the appeals process and the conflict policy — were merged as unpublished drafts and are published today. They define how a Paddock index is governed when one is published. No Paddock index is currently live: the Agent Commerce Index remains suspended, not retired.

The service levels differ from the draft, and the direction is looser rather than tighter. The draft carried four separate timing targets: acknowledgement in 2 business days, a completeness check in 5, a decision in 15 business days from acceptance, and a promise that an appeal filed in the provisional-list window would be decided before that rebalance took effect. The published commitment is two deadlines and one rule: acknowledgement within 5 business days of receipt, resolution within 30 calendar days of that acknowledgement with a written decision and the evidence relied on, and — where a resolution needs more time — an extension communicated before day 30 with a new date. The completeness check is folded into the acknowledgement rather than carrying a deadline of its own, and the provisional-window promise is removed.

Paddock is one person. A published service level that cannot be met by one person is worse than a longer one that can, and the draft's targets were set before anyone had to keep them. The rebalance calendar is amended to match: the provisional-list window is the invitation to contest a row, not a promise of a decision before the effective date, and an appeal upheld after a rebalance takes effect is given effect off-cycle instead.

The conflict policy gains two firewall statements the draft did not make explicitly. A licensee — an exchange, a HIP-3 perp deployer, a structured-product issuer — that conditions the licence on adding, removing, reweighting or retaining a constituent is refused the licence, and an existing licence is terminated on the same ground; the refusal is published. And Paddock never operates a market, facilitator, or gateway: no marketplace or exchange, no acting as an x402 facilitator, no gateway, router or proxy through which agent payments pass. The draft said Paddock does not operate a marketplace and did not name facilitators or gateways.

These four pages are now inside this log's scope. A later change to a service level or to a firewall sentence is a dated entry here naming the old wording and the new, not an edit to a page.

Paddock's circular-settlement detector identifies clusters of wallets that predominantly fund each other rather than receiving payment from outside. The classification it produces is what excludes those wallets from attribution.

The detector was never scheduled. Its classification was last computed on 23 June and had not been recomputed since, while figures derived from it continued to be published and sold. It now runs weekly, and a change to which wallets are flagged opens a pull request for review rather than taking effect automatically.

The first refreshed run moved the flagged 30-day volume from $215,915.91 to $238,031.14. Four wallets were newly flagged, together carrying $16,581.34 over 92 settlements in the trailing 30 days — settlement that was not being excluded from attribution and should have been. Two wallets left the flagged set because their only activity aged out of the rolling 30-day window; between them they carried $399.22 across 4 settlements.

The direction matters more than the size: the stale classification was under-excluding, so attributed figures published during the gap included a small amount of settlement that current methodology flags as circular.

Clarified sourcing language for liveness data.

Section 01 previously described the wallet-mapping source as a crawl of public agent-service listings. There is no continuous crawl. What exists is a small hand-maintained set of wallet-to-service mappings, each admitted only after an automated gate probes the domain's own live payment configuration and finds that wallet declared there. The gate runs when a mapping is proposed or changed, not on a schedule. The card now says that.

Section 04 attached a per-mapping verification claim to the whole map. That claim is accurate for the hand-maintained overrides and not for the catalog half, which is ingested wholesale from a third-party directory that Paddock does not individually audit. Both halves resolve forward from a seller's own declared configuration, which was and remains true; the difference is that only one half is individually checked. The section now distinguishes them.

Section 04 also did not state that attribution runs over a capped nightly sample rather than over every settlement. That fact was stated only as a caveat on one tile in section 02. It is now stated in the section that describes the method.

The Universe 3 tile in section 02 rendered without any caveat, while the Universe 2 tile above it carried one. Universe 3 needs it more: its numerator is counted only among the rows captured in the capped nightly fetch, while its denominator is the full uncapped settlement census. That ratio understates coverage by an unknown factor and is not a market share. The same computation had already been removed from the monthly report for this reason. The tile now carries a caveat naming the mismatch.

A wallet-attribution override for api.xona-agent.com was found to be simultaneously active and internally quarantined. The address was a Solana key that had been stored lower-cased; Solana addresses are case-sensitive, so the stored key could not match any live on-chain address and the service resolved to zero attributed settlement.

The dead entry has been removed. The service's real settlement wallet was identified and added through the normal evidence gate, which requires the wallet to appear as a payment recipient in the service's own published payment challenge. It settles 244 transactions totalling $10.43 over the trailing 30 days.

Separately, Capminal was the last tier-1 constituent whose artifact had never been fetched. It has now been verified against a live payment challenge carrying the expected recipient address. Every tier-1 row now carries a real verification status.

A review of every token that reached tier 1 by domain-name matching rather than artifact verification found that the tiering code assigned tier 1 whenever a domain matched, even when no settlement had ever been observed — while tier 1 is published as requiring settled 30-day volume. Three rows held tier 1 on that basis alone, with no matched wallet and zero transactions.

XONA AGENT and Tenna by Virtuals are reclassified tier 2. Both operate genuine payment endpoints, but the wallets settling their volume were not in Paddock's attribution graph. In XONA's case the wallet credited was an address this project had already flagged internally as unreliable. Scry Agent Ward is reclassified on the same grounds.

Four tokens matched the same unverified way — Aubrai by Bio, MiroShark, MOLTYCASH and Atelier — were confirmed tier 1 on live evidence, including decoded payment challenges for Aubrai and Atelier whose recipient addresses matched the wallets credited.

Concentration that should have been published from the start: the tier-1 market-cap share is 99.57% a single issuer. Excluding it, tier 1 is 0.2674% of the universe. The entire tier-1 cohort settled $451.34 across 31,927 transactions in the trailing 30 days. The market-cap share describes how much token value sits on top of a verified service; it does not describe how much economic activity those services carry, and should not be quoted as though it does.

A reported HTTP 404 at the artifact URL backing the largest tier-1 constituent was traced to the host serving no route at its root and publishing its discovery document under a different filename than the one conventionally checked. Those are the two paths a manual check tries first, so the service appeared dead while being fully operational.

The gateway is live and settling: 13,024 transactions totalling $138.23 over the trailing 7 days, against a recipient address carrying four active directory registrations with heartbeats minutes old at the time of checking. Chainlink remains tier 1.

Two corrections followed. The artifact URL recorded for Chainlink was a marketing homepage that has never carried a payment gate, and has been replaced with the live service descriptor. More significantly, the tier had been assigned by domain matching without ever fetching an artifact — the gap that triggered the review logged above.