Loading
Several of the figures on this site are also published by somebody else, and several of them disagree. This page is every one of those comparisons: what they report, what we count, and why the two are not the same number. Where we have not worked out the reason, the row says so.
We do not adjust our figures towards anybody else’s. We read higher than the reference on ten comparisons and lower on four comparisons. Moving a measurement to match a third party would replace evidence with consensus, which is the habit this platform exists to argue against.
A request is not a settled task. Olas counts requests posted to the mech marketplace over its whole life, from its own subgraph; we count fees that actually settled through the balance-tracker contracts we index, on seven chains, starting when our reader starts. Their own pair of figures shows the same thing from the other side: 11.9m requests produced 10.1m deliveries and $109k of fees, about a cent each. Our fee per settled task is within a tenth of a cent of theirs, which is the check that matters: the counts differ by contract set and window, not by arithmetic. Our side counts the settled rung ONLY. It used to add our deliveries to it, which put every task that was both paid and delivered in the total twice and made this row read as better coverage than we have.
The same rail counted at delivery rather than at request, and our side is now the delivery rung alone rather than every task row we hold. Still not our unit: a delivery we never saw recorded through a contract we index leaves no row here. The gap between their requests and their deliveries, about 1.8m, is their own measure of requests that never completed. These two rows are never added: /lifecycle says why, and one task produces up to both events.
Same rail, longer window, more contracts. Divide each side by its own task count and the two agree to about a tenth of a cent per task, which is the strongest evidence available that both are measuring the same economic activity over different spans.
The gap is a definition, and ours is the narrower one on purpose. x402 is an HTTP protocol; the only part that reaches a chain is a facilitator calling transferWithAuthorization, which emits EIP-3009 AuthorizationUsed. That primitive predates x402 and is used by things unrelated to it, so every AuthorizationUsed is not an x402 settlement. We count authorised transfers we matched to a paired transfer, on USDC only, on five chains, over the blocks named on this page. A tracker reporting hundreds of millions of x402 transactions is reporting the primitive and calling it the protocol. We would rather publish the smaller true number and the size of the assumption beside it.
We read higher and can show our working: an independent sweep of registry logs, run on a different code path from the ingest that fills the table, counted 50,619 against the table’s 50,699 a week later. Two readings of the same contract agreeing to within a week of growth is the check; matching somebody else’s number is not.
Same shape as ethereum: our independent log sweep counted 74,025 on the day it ran, against 84,808 in the table now. Both of our paths read the registry from before its first event to the head.
Ten per cent apart on the busiest chain in the registry, which registers thousands a day: a week of growth covers it. Our own sweep and our own table agree with each other here.
The largest disagreement on the page, and the one we checked hardest, because a figure eight times somebody else’s is the kind that turns out to be double-counted. It is not: our 1,815 rows are 1,815 distinct transactions with 1,815 distinct agent ids. We took the most recent one back to the chain — 0x257ea4ab…a723 at block 94,390,886 — and it is a successful call to the canonical registry address emitting a mint and a Registered event. Where we differ here, the chain agrees with us.
The one place we read materially lower, and the best-evidenced row here in one direction. OUR figure is confirmed three independent ways: the weekly log sweep counted 4,701 on 29 August, the ingest table held 5,039 on 3 September, and on 5 September the registry was walked by hand from its deployment block 58,396,724 in 3,665 windows and answered 5,446 — three paths, three dates, one growth curve of about 150 a day. What their number counts is still unsettled, and two cheap ways to settle it have now been ruled out: the registry exposes no totalSupply or any other counter on any chain we asked, and no free Celo endpoint will serve a Transfer-topic walk of the contract’s whole life without truncating. So the remaining routes are a paid archive index or simply asking them what they count. We would rather ask.
Two tenths of a per cent apart. Nothing to explain, and it is here because a reconciliation table that only lists disagreements is not a reconciliation table.
A hundred registrations apart on a chain adding a few a day. Consistent with the dates the two figures were read.
Small numbers on a young chain. We found this chain from the vault side rather than the registry side, and it was not on the weekly sweep at all until recently, so our own history here is shorter than our count suggests.
Every provider means a different thing by "vault", and neither count is a coverage claim. We are not the largest list and do not sell one: what is here is a cohort we can read positions, flows and closures for, including the ones that died. A larger directory of vaults nobody can look inside is a different product.
The same vault, the same quantity, two prices. Our nightly check reported us above the venue on this vault for weeks and read it as our error; it is not. The vault holds the quantity below, which the contract answers directly through totalAssets(), and the two figures divide out to two different prices for a BNB. The tell was the two stablecoin vaults beside it agreeing to a tenth of a per cent — where the price is 1 by construction the readings match, and where it is not they do not. We publish this rather than quietly matching them, because a venue’s own dashboard being stale is exactly the thing somebody sizing a position needs to know.
488,124.84 WBNB read 5 September 2026. Their figure values it at $721.39 each; ours at $726.52 each, computed 20 October 2026.
Every row above is a figure a person read off somebody’s page on a stated day. This is the other kind: for each vault we can match, what DefiLlama publishes about that vault, stored beside our own reading and never blended into it. It covers 830 of 3,794 open vaults, $9.82B of $11.44B. What it does not cover it says nothing about.
Their headline includes rewards and ours excludes them, so a gap here is as likely to be the definition as the arithmetic.
With a floor of $100k, because two readings of a dust vault taken minutes apart differ by more than a tenth without anything being wrong.
Their judgement that a rate is implausible, printed as theirs. A disagreement about meaning rather than about arithmetic.
We hold a spot rate and no history of it, so a vault that never paid and one that paid and stopped are the same row to us. They publish a thirty-day mean.
Agreement is not proof: the same mistake made twice agrees with itself. What this rules out is the shape that cost us most, where a figure is confirmed by a check computed from the same inputs. A holding that was not there survived a check run every three hours, because that check multiplied the chain’s quantity by our price for our underlying, and our underlying was wrong. An outside auditor found it before we did.
On some of these, yes, and it is ordinary work: a network nobody had thought to look at is a gap we close the week we find it, and three of them were closed this week. On others, no, and the reason is not resignation.
What we sell is not the size of the corpus. It is that for what is in it we hold positions, flows, closures and the dead, and that every figure says where it came from and what it does not cover. A bigger list bought by loosening a definition would cost exactly the thing that makes the list worth reading.