Our DePIN dataset is built to be irresistible because it is checkable. Every value names the source it was read from and links straight to it. Batch verification depends on retained rows and a verified OpenTimestamps proof. You do not have to trust us — you can verify.
Live-coverage figures are separate from dated batch membership and do not describe the historical batch below.
The atom of our dataset is not a number — it is a number with its paperwork. Every value we serve carries the same seven-field shape.
{
"symbol": "AKT",
"metric": "price_usd",
"value": 0.506855,
"unit": "usd",
"source": "CoinGecko /coins/markets",
"verify_url": "https://www.coingecko.com/en/coins/akash-network",
"as_of": "2026-08-09T17:15:20Z"
}symbol / metric — what this measures, keyed so agents can join it.
value / unit — the measured number and its unit. Never rounded up past source.
source — the exact upstream feed the value was read from.
verify_url — a link you can open right now to check the value at that source.
as_of — the timestamp the value was true. Stale is shown, never hidden.Row-shape example. Its as_of timestamp is historical; the source link is not a batch-inclusion proof.
We do not pretend everything is first-party. Each series is labelled with the tier it came from. The largest tier is read directly from the network's own API or chain; the rest are named market and protocol aggregators.
| Source tier | Live series | What it is |
|---|---|---|
| CoinGecko /coins/markets | 8,499 | Market facts: price, market cap, circulating & total supply. |
| subtensor_rpc | 4,526 | Bittensor subnet economics read from a subtensor RPC node. |
| geckoterminal_dex | 1,362 | First-party telemetry read from the source's own public endpoint. |
| dexscreener_pairs | 1,294 | First-party telemetry read from the source's own public endpoint. |
| github | 936 | Public development activity: stars, forks, issues, days-since-push. |
| first_party_api | 803 | Read straight from the network's own API — verify_url points at the network itself. |
| evm_blockscout | 701 | Token supply read from EVM chain explorers. |
| cosmos_lcd | 238 | Cosmos-SDK chain state read from a public LCD endpoint. |
| solana_rpc | 220 | Solana account and supply state read from a public RPC node. |
| akash_console | 193 | Akash provider capacity and utilisation from its own console API. |
| DefiLlama /overview/fees | 139 | Protocol fees, revenue and TVL from DefiLlama's public API. |
| CoinGecko /coins/{id} community+developer | 126 | Market facts: price, market cap, circulating & total supply. |
| dexscreener_tokens | 114 | First-party telemetry read from the source's own public endpoint. |
| bsc_rpc | 64 | BNB-chain token supply read from a public RPC node. |
| 166 further sources | 1,274 | The long tail — each one a named public endpoint carried on every value it produces. |
Every value keeps its tier label all the way to your query, so an integration always knows whether a number came from the network itself or from an aggregator.
Most data vendors ask you to trust a dashboard. We do the opposite: each value hands you the upstream link it was read from, so you can confirm it without us in the loop.
verify_url proves a value is real at its source. The method is to take a batch, build a Merkle tree, and submit its root through OpenTimestamps — free, no token, no spend. Submission is not Bitcoin confirmation. The stages below describe the method, not current status.
symbol · metric · value · unit · source · verify_url · as_of
Each row is hashed into a Merkle leaf.
All leaves fold into one 32-byte root for the day.
The root is submitted to OpenTimestamps calendars; submission alone is not Bitcoin confirmation.
A verified Bitcoin timestamp is needed before claiming confirmation.
leaf = sha256( "symbol\tmetric\tvalue\tunit\tsource\tverify_url\tas_of" )
root = merkle( sort(all rows) ) // odd node duplicates last
stamp = ots stamp root // calendar submission; not Bitcoin confirmation1. pull the batch you were served.
2. sha256 each row, Merkle-root them.
3. confirm it equals the published root.
4. ots verify batch.root.ots // checks the root against BitcoinThese are often conflated, so to be exact about which question each one answers:
verify_url answers “is this what the upstream says?” — and it answers it now. An upstream URL is mutable; on its own it cannot establish what that upstream published at 14:03 UTC six months ago. We do not claim it can.
The ed25519 response receipt answers “what did Kairos actually serve me, and when?” Every /v1/ GET returns X-Kairos-Signature, X-Kairos-Timestamp and a link to the public key. That puts us on the record for our own bytes — it says nothing about the upstream.
A verified Bitcoin timestamp bounds when committed data existed; it is not automatically the batch's own date. Record-level verification also requires membership evidence.
Verification requires retained batch rows, a matching Merkle root and a verified OpenTimestamps proof. The /attestations/batch_<YYYYMMDD>.root file contains the root, not a row count. Recomputing a retained batch and running ots verify can check the commitment and its timestamp. A verified Bitcoin timestamp bounds existence by that time, which may be later than the batch date.
It does not prove that a source value is correct — that is what the per-value verify_url is for, upstream — and it says nothing about trading performance, returns, or signal accuracy. This is a data-integrity guarantee on a data product, not a track-record claim.
The historical record above is not a current confirmation report. Per-value inclusion queries use /v1/attest?symbol=&metric=&date=; a query can return an honest miss. An implemented query route does not establish that a particular row is retained, included or Bitcoin-confirmed. Historical verification requires the retained batch and separately verified timestamp evidence. With verified inclusion and timestamp evidence, the commitment is bounded by the verified confirmation time — it does not establish that an upstream measurement or any analytical conclusion is correct.
When a network has no free or first-party feed, we do not invent a number to fill the gap. We keep the network in the catalog and mark the gap, so you always know the difference between "we measured this" and "no public feed exists".
The catalog holds 731 rows (superseded rows and Bittensor subnet rows included) across compute, storage, sensor, wireless, AI, energy and mobility — the map of the territory, not just the covered part.
Each catalog entry records whether a public stats API exists and its URL. As of today 30 entries carry a public stats-API URL; the rest are cataloged with the gap shown, not hidden.
Provenance-or-silence. If we cannot read a value from a real source, the field stays empty and labelled — never back-filled with a guess.
The dataset is delivered through a structured API with the same provenance shape on every field — designed for AI agents, MCP clients, and analysts who need to cite their sources.
See the coverage and depth, or read how we verify a single number end to end.