DePIN capacity utilisation

Why this and not node counts. Node count is the number most DePIN dashboards lead with, and it is the easiest to grow without demand. The question that separates infrastructure from subsidy is what fraction of that deployed capacity is doing paid work — capacity growing faster than utilisation is overcapacity, not growth. Every figure below is computed from the network’s own public endpoint, and every row links to it.

What “pending” is. Workload that has been ordered on Akash but not yet placed on a provider — demand sitting in the queue, from the network’s own console API. Read it next to the utilisation table above: rising utilisation with a rising pending queue is demand arriving faster than deployed capacity is absorbing it. CPU is shown in cores (Akash reports millicpu; divided by 1,000). Each trend point is that day’s last observation; days with no observation are absent, never carried forward or interpolated. No predictive claim is made.

These are not utilisation. They answer “what fraction of registered nodes are switched on?”, which is fleet health, not busy hardware. We separate them because publishing both in one table invites a false reading: a network showing 99% liveness is not “better utilised” than one showing 27% CPU utilisation — the two numbers answer different questions. Where a network’s denominator is cumulative registrations rather than a live fleet, that is flagged inline.

Refused: IO gpus utilisation.
io.net's GPU_TOTAL is NOT registered GPU supply — it equals DEVICES_ACTIVE exactly on every archived day (1,213/1,213 ... 1,199/1,199), and GPU_HIRED + GPU_IDLE == GPU_TOTAL exactly. So hired/total is a FILL RATE on the already-active pool, near-tautological, and it excludes every passive device. It reads 96.7% while the share of registered devices that are active (active/registered) is 46.2% and FALLING — io.net's 'active' means connected through its worker, hired or idle, not in use (2026-09-25: the worker list matches active exactly, 1,275, of which 1,260 hired) — registered devices grew 2,057 -> 2,594 (+26%) in 7 days while active stayed flat near 1,200. Publishing 96.7% beside Akash's 30.5% (utilisation of REGISTERED capacity) would invert the actual story: io.net is the network accumulating idle supply fastest, not the one running hottest.

Refused: NOS devices utilisation.
NOSANA HAS NO PUBLISHABLE DENOMINATOR (probed 2026-08-24, recorded so the next agent does not re-probe it). The numerator is free and clean — dashboard.k8s.prd.nos.ci/api/jobs?state=RUNNING reports totalJobs=947 running jobs and each Nosana job occupies exactly one node. The denominator is not: /api/nodes and /api/nodes/stats require an authorization header (401 with one, 422 without), and no unauthenticated sibling exposes a node count. Two tempting substitutes were REFUSED. (1) running + queued NODES from /api/markets: that per-market queue holds only IDLE nodes and is 0 across all 47 markets while 43 jobs sit QUEUED, so the denominator would equal the numerator by construction and publish a tautological 100%. (2) per-market access-SFT supply on Solana (231 for the nvidia-3070 market): a node joining three markets holds three SFTs and nothing burns them when it leaves, so the sum counts memberships and departed nodes, not live nodes. The numerator is collected anyway (collectors_clean/nosana_utilisation.py writes NOS JOBS_RUNNING/JOBS_QUEUED/MARKET_IDLE_NODES) so the pair can complete the day Nosana publishes a node count; no ratio until then.

Refused: SC devices utilisation.
SIACOIN'S DENOMINATOR IS CUMULATIVE, NOT LIVE (measured 2026-08-24). Both halves flow — SC_ACTIVE_HOSTS ~530, SC_TOTAL_HOSTS ~87,048 — so the pair LOOKS complete and would auto-publish a 0.6% utilisation figure. It is not a utilisation figure: TOTAL_HOSTS counts every host ever announced to the Sia network and is monotonically non-decreasing across all 19 archived days (87,032.7 → 87,048.0, never once falling), while ACTIVE_HOSTS moves both ways in the 514-556 band. A denominator that can only grow makes the ratio a function of the network's AGE, so it would fall forever regardless of how the network performs — the Storj denominator trap in a new costume. The numerator is honest and stays queryable; no ratio until Sia publishes a currently-announced host count.

Refused: STORJ storage_bytes utilisation.
STORJ PUBLISHES NO CAPACITY DENOMINATOR (measured 2026-08-24). Everything public is the numerator: stats.storjshare.io/data.json gives bytes stored by customers (53.4 PB) and the node-side footprint after erasure coding (92.2 PB, 1.73x), and the per-satellite node counts are memberships, not capacity — a node serving three satellites is counted three times, which is the same double-count that already inflated STORJ node totals. Nothing upstream states how many bytes the network could hold, so any utilisation ratio would need a denominator we invented. The numerator stays collected and is now correctly labelled storage_bytes_in_use rather than storage_bytes_total, which is what it had been resolving to.

Scope, stated plainly. This covers the 6 networks where we hold both sides of the ratio from a first-party endpoint — not all 171 networks we track. Utilisation is undefined without a published capacity denominator, and most networks do not publish one. We are adding them as we verify them; the count above is the honest current number, and we would rather show 6 real rows than 171 modelled ones.

Ratios we refused to publish: one network reports storage-used exceeding storage-total by 64x, and another reports a lifetime-cumulative denominator that would yield a meaningless 0.1%. Both are excluded until the upstream fields are understood.

curl "https://kairossignal.com/v1/network/AKT"    # every metric, with source and as_of
curl "https://kairossignal.com/v1/supply"        # free 12-network sample
curl "https://kairossignal.com/v1/history?network=AKT&metric=CPU_PENDING&days=14"   # the pending-queue series above