A Feed Is a Pipeline, Not an Endpoint
When people say "data feed" they usually mean a single JSON response. In practice a production DePIN data feed is the entire chain: upstream collectors, normalization, storage, and a serving API. If any link is unverifiable, the whole feed is suspect.
Here is what the pipeline looks like end to end.
Stage 1: Collection
Data has to come from somewhere real. We run a fleet of collectors across 69 distinct sources. Each is responsible for pulling raw values on its own cadence:
- RPC paths —
ethereum_rpc(32 networks),bsc_rpc(50),solana_rpc(49), Bittensorsubtensor_rpc(129) - Explorers —
evm_blockscout(118 networks: holders, transfers, gas) - Dev activity — GitHub (54 networks)
- Market — CoinGecko (288 networks)
- First-party APIs — 44 networks with dedicated stats endpoints
Stage 2: Normalization
Every network names its fields differently. DEVICES_ACTIVE, GPU_ACTIVE, ACTIVE_NODES, WORKERS_ONLINE all mean the same thing at different networks. We map 89 native field names into 38 canonical concepts, each with a declared unit. This is what makes cross-network comparison possible — you query GPU_ACTIVE and get a comparable number back from Akash, io.net, and Render.
Normalization also means refusing garbage. An ambiguous or wrong metric is dropped, not shipped, because a bad canonical value poisons every downstream comparison.
Stage 3: Storage
Normalized rows land in ClickHouse, our analytics store. The current store holds roughly 697K rows spanning 10,706 live series. Columnar storage matters because most DePIN queries are time-range scans over specific metrics — exactly what ClickHouse optimizes for.
The series count grows as coverage expands; the architecture is designed so adding a network is a config change, not a rewrite.
Stage 4: Serving
The feed is served through 19 live REST endpoints at https://api.kairossignal.com. Each response carries the provenance contract:
source— where the value came fromas_of— when it was readverify_url— a public URL to confirm itfreshness_verdict— fresh, stale, or missing
# Pull the latest live series
curl "https://api.kairossignal.com/v1/networks" \
-H "Authorization: Bearer *"
Supply trend for a network
curl "https://api.kairossignal.com/v1/supply?network=filecoin&window=90d"
A single verified value
curl "https://api.kairossignal.com/v1/verify/{value_id}"
Provenance Keeps the Feed Honest
A real-time feed that cannot prove its history is not a feed — it is a snapshot someone is asking you to trust. Each daily batch of hundreds of values is hashed into a single Merkle root and anchored to Bitcoin via OpenTimestamps. That gives you tamper evidence without trusting the provider.
The result is a feed you can build a backtest on, an alerting system on, or an autonomous agent on — and verify every number independently.
Freshness: The Design Choice Most Feeds Get Wrong
The biggest silent failure in data feeds is the zero-fill. When a value is missing, many feeds return 0 — which is catastrophic for downstream analytics, because zero looks like a real reading. Our feeds never zero-fill. Missing values carry a freshness_verdict of missing, so your pipeline can distinguish "the number is zero" from "we don't have the number." That single design choice prevents a whole class of data-corruption bugs.
Build or Buy?
You can build this pipeline yourself, but the temporal history is the killer. A day of data not collected cannot be bought later. Starting your own ingestion today means your trend window starts today. Buying a feed with years of banked history starts you at day one of a mature series.
FAQ
What's the difference between a live series and a snapshot? A live series is a time-indexed sequence of values you can trend and backtest. A snapshot is a single point in time. Feeds with history — like our 10,706 series — enable trend analysis; snapshots don't. Why is a zero-fill so dangerous? Because zero is a real number. If a feed returns 0 for a missing node count, downstream analytics treats it as "the network has zero nodes," which is false and corrupting. We return amissing verdict instead.
Can agents consume the feed? Yes, via the MCP server at https://kairossignal.com/mcp/ or the REST API, with full provenance on every value.
Get the feed via API → · See the schema →
The Freshness Problem Nobody Wants to Talk About
Every data feed has a freshness story, and most are quietly bad. Some feeds serve cached values for days. Others silently drop a network when its source breaks. The worst ones zero-fill missing data, which makes the pipeline look healthy while it is being silently corrupted.
Three practices keep a feed honest:
- An
as_oftimestamp on every value. You always know exactly when the number was read, so you can judge freshness yourself. - A
freshness_verdicton every value. The feed tells you whether a value is fresh, stale, or missing — so your code never has to guess. - No zero-fills, ever. A missing value is labeled
missing, not returned as0. Zero is a real number; a fabricated zero is a lie your model will learn.
Adding a Network Is Configuration, Not Engineering
A well-architected feed treats each network as a configurable source rather than a one-off integration. Adding a new network means declaring its source, its field mapping, and its cadence — not writing a new pipeline. That is why the catalog can grow to 327 live networks while the architecture stays manageable. For a consumer of the feed, it means the coverage keeps expanding without destabilizing the endpoints you already rely on.
Real-Time vs Fresh
"Real-time" is often used loosely. What matters is that every value tells you when it was read. A five-minute-old value on a fast-moving metric may be exactly what you need; a five-minute-old value on a daily-cadence metric may be the freshest that exists. The as_of timestamp lets you decide, rather than a vendor's marketing claim.
Read more: DePIN Analytics: Raw Chain Data to Decisions · DePIN On-Chain Data · How to Query DePIN Data
---
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/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