Direct Chain Access, No Middleman
A large share of DePIN data lives on-chain, and the most trustworthy way to read it is directly from RPC endpoints — no third-party indexer or aggregator between the chain and your store. That is the architectural choice behind our on-chain layer: direct RPC reads across 9 blockchains.
Direct access means our as_of timestamp is when we read the chain. It means no external indexer can lag, fail, or distort the data. It means the verify_url on every value points at the chain itself.
The 9-Blockchain RPC Fleet
Our RPC paths cover the chains where DePIN tokens actually live:
| RPC path | Networks | What it provides |
|---|---|---|
| Bittensor subtensor_rpc | 129 | Subnet telemetry, validators, TAO emission |
| evm_blockscout | 118 | Holders, transfers, gas (EVM explorer API) |
| bsc_rpc | 50 | BSC token supply |
| solana_rpc | 49 | Solana L1 + SPL tokens |
| ethereum_rpc | 32 | Ethereum token supply |
| 4 more paths | ~60 | Remaining DePIN chain long tail |
Reading across 9 chains means handling 9 different wire formats — JSON-RPC for EVM chains, JSON for Solana, SCALE-encoded substrate storage for Bittensor. Each needs its own collector and decoder, which is precisely the kind of plumbing that makes first-party on-chain data a moat.
Why Direct Reads Beat Indexers
A third-party indexer in the path adds three costs:
Direct RPC reads eliminate all three. The as_of is when we read the chain; the verify_url points at the chain; and there is no single third-party point of failure.
The Two-Denominator Chains
Some chains need special care. Solana networks often have both an L1 token and SPL tokens, so supply is a two-denominator problem. Bittensor requires decoding SCALE substrate storage from the public Finney endpoint to get at SUBNET_* metrics. Getting these right is what separates real on-chain data from a naive supply query.
Query On-Chain Data
# Token supply, read via the correct RPC path
curl "https://api.kairossignal.com/v1/supply?network=filecoin" \
-H "Authorization: Bearer *"
Networks served by a specific RPC path
curl "https://api.kairossignal.com/v1/networks?source=solana_rpc"
Verify a holder or supply reading against the chain
curl "https://api.kairossignal.com/v1/verify/{value_id}"
Every response carries source (the RPC path), as_of, verify_url, and a freshness verdict.
Provenance on Chain Data
On-chain values carry the full provenance contract. Daily batches are Merkle-rooted and timestamped to Bitcoin via OpenTimestamps, so a historical supply or holder reading is provably the value that was true that day. You can independently verify any number against the chain explorer linked in its verify_url.
On-Chain + Telemetry
The RPC layer is half the story; first-party network telemetry is the other half. Combined, they give you both the token economics (supply, holders, gas) and the infrastructure health (nodes, compute, storage) — the complete DePIN picture.
FAQ
Why read RPC directly instead of using an indexer? Direct reads remove the indexer as a trust point, latency source, and failure point. Theas_of is when we read the chain.
How many blockchains do you cover? Nine, spanning the major DePIN token chains via dedicated RPC paths.
What's the hardest chain to decode? Bittensor — its SCALE-encoded substrate storage requires a real substrate client on the Finney endpoint, not a simple JSON call.
Explore the API → · Try it live →
The Wire-Format Diversity Problem
Reading nine blockchains means handling nine incompatible wire formats. EVM chains speak JSON-RPC. Solana has its own JSON conventions. Bittensor speaks SCALE-encoded substrate storage, which requires a real substrate client rather than a simple HTTP call. Each format needs a dedicated collector and decoder, and each decoder must be maintained as its chain evolves.
That diversity is exactly why direct, multi-chain RPC access is a moat. It's not a thin integration; it's a fleet of specialized decoders that have to be kept correct across every chain. Teams that rely on a single indexer avoid this work — but they also inherit the indexer's limitations as a trust point, latency source, and failure mode.
The Indexer Trade-Off
Using a third-party indexer is cheaper and easier, and it's the right call for many use cases. But it means your data is only as current as the indexer's last sync, only as correct as the indexer's parser, and only as available as the indexer's uptime. Direct RPC reads trade that convenience for three guarantees: freshness (we read when we say we did), correctness (we decode the chain ourselves), and availability (no single third-party point of failure). For infrastructure telemetry that feeds decisions, those guarantees are worth the engineering.
Read more: DePIN On-Chain Data · Bittensor Subnet Data · DePIN Data Provenance
---
This is a data product. Kairos Signal publishes no trading signals, performance returns, win rates, or accuracy claims.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