Hard fork vs chain split
Two words for two things that happen close together in time and get treated as synonyms in casual writing. They are not the same. A hard fork is a protocol upgrade — a change to the rules that decide which blocks are valid. A chain split is what happens when a hard fork doesn't get the coordination it needs, and two groups of nodes keep running two versions of the rules side by side. Same mechanism at the moment of activation, different outcome in the days that follow.
Hard fork: the rule change. Chain split: what happens when the rule change doesn't have consensus and both versions persist. Every hard fork creates a moment where a split is possible; only the ones without coordination turn into a lasting one.
What a hard fork actually changes
Every node holds its own copy of the protocol rules and checks every incoming block against them. A hard fork changes those rules in a way that widens the set of valid blocks — a block the old rules would have rejected is now accepted. Nodes running the new rules will build on such a block; nodes still running the old rules will not, because to them it is invalid.
From the moment the change activates, the two rule sets produce two accept-or-reject decisions for any block that uses the new-only features. If both groups continue producing blocks, they diverge — each on the chain their rules accept, neither on the other. That is a chain split.
Why coordination is mandatory
In a network with a central operator, an upgrade can be pushed. Everyone runs the new code because the operator says so, and there is no "old version" being maintained by anyone. In a peer-to-peer network there is no operator to push, so the only mechanism available is coordination: node operators, mining pools, exchanges and wallet developers agreeing to run the same version at the same time. When enough of them do, the old version has nobody running it, and the upgrade proceeds as if it were one continuous chain — because for every node that matters, it is.
When enough of them don't, the upgrade doesn't fail exactly — it succeeds for the group that moved and fails for the group that stayed, and the network divides into those two groups. The chain the old-rules group extends is not the same chain the new-rules group extends. The counting rule finds them both, and asks its two questions of each.
When coordination fails: the chain split
The word "chain split" earns its usual meaning in this case — the disagreement is real, the minority is large enough to keep producing blocks, and the old-rules chain persists as a working network with its own miners, its own wallets and its own market. Bitcoin and Bitcoin Cash split this way in 2017. Bitcoin Cash and Bitcoin SV split this way in 2018. Ethereum and Ethereum Classic split this way in 2016. Each is a case where a hard fork happened and the coordination that would have made it a straightforward upgrade did not hold.
Most hard forks are not like these. Most are coordinated well enough that the old-rules chain has no mining population and no market by the second block after activation — the network moves, the old rules are effectively unmaintained, and the upgrade shows up in people's wallets as if nothing happened. The rule change was still, technically, the same kind of event; the difference is only in whether anyone stayed behind.
What the counting rule does with this
The site's counting rule doesn't ask about the intent of a fork, who was "right", or which side inherited the ticker. It asks two questions, of each chain that exists after the split: does it have its own base-layer blockchain, and does it have its own consensus mechanism? If both answers are yes, it is counted. If either is no, it is not.
Almost every fork-produced chain fails the test — not because of anything about the fork itself, but because the losing side stops producing blocks and the losing chain therefore stops existing as a working network. A chain that no miner extends is not a chain the counting rule can find, because there is nothing to check. This is why the ranking lists BTC, BCH and BSV separately (all three still have their own miners and their own consensus) but does not list every one of the Bitcoin forks that have been attempted since 2017 — of which Wikipedia names four that produced a distinct chain, and of which most have effectively no hashrate or trading market today.
The test is passive rather than editorial. The site does not decide which forks count; the market of miners and node operators decides that, by continuing to run one chain or by abandoning it, and the counting rule reports what they left behind.
Where the site's opinions go
Neutrality on the counting question is the site's discipline; neutrality on which forks were good is not. The counting rule tells you whether BCH is a cryptocurrency (it is); it does not tell you whether the 2017 fork was the right decision, or which side inherited what mattered about the original protocol. Those are questions with real answers and the site is going to answer them — on the per-asset pages, where the analysis sits in its own section, visually distinct from the arithmetic.
The rest of the Journal continues the arithmetic. This piece and the counting rule applied to BTC/BCH/BSV both stop at "the rule finds three chains." The coin pages themselves will pick up where the rule leaves off.
A follow-up on soft forks — and specifically why SegWit, usually filed under "soft fork", would technically have produced a chain split if a meaningful minority had refused it. Coordination there was so complete that the question never came up in practice, which is the whole point.
This post argues about definitions, not figures, so it does not carry a data stamp. The definitions are stable; the list of chains they identify is what moves.