The Token Layer of DePIN
DePIN has two data layers. The telemetry layer measures physical infrastructure — nodes, GPUs, storage. The on-chain layer measures the token: circulating supply, holders, transfers, gas, and contract activity. Both matter, and conflating them is how you end up thinking a falling token price means the network is failing.
On-chain data answers the supply question: how many tokens exist, who holds them, and how the chain is actually being used. At Kairos Signal we read this layer directly from RPC endpoints across 9 blockchains — no third-party indexer between the chain and our store.
The 9 Blockchains We Read Directly
Our RPC fleet covers the chains where DePIN tokens actually live:
- Ethereum RPC — 32 networks (ERC-20 token supply, holders)
- BSC RPC — 50 networks (BEP-20 supply)
- Solana RPC — 49 networks (Solana L1 + SPL tokens)
- Bittensor
subtensor_rpc— 129 networks (substrate storage, decoded directly) - Five more chains — via dedicated RPC paths for the remaining DePIN long tail
as_of timestamp is when we read the chain.
Supply: The Metric That Defines the Token Layer
Circulating supply is the on-chain metric investors lean on hardest, and it is surprisingly hard to get right. It is not simply "total minted." It requires knowing what is locked, burned, staked, and reserved. We normalize supply into canonical concepts so the number is comparable across networks.
For Solana networks, for example, supply spans both the L1 token and any SPL tokens a DePIN project issues — a two-denominator problem that trips up naive queries. For Bittensor, the 129-subnet picture requires decoding SCALE-encoded substrate storage from the public Finney endpoint, which we do directly.
Provenance on Chain Data
On-chain values carry the same provenance contract as telemetry:
source— the RPC path (ethereum_rpc,bsc_rpc,solana_rpc,subtensor_rpc)as_of— when we read the chain (not a finality proof, but our read time)verify_url— a public explorer link to confirmfreshness_verdict— fresh, stale, or missing
Query On-Chain Data
# Token supply for a network (read via the correct RPC path)
curl "https://api.kairossignal.com/v1/supply?network=filecoin"
On-chain market networks
curl "https://api.kairossignal.com/v1/networks?tier=onchain_market"
Verify a holder or transfer reading
curl "https://api.kairossignal.com/v1/verify/{value_id}"
Reading the Token Layer Correctly
There are three common traps in on-chain DePIN data, and each requires care:
as_of is when we read the chain, not a finality proof. For most analysis this is fine; for settlement-grade use you'd wait for finality.Where On-Chain Meets Telemetry
The most powerful queries combine both layers — token supply and network telemetry in one response. That is what turns on-chain data into DePIN intelligence: supply tells you the token economics, telemetry tells you whether the network is actually working. Reading both from first-party sources is the difference between a price feed and a network health check.
FAQ
Is token supply the same as network health? No. Supply describes the token economy; telemetry describes the network. A network can have stable supply and a collapsing node count, or a falling price and growing utilization. You need both layers to judge it. Why read RPC directly instead of using an indexer? Direct reads eliminate the indexer as a trust point, a latency source, and a single point of failure. Theas_of timestamp is when we read the chain — not when an indexer last synced.
How many blockchains do you cover? Nine, spanning the major DePIN token chains: Ethereum, BSC, Solana, Bittensor, and five more via dedicated RPC paths.
Read the docs → · Get a free key →
What On-Chain Data Does and Doesn't Tell You
On-chain data is the ground truth of the token layer — but it has a hard limit. It tells you supply, holders, transfers, and gas with certainty. It tells you almost nothing about whether the infrastructure is working. A network can have a healthy on-chain picture and a collapsing node count simultaneously.
That's why on-chain data is one half of the story, not the whole story. The other half is first-party telemetry: active nodes, deployed compute, real storage. The most useful analysis layers both — token supply and network telemetry in the same query — so you can see whether the token economy and the infrastructure are moving together or diverging.
Reading Supply Across a Network Family
Some DePIN projects issue multiple tokens or run tokens on multiple chains. Reading supply correctly means tracking each denominator and labeling it — the L1 token and SPL tokens on Solana, the root token and subnet tokens on Bittensor. A supply figure that silently sums incompatible denominators is worse than useless; it's misleading. We track and label each denominator so the number you get is the number you can defend.
The RPC Read Tradeoff
Direct RPC reads give you the freshest possible view, but they come with a caveat: as_of is when we read the chain, not a finality proof. For most analysis that is the right trade — you want the current state, not a settled-but-stale one. If you need settlement-grade certainty, you'd wait for finality. Our as_of is transparent about which one you're getting, and that transparency is the point.
Read more: DePIN RPC Endpoints · DePIN Telemetry · DePIN Network 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