We Joined the IPFS DHT and Counted It
Most "network size" numbers you see for peer-to-peer systems are copied from someone else's dashboard. This week we stopped copying and started counting: Kairos now runs its own crawlers on the IPFS Amino DHT and the BitTorrent Mainline DHT, on a daily cadence, writing results into the same provenance-first pipeline as our other 10,706 live series (as of 2026-08-24).
Here is what we measured, how we measured it, and where the numbers can mislead you.
The IPFS numbers (crawl completed 2026-08-24T13:57:03Z)
Our crawler (source=nebula_crawl_firstparty, built on the open-source Nebula libp2p crawler) walks the DHT routing tables of every server peer it can reach, breadth-first, until it runs out of new peers. The crawl that completed at 13:57 UTC today found:
- 6,416 IPFS DHT server peers sampled (
IPFS_DHT_PEERS_SAMPLED, also ourIPFS_DHT_ESTIMATED_SIZE) - 3,424 dialable = 53.4% reachability (
IPFS_DHT_PEERS_DIALABLE / IPFS_DHT_PEERS_SAMPLED) - 257 distinct agent-version strings (
IPFS_DHT_AGENT_VERSIONS_DISTINCT)
That 53.4% dialability figure is the one an infrastructure analyst should stare at: roughly half of the peers advertised in routing tables were not reachable when we dialed them. A DHT entry is a claim, not a liveness proof. Any headline peer count that doesn't separate listed from dialable is overstating the working network.
The BitTorrent numbers (2026-08-24T13:56:09Z)
We also sample the BitTorrent Mainline DHT first-party, using the sampling approach enabled by BEP-5 (the Mainline DHT protocol spec). Because Mainline is vastly larger than the IPFS DHT, we don't crawl it exhaustively — we sample node-ID space and extrapolate from response density:
- 603 nodes contacted, 327 responded — 54.2% response rate
- Network size estimate: 2,157,199 nodes
Note the scale gap: the BitTorrent Mainline DHT is roughly ~336× larger than the IPFS server DHT by our same-day estimates (2,157,199 vs 6,416). The oldest widely-deployed DHT on the internet is still, by a wide margin, the biggest.
Caveats, stated plainly
We publish measurement caveats the same way we publish for our other physical-world feeds (our military-aircraft counts are transponder-visible-only; our AIS coverage carries receiver-density bias). The DHT crawls have their own:
- Server peers only. The 6,416 figure counts peers in DHT server mode. IPFS clients that don't serve the DHT (most desktop and browser nodes) are invisible to a routing-table crawl. This is a measure of the DHT's infrastructure backbone, not "everyone running IPFS."
- Point-in-time, single vantage. A crawl is a snapshot from our network position. NAT'd peers, transient peers, and peers that rate-limit strangers depress dialability. 53.4% is our reachability, not a universal constant.
- Extrapolated, not enumerated (BitTorrent). The 2,157,199 figure is a statistical estimate from ID-space sampling density, not a census. Treat it as order-of-magnitude with day-to-day variance.
- Denominator choice matters. "53.4% dialable" uses sampled peers as the denominator. Divide by only previously-known-good peers and you'd get a different, flattering number. We publish both numerator and denominator so you can pick your own.
- This series is one day old. First row landed 2026-08-23T15:47:48Z; we have 4 crawls so far, now on the daily cadence. We will not draw trend conclusions from it yet, and neither should you.
Verify it yourself
We think a number you can't check is marketing, so:
- Our crawler's lineage: the crawl engine is built on Nebula, open source at github.com/dennis-tra/nebula. You can run your own crawl and compare against our 6,416.
- Independent cross-check: ProbeLab publishes Amino DHT server counts at probelab.io/ipfs/amino. Put our same-day
IPFS_DHT_ESTIMATED_SIZE=6,416next to their chart and judge the order-of-magnitude agreement yourself. - BitTorrent method: the DHT protocol we sample is specified in BEP-5.
- Our API: the series ship through the same provenance-first endpoints as the rest of the estate — every value carries its source and
as_oftimestamp. Start at the API docs or poke at live data on the try page.
Why we're doing this
Kairos's thesis is that decentralized-infrastructure data should be measured, not repeated. As of 2026-08-26 the estate tracks 327 live networks and 10,706 live series, 3,801 of them first-party series — read from the networks themselves rather than an aggregator. The DHT crawlers extend that to the p2p substrate a lot of DePIN quietly depends on. If you've read how we verify every DePIN number or why every DePIN metric should carry a verify URL, this is the same discipline pointed at the DHT: join the network, count it, publish the method and the denominator.
Want the data? The free tier is at kairossignal.com/try, and the $199 Design Partner plan (pricing) gets you the full daily series.
---
Try it yourself
Query the live catalog, supply telemetry, and provenance receipts directly: /v1/networks, /v1/supply on the REST API.
Related reading: DePIN Intelligence guide · DePIN network data: 327 networks, 69 sources · how we read supply telemetry from 296 networks · the DePIN developer guide
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