How we verify every DePIN number: verify_url on every value + a daily Bitcoin anchor

Most data vendors ask you to trust a dashboard. A number appears, and you take it on faith. For a DePIN dataset that AI agents are supposed to act on autonomously, that is not good enough. So we built the opposite: a dataset that is irresistible because it is checkable, not despite it.

Two mechanisms carry the whole promise. The first proves each value is real at its source. The second proves we did not quietly change it afterwards.

Mechanism one: a verify_url on every value

The unit of our dataset is not a number — it is a number with its paperwork attached. Every value we serve has 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"
}

That is a real row from today's batch. The interesting field is verify_url. It does not point back at us — it points upstream, to the exact source the value was read from. Open it and compare.

We do not pretend everything is first-party, and the label tells you which is which:

• The largest tier, 595 live series, is read straight from the network's own API or chain. For these, the verify_url points at the network itself — a provider endpoint, a station API, a block explorer. The number originated where the link goes.
• 58 series are market facts from CoinGecko: price, market cap, circulating and total supply.
• 51 series are protocol TVL, fees and revenue from DefiLlama.
• The rest are named, tier-labelled feeds: GitHub developer activity, Akash provider and lease telemetry, WeatherXM station telemetry, Flux node telemetry.

The as_of timestamp pins each value to the moment it was true, so a check is a like-for-like comparison — and staleness is surfaced, never buried.

Mechanism two: a daily Bitcoin anchor

A verify_url shows a value is real at its source. It does not, on its own, stop us from editing our copy later. That is what the Bitcoin anchor is for.

Once a day we take the entire batch of provenance-stamped values, hash each row into a Merkle leaf, and fold the whole tree down to a single 32-byte root. Then we timestamp that root to Bitcoin through OpenTimestamps — which is free, uses no token, and requires no spend.

leaf  = sha256("symbol\tmetric\tvalue\tunit\tsource\tverify_url\tas_of")
root  = merkle(sort(all rows))
stamp = ots stamp root   // submitted to 4 independent calendars

Today's batch, dated 2026-08-09, rooted 1,369 values across 228 networks into this root:

9cd92fde048419f2187e38d82c46797d19e8dd3909791a370a1646b6987318b7

That root was committed to four independent OpenTimestamps calendars and is currently pending Bitcoin confirmation. The calendars batch submissions and commit to a Bitcoin transaction on their cycle; once that transaction is mined, ots upgrade completes the proof and ots verify checks the root against the chain.

Anyone can verify the day, with zero trust in us:

Pull the batch you were served.

SHA-256 each row and Merkle-root them.

Confirm it equals the published root.

Run ots verify on the proof file — it checks the root against the Bitcoin blockchain.

What this proves — and what it does not

Being precise here is the point of the whole exercise.

• It proves integrity and point-in-time. That this exact set of 1,369 values existed on 2026-08-09 and has not been altered since.
• It does not prove a source value is correct. That is what the per-value verify_url is for, upstream.
• It says nothing about trading performance, returns, or accuracy. This is a data-integrity guarantee on a data product — not a track record, not a signal claim, and we make no such claim anywhere.

The gaps are labelled too

Provenance-or-silence cuts both ways. When a network has no free or first-party feed, we do not invent a number to fill the hole. We keep the network in the catalog — 385 network entries cataloged so far — and mark the gap. Each catalog entry records whether a public stats API exists and its URL; where none does, the entry is present with the gap shown rather than back-filled with a guess.

Access

The dataset and the Bitcoin anchor are real and running today. The public, self-serve query endpoint and a per-value inclusion-proof endpoint are being brought online; API access is granted on approval in the meantime.

Read the full methodology on the Provenance page, or see coverage and depth across the DePIN data product.