DePIN capacity vs demand — brief for 2026-10-21

Generated 2026-10-21T08:00:01Z. Every number is measured, carries its source and as-of time, and can be re-derived from the live API. Windows are stated; nothing is interpolated or forecast.

MarkdownJSONLive API (free, no key)

The Allocator's Ledger — capacity vs demand, and active-device share

For utilisation rows: is this network adding capacity faster than recorded use absorbs it? For active-device share rows (resource: devices): are total devices growing faster than active devices? That share measures neither use nor demand.

Divergence is denominator growth minus numerator growth. For utilisation rows the denominator is capacity and the numerator is recorded use; this does not establish paid demand, revenue, or a capacity bottleneck. Active-device share rows (resource: devices) divide active devices by total devices; 'active' means connected, hired or idle, not in use, so that share is not utilisation and not demand. Each row states its own window. Undefined growth is n/a. One window per row, not a forecast.

Pairs we can compute and refuse to publish

A refusal you cannot audit is just a different kind of marketing, so each reason is published in full.

IO gpus

io.net's GPU_TOTAL is NOT registered GPU supply — on every archived day when this refusal was recorded it equalled DEVICES_ACTIVE exactly, and GPU_HIRED + GPU_IDLE equals GPU_TOTAL exactly. So hired/total is a FILL RATE on the already-active pool, near-tautological, and it excludes every passive (registered but not connected) device. io.net's 'active' means connected through its worker, hired or idle, not in use. Publishing that fill rate beside other networks' utilisation of REGISTERED capacity would compare different quantities. The share of registered devices that are active is reported separately as the IO devices pair — an active-device share (active devices divided by total devices), computed from data for its own window rather than typed here.

NOS devices

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.

SC devices

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.

STORJ storage_bytes

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.

Unchanged observations — cause unverified

Exactly one distinct stored value across >=20 observations spanning >=5 days, while other metrics on the same network change. Counts are stored observations, not independently verified poll attempts. Metric-name hints rank candidates; they do not establish expected cadence. Constant values and single upstream rechecks do not prove a stopped feed. No statistical failure probability is claimed.

• CFG dex_venues_active — unchanged at 1 for 10d across 40 stored observations, while 7 other metric(s) on CFG kept moving
• HEU dex_gt_pairs_active — unchanged at 4 for 10d across 40 stored observations, while 4 other metric(s) on HEU kept moving
• CESS dex_gt_venues_active — unchanged at 5 for 10d across 40 stored observations, while 8 other metric(s) on CESS kept moving
• VDO dex_gt_venues_active — unchanged at 2 for 10d across 40 stored observations, while 6 other metric(s) on VDO kept moving
• XL1 dex_gt_venues_active — unchanged at 2 for 10d across 40 stored observations, while 5 other metric(s) on XL1 kept moving
• XPIN dex_gt_pairs_active — unchanged at 20 for 10d across 40 stored observations, while 6 other metric(s) on XPIN kept moving
• SUIDEPIN dex_pairs_active — unchanged at 1 for 10d across 38 stored observations, while 15 other metric(s) on SUIDEPIN kept moving
• NOS jobs_completed_market_nvidia_3060_community — unchanged at 56502 for 10d across 237 stored observations, while 39 other metric(s) on NOS kept moving
• ONO dex_gt_pairs_active — unchanged at 9 for 10d across 40 stored observations, while 23 other metric(s) on ONO kept moving
• SXCH dex_gt_venues_active — unchanged at 3 for 10d across 40 stored observations, while 5 other metric(s) on SXCH kept moving
• DBT dex_gt_venues_active — unchanged at 2 for 10d across 40 stored observations, while 8 other metric(s) on DBT kept moving
• IO devices_l40s_active — unchanged at 8 for 10d across 240 stored observations, while 55 other metric(s) on IO kept moving

Supply verifiability — what we confirm on-chain ourselves

149 of 221 networks reconcile to within 1% — those figures are independently confirmed, not taken on trust. Of the other 72, 54 are more than 10% off; the 15 with the lowest ratios are listed with the exact contract we read so you can check in one click.

Verify any of this yourself

This brief is machine-readable and free — no key, no signup:

curl https://kairossignal.com/v1/brief

Every row ships source, as_of and a verify URL pointing at the origin rather than at us. If you can refute a number here, we would rather publish the correction than the number.