Storj (STORJ) — the network, measured

Generated 2026-09-02T13:03:45Z from live ClickHouse queries against this estate's ledger. Held inventory: 19,903 observations · 74 distinct series · 4 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-02 12:50:20 · 19,903/19,903 rows carry a verify_url. 68 series refreshed in the last 24h (1,724 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where every number comes from

4 source families feed this network's ledger. Every row they wrote carries its own source, as_of and verify_url; this table is the live rollup of that.

30-day history — headline series (daily last-value, live)

One row per series: latest value, a 30-day sparkline of daily last-known values (scaled to the series' own min→max), day count, and window change. Series absent from the 30-day window are omitted from this table, not zero-filled.

Node ledger per satellite — as Storj counts it

Storj's nodes.json reports node membership per satellite. A node serving three satellites is counted three times, so satellites are shown as held and are deliberately not summed into a "network total" — the same double-count that previously inflated Storj node totals here. NODES_TOTAL in the inventory below is Storj's own aggregate field, kept with the same caveat.

Storage & bandwidth — as held, with the capacity trap declared

Storj publishes the numerator only. storage_total_bytes is what customers have stored (the canonical layer maps it to storage_bytes_in_use); storage_total_bytes_after_expansion is the node-side footprint after erasure coding. There is NO published capacity denominator, so this page computes no storage-utilisation ratio — inventing a denominator is the exact overstatement the estate's canonical-metrics module refuses.

Full metric inventory — 74 measured series, each with provenance

Every series held for STORJ with rows in the last 30 days: latest value, when it was observed, which source observed it, how many rows we hold, how many of the last 30 days it reported, its comparability grade, and the origin link. "days/30" counts distinct dates with at least one row in the window.

Revision ledger — 2 backward revision(s) recorded for STORJ

Backward revisions are values upstream later replaced for a date we had already archived. The before-value is retained — that retention is the only reason a rewrite is detectable, and it is the part every overwriting vendor discards.

Estate grades for STORJ (graded 2026-08-20 13:54:15.000)

Served by /v1/network/STORJ — the same grades a paying agent receives. Scores are the engines' own 0–100 outputs, not ours to smooth.

Verify any cell yourself — the exact commands

No account, no key, no trust required. Commands 1–4 hit the same upstream endpoints our collectors do; command 5 hits this estate's public API, where every row carries the same source / as_of / verify_url fields.

# 1) Per-satellite node ledger — keyless, as of 2026-09-02T13:03:45Z:
curl -s "https://stats.storjshare.io/nodes.json" | python3 -m json.tool
# 2) Storage & bandwidth — keyless:
curl -s "https://stats.storjshare.io/data.json" | python3 -m json.tool
# 3) Dev velocity (GitHub repo) — keyless:
curl -s -H "User-Agent: kairos-check" "https://api.github.com/repos/storj/storj" | python3 -m json.tool | head -40
# 4) Market reference (CoinGecko public API):
curl -s "https://api.coingecko.com/api/v3/coins/markets?vs_currency=usd&ids=storj" | python3 -m json.tool
# 5) This estate's public API row for STORJ:
curl -s "https://kairossignal.com/v1/network/STORJ" | python3 -m json.tool | head -60

Method & honesty notes. All counts are queries against the live ledger at generation time, not restamped copy — this page is regenerated by gen_deep_dive_storj.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. Comparability grades come from the served canonical-metric system via its own per-symbol resolver: total_supply maps to token_supply_total (question-verified), NODES_TOTAL to nodes_total (unit-verified — satellite memberships, not unique nodes), storage_total_bytes to storage_bytes_in_use (question-verified, via the STORJ per-symbol override — it is usage, not capacity). The estate refuses to publish a storage-utilisation ratio for Storj because no upstream source states how many bytes the network could hold; the refusal and its reason are recorded in the canonical module, not invented here. Per-satellite counts are memberships and are never summed. Where a section has no data, it is absent — we do not publish zeros for gaps.