One URL, Four Node Counts
On 2026-08-24 at 14:23 UTC we fetched https://stats.storjshare.io/nodes.json — Storj's own public per-satellite stats endpoint. For the us1 satellite it reported, in the same JSON object, in the same second:
total_nodes: 123,580active_nodes: 32,796vetted_nodes: 40,039disqualified_nodes: 80,615exited_nodes: 7,696
The Gap Is Archaeology, Not Churn
The 90,784-node gap between total and active is not nodes that might come back. It is dead history that the ledger never forgets:
- 80,615 disqualified — nodes that failed audits and were permanently removed
- 7,696 exited — nodes that completed graceful exit and left
total_nodes on us1 are permanently gone, and will stay in the "total" forever, because total_nodes is a cumulative ever-registered count. It only goes up. Quoting it as fleet size is like counting every phone number ever issued as active subscribers.
(The remaining slice between active and total is offline, suspended, and unvetted nodes — states that can transition, unlike the 88,311.)
Ratio 1: Active / Total = 26.5%
32,796 / 123,580 = 26.5%. This is the honest answer to "of every node that ever registered on us1, what share is alive today?" It looks damning — three quarters of the network gone! — and it is the number a short-thesis writeup would quote.
Ratio 2: Active / Vetted = 81.9%
32,796 / 40,039 = 81.9%. Vetted nodes are the ones that passed Storj's audit gauntlet and were admitted to hold real data. Of those, 82% are active right now. This is the honest answer to "is the operational network healthy?" — and the answer is yes. The total_nodes figure is an archaeology count; the vetted denominator measures the working fleet.
Same numerator. Two denominators. 26.5% vs 81.9%. A 3x swing in the story, from one JSON object, with zero disagreement about the underlying facts.
All Four Satellites Agree on the Shape
Fetched in the same request, same second (2026-08-24T14:23Z, re-verified at publish time):
| Satellite | Active | Total | Active/Total | Active/Vetted | |---|---|---|---|---| | us1 | 32,796 | 123,580 | 26.5% | 81.9% | | eu1 | 29,474 | 115,355 | 25.6% | 80.7% | | ap1 | 29,373 | 115,717 | 25.4% | 79.3% | | saltlake | 27,234 | 112,641 | 24.2% | 81.8% |
The consistency matters: this is not a us1 quirk or a snapshot artifact. It is the structural signature of a network with several years of accumulated churn in a monotonic ledger.
The Third Trap: Never Sum the Satellites
Here is the trap that actually bites aggregators. Adding the four active_nodes figures gives 118,877 "active nodes." That number is roughly 4x wrong, because a single Storj node serves all four satellites simultaneously — the same physical machine appears in all four rows. The per-satellite counts are four views of (mostly) one fleet, not four fleets.
Any dashboard showing a "Storj network total" built by summing this endpoint is overstating the fleet ~4x. We have seen this exact failure class across DePIN: the raw data is public and correct, and the aggregation step silently changes what is being counted.
Why We Care
Kairos tracks first-party supply telemetry across 327 live networks (10,706 live series, as of 2026-08-24), and Storj is the cleanest teaching example of a pattern we hit constantly: the numerator is easy; the denominator is the product. "Node count" is not a metric until you specify ever-registered vs vetted vs active-now, and per-satellite vs deduplicated. Our pipeline stores which denominator each series uses and the URL it came from, so a number can always be traced back to a definition.
The honest caveats cut both ways, as always: active_nodes is the satellite's own liveness definition, not ours; we cannot independently observe nodes that never talk to a satellite; and a snapshot says nothing about trend — the same total/active ratio can come from a growing network with old scar tissue or a shrinking one. (This is the same discipline we apply elsewhere: military aircraft counts are transponder-visible-only; crowd-sourced receiver networks have receiver-density bias. State the denominator, state the blind spot.)
Verify It Yourself
No API key needed — this is Storj's public endpoint:
curl -s https://stats.storjshare.io/nodes.json | python3 -m json.tool
Recompute the ratios for us1:
curl -s https://stats.storjshare.io/nodes.json | python3 -c "
import json,sys
d = json.load(sys.stdin)
us1 = [v for k,v in d.items() if 'us1' in k][0]
print('active/total :', us1['active_nodes']/us1['total_nodes'])
print('active/vetted:', us1['active_nodes']/us1['vetted_nodes'])
print('dead share :', (us1['disqualified_nodes']+us1['exited_nodes'])/us1['total_nodes'])
"
Your numbers will drift slightly from ours as nodes churn; the shape will not.
To pull Storj alongside the rest of the estate via our API (each value carries its source URL and timestamp):
curl https://kairossignal.com/v1/network/STORJ -H "X-API-Key: YOUR_KEY"
Related reading: Filecoin API: storage providers and network power · WeatherXM to Akash: comparing supply telemetry across categories
Docs: API reference · Try it free · Pricing
---
Data access: free tier at kairossignal.com/try, or the $199 Design Partner tier at kairossignal.com/pricing.
---
Try it yourself
Query the live catalog, supply telemetry, and provenance receipts directly: /v1/networks, /v1/supply on the REST API.
Related reading: Storj network stats · DePIN infrastructure data · DePIN Intelligence guide · DePIN network data: 327 networks, 69 sources
17 of 20 design-partner seats remain at a lifetime-locked $199/mo (full API access, all 19 endpoints, 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 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