The System, End to End
This is the technical manual for how DePIN intelligence is produced: from raw network APIs to a verified, queryable API. It covers the architecture, the schema, and the provenance model that make the data trustworthy.
Architecture
The system has four stages:
1. Collectors
A fleet of collectors pulls data across 69 sources. Each handles a different wire format:- RPC paths —
ethereum_rpc(32 networks),bsc_rpc(50),solana_rpc(49), Bittensorsubtensor_rpc(129, SCALE-encoded substrate storage) - Explorers —
evm_blockscout(118 networks) - Dev activity — GitHub (54 networks)
- Market — CoinGecko (288 networks)
- First-party APIs — 44 networks with dedicated stats endpoints
2. Normalization
Raw fields map into 38 canonical concepts with declared units. This is the schema layer:DEVICES_ACTIVE, GPU_ACTIVE, ACTIVE_NODES all normalize to the concept they describe, so cross-network comparison is meaningful.
3. Storage
Normalized rows land in ClickHouse (~697K rows, 10,706 live series). Columnar storage optimizes the dominant query pattern: time-range scans over specific metrics.4. Serving
The API exposes 19 live REST endpoints athttps://api.kairossignal.com, plus an MCP server for agents at https://kairossignal.com/mcp/.
Schema Design
The canonical schema is the heart of the system. By mapping ~89 native field names into 38 concepts, it enforces a same-question guarantee: a query for a concept returns comparable, unit-consistent values across every network that reports it.
Ambiguity is rejected, not shipped. A metric that can't be cleanly mapped to a canonical concept is dropped, because a bad canonical value poisons every downstream comparison.
The Provenance Model (Three Layers)
verify_url per value — a public URL pointing at the exact upstream source. Open it and confirm the number.Every value also carries source, as_of, and freshness_verdict (fresh, stale, or missing — never zero-filled).
Provenance on Every Response
{
"network": "akash",
"gpu_active": 3500,
"source": "first_party_api",
"as_of": "2026-08-25T12:00:01Z",
"verify_url": "https://...",
"freshness_verdict": "fresh"
}
Freshness Semantics
The freshness_verdict is a first-class schema field:
fresh— safe to use as current.stale— historical or uncertain.missing— excluded, never zero-filled.
Data Volume
- 327 networks with live data
- 296 first-party telemetry
- 78 on-chain market only
- 339 catalog only (of 800 cataloged)
- 10,706 live series
- 69 sources
- ~697K rows
A Worked Pipeline Trace
A value like gpu_active for Akash: the first_party_api collector reads Akash's console, the normalization layer maps the native field to the canonical GPU_ACTIVE concept, the row lands in ClickHouse with as_of, and the API serves it with a verify_url. At day's end the batch is hashed into a Merkle root and anchored to Bitcoin. Every stage is auditable — that's the point of the manual.
Verification Workflow
# Pull a value
curl "https://api.kairossignal.com/v1/networks/akash?fields=gpu_active" \
-H "Authorization: Bearer *"
Inspect its provenance
curl "https://api.kairossignal.com/v1/verify/{value_id}"
Open the verify_url to confirm at the source; the Merkle root and Bitcoin timestamp prove the batch's integrity and time.
FAQ
What is the same-question guarantee? A query for a canonical concept returns comparable, unit-consistent values across every network that reports it — no schema archaeology. Why is ambiguity rejected? A bad canonical value poisons every downstream comparison. We'd rather drop a metric than ship a wrong one. How is integrity enforced? Daily batches are Merkle-rooted and anchored to Bitcoin via OpenTimestamps, so any historical value is cryptographically provable. Full API reference → · Get a free key →The Collector Contract
Every collector in the fleet obeys the same contract regardless of wire format: pull the raw value, timestamp it with as_of, map its field into a canonical concept, and write the row to ClickHouse with its source. That uniform contract is what makes 69 wildly different sources composable into one queryable API. A collector that can't produce a canonical, timestamped, source-annotated row doesn't ship — because a value that can't be traced is a value that can't be trusted.
The Testing Philosophy
The pipeline is only as trustworthy as its tests. Normalization is enforced by a suite that verifies every network's fields map to the right canonical concept with the right unit — and refuses a mapping that's ambiguous rather than guessing. This is the practical meaning of "provenance or silence": a wrong or ambiguous value is dropped, not shipped. The same standard applies to the provenance layer — a batch that can't be Merkle-rooted and Bitcoin-anchored is a batch that isn't released.
Read more: DePIN Data Documentation · Merkle Root Data Integrity · DePIN Data Provenance
---
This is a data product. Kairos Signal publishes no trading signals, performance returns, win rates, or accuracy claims.---
Try it yourself
Query the live catalog, supply telemetry, and provenance receipts directly: /v1/supply, /v1/provenance on the REST API.
Related reading: DePIN Intelligence guide · DePIN network data: 327 networks, 69 sources · how we read supply telemetry from 296 networks · the DePIN developer guide
17 of 20 design-partner seats remain at a lifetime-locked $199/mo (full API access, all 19 endpoints, MCP server, Bitcoin-anchored provenance). After seat 20 the price becomes $249/mo. Claim a design-partner seat → · See pricing---
Get Started With DePIN Intelligence
Kairos Signal provides verifiable, provenance-first telemetry for 327 DePIN networks — 296 with first-party supply data read directly from each network's own API or blockchain. Every value carries a verify_url you can check yourself, and each daily batch is Merkle-rooted and anchored to Bitcoin.
Every API response is signed with ed25519 and timestamped. You can prove what was served and when, months later. That is what we mean by provenance-first.
Related reading: DePIN Intelligence Guide · DePIN Telemetry · How to Query DePIN Data · DePIN Data Verification · Pricing