io.net API: GPU Workers, Compute Supply & Network Health
What the Metrics Tell You
The set of io.net metrics — registered devices, active devices, GPU worker counts by type, and protocol revenue — form a coherent picture when read together:
- Registered vs. active reveals how much of the advertised fleet is actually working. A wide gap is idle inventory; a narrow gap is a tight, functioning market.
- GPU worker counts by type shows the hardware mix, which determines what workloads the network can actually serve.
- Protocol revenue is the closest thing io.net has to a demand signal — real fees collected, not token inflation.
A Usage Scenario
Suppose you are building a tool that routes GPU jobs across compute networks. The naive implementation reads "registered GPUs" and picks the largest advertised fleet. That will consistently misallocate — the fleet with the most registered GPUs may have the lowest active ratio, so your jobs queue behind a wall of idle-but-unreachable hardware.
With canonical, first-party supply data, the same tool reads devices_registered, devices_active, and devices_busy for each candidate network, computes true availability, and routes jobs where compute is actually working. This is a concrete, quantifiable improvement to any GPU scheduling or capacity-planning tool, and it depends entirely on data quality — registered counts alone cannot produce it.
io.net (IO) is the largest decentralized GPU compute network. Tracking its supply-side metrics — worker counts, GPU types, geographic distribution — is essential for anyone building DePIN analytics or compute pricing models.
What We Track for io.net
- Registered devices — from io.net's own API
- Active devices — from io.net's own API
- GPU worker counts by type — from io.net's stats endpoint
- Protocol revenue — from DefiLlama
- Price & market cap — from CoinGecko
Why Worker Counts Are Not Compute Supply
The headline metric on io.net is "registered devices," but that is not the same as compute supply. The full funnel matters:
- Registered devices — everything io.net believes exists.
- Active devices — devices reporting a heartbeat right now.
- Busy devices — the subset currently running a job.
What We Track for io.net
- Registered devices — from io.net's own API
- Active devices — from io.net's own API
- GPU worker counts by type — from io.net's stats endpoint
- Protocol revenue — from DefiLlama
- Price & market cap — from CoinGecko
The Utilization Trap
A reported utilization above 90% on a compute network is almost always a fill rate — busy divided by active. Because the active pool is definitionally working, this metric can barely be anything but high. The number that actually tells you whether the network is absorbing supply is busy divided by registered — and that is the number that requires trustworthy supply data to compute.
We expose both fill_rate and registered_utilization as distinct concepts, so your tooling never confuses the two. Every value carries a verify_url to io.net's own API, and every daily batch is Merkle-rooted to Bitcoin.
Query io.net Data
# Get all io.net metrics with provenance
curl "https://api.kairossignal.com/v1/networks/io.net" \
-H "X-API-Key: YOUR_KEY"
Cross-network supply comparison
curl "https://api.kairossignal.com/v1/supply?network=io.net" \
-H "X-API-Key: YOUR_KEY"
Every value carries source, as_of, age_hours, freshness, and verify_yourself.
Free API Key — $5 Credits
curl -X POST https://kairossignal.com/v1/credits/register \
-H "Content-Type: application/json" \
-d '{"email":"[email protected]"}'
---
Try it yourself
Query the live catalog, supply telemetry, and provenance receipts directly: /v1/networks, /v1/provenance on the REST API.
Related reading: io.net GPU data · io net gpu supply data how many gpus are actually online · io.net registered vs active devices · compute supply across Akash, io.net, Aethir
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