The DePIN Data Problem
Every AI-compute DePIN advertises a GPU count. io.net says it has tens of thousands of GPUs for AI workloads. But the number most people quote is registered capacity — the GPUs the network believes exist. What actually matters is how many are active and how many are busy. Those are three different numbers, and conflating them is how bad GPU supply data gets born.
At Kairos Signal, we measure the gap between registered and active supply directly from first-party telemetry. It's the single most important number on any compute DePIN, and almost no dashboard publishes it.
Registered vs. Active: The Real GPU Supply
The pattern repeats across the AI-compute sector. Registered device count grows while active count stays flat — a widening pool of idle inventory that looks like growth if you only read the top-line number.
- Registered supply is the headline the network markets.
- Active supply is the GPUs actually connected and working.
- Busy supply is the subset of active GPUs currently running a job.
The Utilization Trap
This is where most GPU supply analysis goes wrong. A reported utilization of 96%+ is almost always a fill rate of the active pool — it can barely be anything but high. The number that actually tells you whether the network is absorbing supply is registered-supply utilization, and that's the number that requires good supply data to compute.
Why the Gap Matters
The registered-vs-active gap is the single most informative number on a compute DePIN, and it changes decisions:
- For an AI/ML team choosing where to run training jobs, registered supply overstates availability. If you provision based on registered GPUs, you will hit availability walls when the active pool turns out to be a fraction of the headline.
- For an investor assessing a GPU network, a widening registered-vs-active gap signals a network adding hardware faster than it adds demand — a supply glut that will pressure prices regardless of the token narrative.
- For an agent that auto-provisions across networks, distinguishing registered from active is the difference between a job that runs and a job that queues forever.
devices_registered, devices_active, and devices_busy, you get the full funnel in one response instead of a single marketing number.
The Fill Rate vs. Utilization Distinction
A common mistake is to treat "fill rate" and "utilization" as the same thing. They are not:
- Fill rate = busy ÷ active. It measures how much of the working pool is occupied. Because the active pool is definitionally working, this is always high — a 96% "utilization" headline is usually this metric.
- True utilization = busy ÷ registered. It measures how much of everything the network claims is actually generating revenue. This is the number that reflects whether the network is absorbing its supply.
Query io.net GPU Supply Yourself
# io.net supply + market data
curl "https://kairossignal.com/v1/networks/io.net" \
-H "X-API-Key: $KS_API_KEY"
The utilization-relevant fields
curl "https://kairossignal.com/v1/networks/io.net?fields=devices_registered,devices_active,gpu_utilization"
Compare GPU utilization methodology across io.net, Akash, and Render
curl "https://kairossignal.com/v1/compare?concept=GPU_UTILIZATION&networks=io.net,akash,render"
Each field carries a verify_url pointing at io.net's own API, so you can confirm the registered and active counts against the source — and see whether "utilization" in the response means fill rate or true registered-supply utilization.
Why Provenance Wins
Because our daily batch is Merkle-rooted and timestamped to Bitcoin via OpenTimestamps, the registered/active gap you read today is provably the gap that existed today. When io.net restates a device count, both the original and revised values stay in the archive with their timestamps — so an agent backtesting on GPU supply never fits on silently-restated data.
A GPU count without a registered/active split is marketing. Ask for the supply data underneath. Get a free API key →---
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: io.net GPU data · io.net registered vs active devices · compute supply across Akash, io.net, Aethir · how we read supply telemetry from 296 networks
Design-partner seats are capped at 20 at a lifetime-locked $199/mo (full API access, every published endpoint, 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 DePIN networks, including first-party supply data read directly from a 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