How every number on this site is produced, what is excluded, and what cannot be seen. Permanent and versioned; every change is in the changelog at the end. Written to be quoted. Where TOLL is uncertain, it says so here rather than rounding the uncertainty away.
Every record in the Coinbase CDP discovery catalogue carries three quality counters: l30DaysTotalCalls, l30DaysUniquePayers and lastCalledAt. TOLL pulls the full catalogue every six hours, unauthenticated, page by page, and appends one row per endpoint per pull to an append-only table. Nothing in that table is ever updated or deleted. Every Ledger page is built from one snapshot and prints that snapshot's timestamp. Binance's registry publishes no counters, so its 128 exclusive listings appear in the index without them.
Across five snapshots spanning 66 minutes on 10 September 2026, not one endpoint's calls or last-call timestamp changed. The registry recomputes its counters on a schedule of its own; TOLL samples every six hours, more often than they change. So far 28 snapshots have been taken since , of which 25 carried a change from the previous one. The series on the Ledger page marks every snapshot and draws its trace through the changed ones, and states the observed refresh cadence as it accumulates.
On the current snapshot 12 endpoints report zero calls in 30 days and still carry a last-call timestamp inside the 30-day window. Either the call count excludes something the timestamp includes, or the two windows differ. TOLL does not know which and does not guess. The earliest last-call value on every snapshot is 30 days before it ( on this one, latest ); nothing older is retained by the registry, so an endpoint last called 31 days ago is indistinguishable from one never called, and dormancy figures are bounded at 30 days.
The 12 endpoints with zero calls and a last-call timestamp inside the window
l30DaysUniquePayers is counted per endpoint. One wallet paying twenty endpoints is counted twenty times. Wherever the site shows a total of payers it is the sum of those per-endpoint counts, labelled as an upper bound, and it is never presented as a count of unique payers. Global uniqueness is not derivable from the quality counters; it needs on-chain settlement data, which is a later phase.
The share of endpoints with counters whose calls and unique payers both equal 1 on the snapshot. It is the share of the index that has been touched once, by whom the counters cannot say.
Pearson's r between l30DaysTotalCalls and l30DaysUniquePayers across every endpoint with counters on the snapshot, computed by Postgres's corr(). A value near zero means volume and breadth of use are unrelated: the endpoints with the most calls are not the endpoints with the most payers. Rows where either counter is absent are excluded from that pair and from no other figure.
Both counters are heavy-tailed, and Pearson's r on a heavy-tailed pair is carried by its largest points. Between 10 and 14 September 2026 the published r rose from 0.11 to 0.40 while one endpoint grew from 3,147 calls and 246 payers to 52,038 calls and 1,985 payers, becoming both the largest by calls and the largest by payers; removing that endpoint alone returns r to 0.10. Over the same days the same set of endpoints, the rank correlation and r across the endpoints outside the top 1% by calls all held still. Two figures are therefore published beside Pearson, and neither replaces it: Spearman's r on the ranks of the same two columns, and Pearson across every endpoint outside the top 1% by calls. The sentence each page states is chosen from the value at that snapshot rather than written once, so it cannot go stale under the figure it describes. All four measurements at every snapshot, the endpoint that carries the published one, and what follows for aggregate figures about a market this concentrated are on the correlation page.
Endpoints are sorted by calls, descending. The top 1 percent is the largest whole number of endpoints not smaller than 1 percent of the count; its share is the sum of its calls over the sum of all calls. The same for 10 and 50 percent. Deciles use linear interpolation between neighbouring ranks. Buckets are fixed and printed. No seller cap applies on Ledger pages: the concentration is the finding.
The payTo address of the first accept on the endpoint's primary registry record (Coinbase where it is listed there, otherwise Binance). It is a payment address as declared by the seller. It does not identify a person or a company, and TOLL never claims it does. Endpoints sharing a payee wallet are grouped on a seller page for that reason only. EVM addresses are compared case-insensitively.
From one catalogue pull: every record's last-call timestamp is floored to a 10-minute UTC boundary. For every window with at least 50 records TOLL computes the number of records, the number of distinct hosts, the largest share of records paying to one wallet, the share with exactly one unique payer, the median call count, and the span in seconds between the earliest and latest timestamp. A window passes when the top wallet share is at least 80%, the single-payer share is at least 80%, and the median call count is at most 5. Every candidate window is published with its measurements and its pass or fail; the thresholds are printed in the column headers. The candidate set moves with the trailing 30-day span of the last-call field, so the count of windows differs between snapshots under the same rule; each list states the snapshot it was computed from.
What the rule measures is a signature, not a motive. A seller smoke-testing a fresh deployment and a seller inflating its own metrics produce identical windows. The counters do not name the payer or record why a call was made. The Ledger reports the measurement and the rule version that produced it, and never states or implies intent. Named sellers have a right of reply through the public form, published unedited. Any change to a threshold, the window size or a measurement creates a new rule version and a changelog entry; lists produced under a prior version stay published under their stamp.
From the same snapshot: every listed endpoint whose counters show at least 100 calls in the trailing 30 days and exactly one unique payer. This is a reading of two published counters and involves no timing rule, so it is published on its own page, /ledger/single-payer, rather than under the burst windows: high volume from one payer is what a working integration looks like from outside, and listing it beside burst windows would misread it. An endpoint with two payers cannot be classified, because the split between them is not published. The counters do not name the payer or say whether it is related to the payee; that needs on-chain data. The page's share figure is the calls of qualifying endpoints over all calls counted at the snapshot.
A successful pull of a registry is an observation of everything it lists. An endpoint listed at the previous pull and absent from this one is recorded as delisted at this pull's timestamp: a raw delisting. The catalogue's page order drifts while it is being read, so a listing can miss one pull and reappear. A delisting is confirmed after 2 consecutive successful pulls without the endpoint (rule version 1), as its own event; reappearance is a relisting and restarts the count. Confirmed is the headline figure, raw is always beside it.
TOLL measures whether a registry lists an endpoint and nothing more. An endpoint absent from the Bazaar may have been withdrawn by its seller, failed the registry's own validation, or been restructured under another URL; the service behind it may be running untouched. No page on this site claims a service is dead. A delisted endpoint keeps its page, with its last observed state and the date it was first observed absent.
Once a day TOLL calls Coinbase's validate endpoint for every listed endpoint that declares an HTTP method, sending that method. The verdict is read from the response body, never from its HTTP status, which is 200 even for hosts that do not exist. pass means the body says valid: true. fail means the endpoint was unreachable or did not return HTTP 402. malformed means it returned 402 but failed one or more required preflight checks. legacy_v1 means it returned 402 with the x402 v1 protocol. unknown_method means the listing declares no method, so validate is not called. unobserved means validate itself did not answer, on a timeout, a 5xx or an unparseable body; it says nothing about the endpoint and is excluded from every uptime figure. The named checks that failed are stored on every observation. Two checks, bazaar.info.output and bazaar.info.output.example, are advisory: validate reports them with severity “advisory” and an endpoint failing only those still passes. The full response body is kept on an endpoint's first observation and whenever its state changes.
Over a window of 7, 30 or 90 days: the number of sweeps at which the endpoint was pass, divided by the number of sweeps that observed it (pass, fail, malformed or legacy_v1; unobserved excluded). Each page prints the counts beside the percentage. With one sweep a day the 7-day figure rests on at most seven observations.
The latest finished sweep, daily-2026-09-15, planned 15,523 endpoints and completed 15,708 between and , 203 minutes wall time, with 2 unobserved. Calls are paced to at most two per second with four in flight; validate itself takes two to three seconds per probe, so the observed rate is about 1.3 calls a second and a clean full sweep takes about three hours. Registry pulls so far: 56 succeeded, 2 failed (last: binance at ). Every pull, successful or not, is a row, so a gap in the series always has a stated cause.
The index covers the Coinbase CDP discovery catalogue and the Binance B402 bazaar, deduplicated on canonical URL: scheme and host lowercased, trailing slashes removed, the fragment kept only for MCP tool listings. Endpoints outside those registries, and calls made through other facilitators, are invisible to every number here. The counters cover CDP-facilitated calls to listed resources only. “Endpoints listed now” counts endpoints present in at least one registry at the last pull; it is registry state, so it is marked live rather than pinnable wherever it appears.
Neither registry supplies a title, a listing date, a category, a human-readable price or a URL slug. TOLL derives all five and marks each as derived where it appears. First observed is TOLL's own first observation; observation began on 10 September 2026, and every listing that predates it shows that date. Title is the last two meaningful path segments. Category comes from keyword rules, version 1, matched on the path first and the full text second; the rules are in the repository and the “other” category is where nothing matched. Price is the declared smallest-unit amount converted with a table of verified asset decimals; where the asset is not in the table the raw amount is shown and the page says the decimals are unknown. Nothing is guessed. Amounts declared as decimals rather than integers, as some XRPL and other listings do, are shown as not declared.
A dash in a table cell or beside a reading means no value was observed, and never zero: a counter the registry did not publish, a sweep that did not reach the endpoint, a price TOLL cannot compute because the asset’s decimals are unverified. Zero is printed as 0 wherever zero was measured.
Every accept in every registry record is stored as declared, with the registry it came from. Network identifiers are shown as declared, with pre-CAIP-2 names such as “base” mapped to their CAIP-2 form. The list of networks on the site is derived from this data, not maintained by hand. Since 12 September 2026 at 20:44 UTC every pull also appends the full accepts array of each endpoint whenever it differs from the previous pull's, so a change of price, payee or network is dated rather than overwritten. Where a listing names several networks, the network index counts how many listings name each pair; a number recurs there that TOLL has not explained. 851 listed endpoints declare almost every pair of the twelve largest networks, and the figure is the same for pairs that otherwise have nothing in common. One seller listing the same endpoints on every network it can would produce that signature, and so would other arrangements. It is recorded as an open question in the changelog, and nothing is stated about its cause until it has been looked into.
Up to five listed endpoints in the same category, nearest by declared price where both prices are comparable, then most called, at most one per payee wallet.
Every ranking page caps any one payee wallet at three rows and prints how many rows it folded; the concentration page shows the distribution the cap hides. The index itself suppresses nothing: category, network and seller lists carry no cap, list every endpoint most called first with a fixed tiebreak, and are paged by path segment, 100 rows to a page, so every endpoint is reachable by links. Until 13 September 2026 the category and network tables carried the cap and stopped at 300 rows; the changelog records the change.
Every Ledger page exists in a pinned form at <page>/at/<stamp>, where the stamp is a snapshot's UTC minute with hyphens for colons, for example /ledger/bursts/at/2026-09-12T15-30Z. The pinned page renders from the snapshot taken in that minute and nothing on it changes afterwards, which is what makes a figure quoted from it checkable later. A stamp between snapshots redirects to the latest snapshot at or before it, so every pinned URL in circulation is a snapshot's own. The validation page pins to the latest daily sweep finished at or before the stamp and names it. Pinned views are not indexed by search engines; the live page is canonical. Every timestamp tag on the site says which of four things its figure is: pinnable, read from an append-only table and stable under a pinned URL; pinned, the same figure on a pinned view; live, registry state at the last pull, which moves with the registries and is not part of any snapshot; or final, the last observation of a delisted endpoint, which no later snapshot will change. Endpoint pages pin too, at /e/<slug>/at/<stamp>: the counters from that snapshot, the payment options as last declared at or before it (from the accepts history, kept since 12 September 2026 at 20:44 UTC), and the validations and presence events up to it. The comparisons in the prose and the similar-endpoints block are live and are not part of the record, so a pinned endpoint view leaves them out. Pinned views hold only as long as the snapshots behind them exist: the quality table holds 412,444 rows across 28 snapshots as of this build, grows by about 14,500 rows every six hours, and TOLL commits to never deleting from it. The method page is not pinned; it is the permanent record and is dated through the changelog.
Every Ledger page, the delistings, and every endpoint are available as JSON under https://tollindex.com/api/v1, free and without a key. Every body names the snapshot it was built from and the rule or method version that produced it; Ledger bodies take ?at=<stamp> and resolve it exactly as a pinned page does. The path is versioned from the first commit: a field's meaning never changes under /api/v1, and anything that would change one goes to a new version while the old one keeps serving. Responses are cached at the edge for six hours, the same cadence as the pages. The data is published under CC BY 4.0: reuse it, with attribution to TOLL and a link to the page cited. The registry records inside the endpoint bodies are the registries' own and are passed through untouched.
The pages under /vs/ set what another site publishes beside what TOLL publishes, row by row, in the other site’s own terms where possible and with no adjective. A fact about another site decays: every comparison page prints the date its facts were read, first and before the table, and lists the pages read. The rule is that each comparison is re-checked at least every 30 days; a page whose check is older than that says so above its table and asks the reader to treat every fact as possibly moved. A re-check moves the date even when nothing changed. A correction from anyone, the site compared included, goes through the public form and is published with its outcome, and the table is updated with a new check date. The Coinbase Bazaar is TOLL’s source and is not compared.
Thirteen sweep runs left open, and what the status page now says about them
A new-listings sweep probes the endpoints a pull has just added, in chunks of two hundred, and a run is closed only when its last chunk clears the queue. A run that fills its chunk is therefore left open on purpose and continued by the next one, which the status page already showed as such. Three rows were that. The other ten were not: the sweep worker stopped part-way through a chunk and restarted, and because a new-listings run takes its identifier from the clock, a restart opens a fresh run rather than resuming the old one, so the abandoned row stays open with nobody to close it. The worker event log shows the restarts that made them, on 11 and 12 September. The endpoints those runs had not reached were swept by the run that followed, so the measurement record has no hole; the run table does. They went unremarked for four days because the status page lists the ten most recent sweeps and eleven of the thirteen were older than that. It now states, as a figure of its own, how many run rows are open and not writing, how long the oldest has been silent, and how many others are open by design.
Audit gap: seven tooling failures in one day, and what each was hiding
TOLL publishes the gaps in its collector and the gaps in its audit, so it publishes the failures of the tools that produce both. Seven on 15 September. The verification script cleared its port by matching a command line that stops matching once the server is up, so a full run — accessibility, design, colour, overflow, every page type — was measured against a server left from a run two and a half hours earlier whose build had since been overwritten, while the script reported that it was serving the build it had just made; it now clears the port by process id, refuses to continue if anything still holds it, and checks that the process answering is the one it started. The stale-stamp race was then diagnosed wrongly twice, once from a query ordered by identifier instead of by time, which hid the pull that had in fact run through the build, and once by blaming the writer, which already commits a pull in a single transaction; the fault was on the reading side, where a figure counted in one statement was stamped from another, and the stamp now travels inside the counting statement. And the figure gate itself had a hole older than any of this: it asked whether every source of a figure stood at its own instant, so two sources agreeing and a third adrift at an instant of its own was neither compared against them nor counted as unexplained, and a drifted source was invisible. It was found by planting exactly that and watching the gate pass. The gate now tests for an instant at which one source stands alone, and a figure may go uncompared only if the database attests to a reason: every instant a real pull boundary, or all of them inside a sweep that was running. Anything else fails the build. The last two were in the repair of the first: the verification script was edited while a run of it was in progress, and because a shell reads a script as it executes it, the run died on a line that was valid and five sections of completed work went with it; it runs from a copy of itself now, and the first version of that copy named itself with a template whose wildcard was not in the last position, so one fixed filename was created and the following run refused to start. Both are fixed and both are here, because a failure in the repair of a failure is the kind that goes unrecorded. Seven in a day is a class rather than a run of bad luck, and the class is worth more to a reader than the list. Four of the seven were a tool reporting a result it did not have: the verification script stating it was serving the build it had just made while a stale server answered; the figure gate stating that no figure went unexplained while a planted fault sat inside it; and two runs reported as under way, one already dead on an edited script and one never started at all. What they share is a silence that looks like a pass, because a tool that found nothing and a tool that did nothing print the same thing. Three of the four were caught by making the tool fail on purpose — planted faults, a figure stamped with an impossible date, an interrupted run and a restart — and the fourth only because a number moved when nothing should have moved it. Two more were not tool output but readings of evidence, each corrected by looking at the evidence a second time rather than trusting the first look. No new rule follows from any of this. The two already written down are enough: a tool proves it can fail before a zero is believed, and a run that happened before the change does not verify the change. What was new on 15 September was pointing them at the tools that enforce them, which is the one place they had never been pointed. The seventh is the reason that matters. The check written to abolish the excuse category contained a blanket excuse of its own: a sweep row left open was read as a sweep still running, and its window was taken to run from the row’s start to the present, so the oldest of thirteen rows abandoned days earlier would have excused any two instants in the last four days. The companion check that reports whether this is a quiet minute to build in read the same rows the same way and raised an alarm that could never clear, which carries as much information as one that never raises. A run’s window now ends at the last verdict it actually wrote. Three of the seven, counted this way, were a check excusing itself.
A stated convention: the dash that means no value, and why it stays
An em dash standing alone in a table cell means TOLL has no value to put there. It appears in twenty-three of the site's source files and the design detector counts every one of them as prose, reporting an overuse of em dashes on three pages. The finding is left standing rather than swept: replacing the dash properly means saying, at each site, which silence it is — a registry that publishes no such field, a field published empty, a figure that cannot be computed from what is on record — and those are different statements that only the page in question can make. The endpoint and comparison pages have been through that already and carry the words instead: no counters published, not yet swept, never swept, not ranked, not computable. The rest will be converted the same way as each page type is rebuilt, one at a time and with the reason stated, and until then the detector's count on those pages is expected rather than accepted silently.
The site is arranged as a marketplace, and three faults that found
Every page type now opens with the same head, tables sit in cards under a tinted head rather than a solid ink bar, and the listing and comparison pages carry the arrangement a buyer expects. Rearranging it surfaced three disagreements between pages. Sweeps run counted every validation that was not unobserved, so a comparison read 0 of 4 where the endpoint's own page read 0 of 0; both use the population the endpoint page uses. An endpoint with no counters was ranked against the endpoints that have them and came out 1,658th of 1,657; it is not ranked. A payee's reach counted declared payment options rather than endpoints. The comparison page's call and payer figures carry the same ids the endpoint pages carry, and the figure check reads it before every deploy.
Audit gap: the verification script measured a server it had not started
The script that produces every clean claim about this site cleared its port with a pattern match on the command line. Once it is up, the server's process is named next-server, so the pattern matched nothing: the previous run's server survived, the new one exited with the port already in use, and the readiness check — a connection rather than a status — was answered by the survivor. A full run on 15 September reported 509 design findings and horizontal overflow on thirty page types, all of it measured against a server left from a run two and a half hours earlier whose build had since been overwritten on disk, while the script printed that it was serving the build just made. The port is now cleared by process id, the run stops if anything still holds it, readiness means a 200, the process answering is checked against the one the run started, and the server is stopped when the run ends. Published here because a site that reports its collector's gaps reports its auditor's.
Stacked tables keep their semantics, and their labels leave the stylesheet
Below 640px three tables stack their columns so a sentence column is readable on a phone. Two things about that were wrong. The row headers and cells used display:contents, which removes an element from the accessibility tree outright rather than restyling it, and the substitute column labels were generated content, which is not read reliably, not copyable and not translated. The cells are ordinary blocks now with explicit table, rowgroup, row and cell roles so the semantics do not depend on how a browser treats a display override, and every substitute label and unit is an element in the page. Verified against the accessibility tree at 375 pixels.
Open question: the count of 851 across almost every network pair
Drawing which networks are declared together surfaced a number that recurs: 851 listed endpoints declare almost every pair of the twelve largest networks, and the figure is the same for pairs that otherwise have nothing in common. A single seller listing the same endpoints on every network it can would produce exactly that signature, and so would several other arrangements. It is recorded here as an open question rather than a finding: TOLL has not investigated it, states nothing about who or why, and will publish what it finds when it does, upheld or not.
The calls-to-payers correlation is carried by one endpoint
The published Pearson's r rose from 0.11 on 10 September to 0.40 on 14 September. Investigated: the same endpoints present at the first and last snapshot show the same rise, so it is not the index changing composition; the rank correlation held between 0.64 and 0.66 at every snapshot, and Pearson across the endpoints outside the top 1% by calls held between 0.53 and 0.56. One endpoint, q verdict resource on www.ax1.vc, grew from 3,147 calls and 246 payers to 52,038 calls and 1,985 payers and now holds 13.3% of all calls counted; removing it alone returns r to 0.10. Nothing in the collector changed. Pearson stays the published figure and is not restated; the rank correlation and the trimmed figure are published beside it, and the sentence each page states is now chosen from the value. All four measurements at every snapshot are published on a page of their own, /ledger/correlation, with the endpoint named and the right of reply.
Audit gap: readings announced without their label, and its fix
Screen-reader testing on 14 September found that a reading's value could be announced without the label before it, and the finding was deferred and published here unresolved. Rebuilding the readings as panels did not fix it: the panel flattened to loose text with nothing tying the number to what it measured. Each reading is now a named group, and the value carries its label in its own accessible name, so landing on the figure announces what it is and then what it reads. Verified against the accessibility tree on 14 September 2026.
Audit corrections and the figure check
Pass share is passing over observed on every page; the home and category index had divided by listed. Raw delistings count every endpoint absent at the last pull on every page and in the JSON, which had counted only the unconfirmed ones and now names those as not_yet_confirmed. The curated count includes listed endpoints only. Every figure that appears on more than one page carries its id and snapshot in the markup, and a check that one snapshot yields one value everywhere runs before every deploy. Links in prose are underlined; report outcomes are announced and land on the docket; the measure is recorded as a stated exception.
Audit gap: the design detector was not running
From 13 to 14 September the design detector used on every redesign phase failed to launch a browser on the build machine and reported an empty list; phases 3 to 6 were recorded as having zero detector findings on that basis. Run against a working browser on 14 September, the same pages carried 42 axe-core violations and real line-length and overflow findings. The violations are fixed; the audit is in the repository as ops/audit-2026-09-14.md.
Asset, cheapest and question pages; feed, data page, structured data
Pages per payment asset with an index that names every asset TOLL cannot price; a canonical cheapest page per category; three question pages answered from the data; /data, llms.txt and an Atom feed carrying changelog entries, changed snapshots and confirmed delistings; social images per page type with a delisted variant; structured data; a sitemap index; and a footer that reaches every page.
Comparison pages and the status page
Three comparison pages, each with its check date first and a 30-day re-verification rule; a status page showing every pull, sweep, restart and alert as a row, with the performance baseline.
Endpoint pages: the delisted state, pinned views, marks
A delisted endpoint's page opens with a banner, states once that every figure is final, and keeps the presence timeline; the URL never goes away. Every endpoint page gains a pinned form at a snapshot stamp and a citation. Verdicts everywhere are pen marks with their word; the folded rows on ranking pages are drawn as a line where they would have been, naming the wallet and linking its seller page.
Category and network lists uncapped and paged
The seller cap of three rows now applies to ranking pages only, as Section 6.3 of the specification states. Category, network and seller lists show every endpoint, 100 to a page by path segment; before this they were capped and cut at 300 rows, so most of the index was reachable only through the sitemap. Search gains trigram indexes and a ten-minute cache per query.
Accepts history, pinned views, JSON version 1
Every pull appends each endpoint's full accepts array when it changes, so price and payee changes are dated. Every Ledger page gains a pinned form at its snapshot stamp and a citation with the pinned URL. The JSON under /api/v1 publishes every Ledger page, the delistings and every endpoint, under CC BY 4.0.
Category rules and site launchrule v1
Category rules version 1. The site goes live.
Burst rulerule v1
Thresholds as stated under burst windows on the method page. First full daily sweep the same day.
Delisting confirmation rulerule v1
A raw delisting is confirmed after 2 consecutive successful pulls without the endpoint. Confirmed is the headline figure, raw beside it.
Observation begins
First quality snapshot at 19:08 UTC. Every listing present at that pull carries it as its first-observed date.