Measured by crawling the network from seed.thelionpool.org, an independent DNS seed (how the seed is operated). Every node counted here was connected to directly and answered.
On 27 Sep 2026 at 21:28 UTC the seed switched to new crawler software, LionSeed.
Figures from the 21:43 UTC sample onward come from the new crawler. It started with a shorter history than the old one, so the counts stepped down at the switch and will rebuild over roughly two days. That drop is the change of crawler, not nodes leaving the network. The new crawler also reaches Tor and I2P nodes, so from that point the post-fork counts include them. The stable nodes list below restarted its observation period at the switch as well.
Two limits, both of which make these numbers a lower bound.
First, a crawler only sees nodes that accept incoming connections. Anything behind NAT that never listens is invisible to it. Second, “rated good” is the seeder’s own quality gate: the node answered a handshake in the last hour, on the right port, with the right services and height, and has a solid uptime record. A node that is up but new to the crawler, or that dropped out recently, is not counted yet. Treat the good count as “confidently serveable”, not as “every node that is up”.
PR #419 changes a consensus rule. A node on an older release is not necessarily on a different chain: it only diverges if a block spends a coinbase output younger than the long maturity.
—
Share of reachable post-fork nodes running a release that contains the consensus rule, sampled by this crawler roughly once an hour. Raw samples, not smoothed.
| Sample time (UTC) | Enforcing | Reachable post-fork nodes | Share |
|---|
This is the number that matters before a consensus change. A node only enforces a new rule if it is running code that contains it.
Each node reports its block height during the handshake. A cluster stuck well behind the rest is the first visible sign of a chain split — so the post-fork nodes are split here into those on an enforcing release and those not, to show whether the two groups are drifting apart.
| Distance from the highest block seen | All | Enforcing | Not enforcing |
|---|
Heights are as of each node's last handshake, not this instant, so some of the spread is crawl recency rather than real lag. A genuine split would show as a persistent cluster in the bottom row across several updates.
If you run a curated, fixed-list seed rather than a crawler, the hard part is knowing which nodes are actually reliable. This is that evidence: post-fork nodes this crawler has found consistently reachable, with the figures behind the claim.
This is evidence to curate from, not a list to serve unexamined. A curated seed is resistant to Sybil attacks precisely because a human chooses it. An attacker cannot get in by running nodes. Serving this list verbatim would hand that property away, because anything that keeps its uptime high ends up here automatically. Use it to inform your judgement, not to replace it.
| Address | 2h | 1d | 7d |
|---|
Addresses only, deliberately without the software each one runs: the version mix is published above in aggregate, but tying a specific address to a specific version on a network this small would be an inventory of who runs what. Full machine-readable list: stable-nodes.json. Longer windows read low while the crawler is young. They are averages that start empty and fill as it runs, which is why the qualifying window widens over time rather than being fixed at 30 days from day one.