We checked every number on our own site. Then we checked everyone else's.
We spent a day auditing the yield and the size of all 64 assets we rate. We
expected to find drift. We found something worse, and then found the same
problem in the sources the whole sector treats as ground truth.
Our own results first, because we have no standing to write the rest of this
otherwise.
What was wrong with ours
Fifteen of sixty-four published sizes were wrong by more than 25%. Four were
wrong by over 10x.
The worst was Aave V3 USDC. We published $4.80bn. The pinned market held $174M,
and the entire Aave v3 USDC complex on Ethereum in the yields feed came to about
$235M across four markets. Our figure was roughly twenty times anything findable
and had no source at all.
Savings DAI was published at $2.22bn against roughly $205M. That is a
pre-migration figure: deposits moved to sUSDS, which now holds about $4.62bn,
and our number never followed.
The rate side was worse in a different way. Sixteen of twenty matchers had
silently died because upstream project slugs were renamed, so four of
fifty-nine assets were actually updating. For twelve months the site advertised
14.5% on a Beefy vault that had been retired after an exploit, and called it the
highest yield we tracked.
Two of the errors were not staleness
This is the part worth generalising, because a freshness check would never catch
it.
BlackRock BUIDL was published at $5.00bn. That number is real and current.
It is Securitize's platform-wide assets under management, stated in their own
investor communications. It is not BUIDL's fund AUM, which is about $2.64bn. We
had taken a true number about the platform and published it as a number about
the fund.
Usual USD0 was published at $101M. Also real. It sits at DeFiLlama's
protocol-page figure of roughly $92M, which counts only the on-chain-visible
collateral basket. That is a TVL measure. USD0's circulating supply is $550M. We
had published a collateral figure as a supply figure.
Both were correctly copied from a legitimate source. Both measured something
else. We now call this a wrong-metric error and treat it as a different class
from staleness, because the tooling that catches one is blind to the other.
Then we checked the sources
Auditing our own numbers meant reading the aggregators closely. They have the
same problem.
DeFiLlama's BUIDL protocol page reports about $3.45bn. Its Aptos adapter
reports 821,933,062 BUIDL. We queried the Aptos indexer directly for the same
asset and read 16,186,193. That is an overstatement of roughly $806M on a single
chain, and the series shows three step-jumps that correspond to no on-chain
event. Note the stablecoin endpoint for the same token is fine at $2.64bn, so
which DeFiLlama surface you read decides whether you are 30% out.
CoinGecko carries 10,252 LBTC. DeFiLlama's native-token series says 8,968.5
BTC and StakingRewards says 8.55k. Two sources cluster and one does not. On
Liquid Collective's LsETH and StakeWise's osETH, CoinGecko runs 4 to 5 percent
below both protocol NAV and the live DEX quote, because its price feeds for
those tokens are dragged down by thin venues. Historical "depegs" derived from
those feeds are data artifacts, not events.
rwa.xyz undercounts BUIDL's Solana supply by about $45M against a direct
Solana RPC read, while being accurate on the nine other chains and correct on
Aptos where DeFiLlama is not.
We are not claiming these are careless. They are wide-coverage systems and this
is what wide coverage costs. The point is narrower and more useful: on any
given asset, the aggregators disagree, and the disagreement is often larger than
the number a reader is trying to act on.
The structural problem underneath
Three defensible definitions of size can differ by more than 10x for the same
product.
OpenEden's TBILL is the clean example. The Ethereum pool holds about $21M. Summed
across chains it is about $253M, most of it on BNB Chain. We had published $80M,
which matched neither. All three are answers to reasonable questions. None of
them is the TVL.
The same trap runs through the category. A rate source is not a size source:
wstETH and stETH share a yields-feed pool that measures stETH supply, not
wstETH's, and every wstETH entry in that feed is a lending market, which counts
collateral rather than supply. Summing those would count the same tokens at four
venues.
So the fix is not a better source. It is declaring the measure. Every asset
in our corpus now pins a source and a definition: token supply, protocol AUM,
vault assets, or programme AUM. Where none applies, the asset is unbound and the
site shows no number rather than a plausible one.
What we changed
Every rate and every size is now pinned to a named source in a file anyone can
read. The refresh jobs are built to fail rather than guess: if a pinned pool
disappears, the run goes red and nothing is written. A first correction of more
than 25% on an asset that has never refreshed cleanly is held for a human,
because a legacy number and a market move are different events.
Thirty assets are unbound. Those show no rate or no size at all, and we
publish the list with the reason for each in the refusal
ledger.
Two of our own pinned pool IDs turned out to be fabricated. The recorded expected
values matched the live pools exactly, which is how we know the right pools were
read and the wrong identifiers written down. The pipeline caught both on its
second run, which is the only reason this paragraph exists.
What a reader should take from this
If you are sizing a position in a tokenized asset, the published figure is a
claim with a definition attached, and the definition is usually not stated.
Ask which chains it counts. Ask whether it is supply, fund AUM, or collateral.
Ask when it was last actually read rather than last displayed.
If you build one of these datasets, the cheapest useful change is to make the
measure explicit per asset. We did it after fifteen errors, not before.
Every figure here was read on 25 August 2026 and is reproducible from
lib/rate-sources.json, lib/tvl-sources.json and the public endpoints named
above. Corrections to research@realworldtokenspace.com and we will publish them.