Hard Fork State: Identity, Not Just Code
By

A hard fork is not primarily a technical problem. It is an identity problem.

When a blockchain’s consensus rules change and not everyone follows the new rules, the chain splits. Two (or more) ledgers share the same history up to a point, then diverge. They may carry the same name, the same ticker, and the same pre-fork balances. Bitcoin has experienced this multiple times.

The operational difficulty that follows is rarely about the code itself. It is about answering, verifiably and consistently, which ledger is which — across custodians, exchanges, auditors, wallets, and supervisors.

The Recent BIP-110 / BLAKE2b Developments

In August 2026, BIP-110 (Reduced Data Temporary Softfork) triggered a chain split at block 961,632. Nodes enforcing the proposal rejected blocks that did not signal support. The majority of hash power continued on the existing rules, producing the chain that the bulk of the network and markets treat as Bitcoin. A minority branch formed.

That minority branch later changed its proof-of-work algorithm from SHA-256d to BLAKE2b. Bitcoin Knots shipped a final release (version 29.4.1) that implements this change. Its release notes describe the chain followed by the rest of the network as “a new altcoin.” The BLAKE2b chain activates a different header format and hashing algorithm, making existing SHA-256 ASICs incompatible.

Because difficulty adjusts only every 2,016 blocks, a low-hashrate chain can temporarily produce blocks much faster (or slower) than the ten-minute target until the next retarget. Early observations of the BLAKE2b branch showed significantly elevated issuance relative to Bitcoin’s schedule while difficulty remained elevated from the parent chain.

Multiple software and explorer implementations now track different lineages that claim connection to the BIP-110 event. An explorer that indexes only one branch can present an incomplete or misleading view of the overall situation. Ordinary holders do not need to track every technical detail, but three practical points matter:

  • Replay risk: Transactions valid on one chain may be valid on another if they share the pre-fork UTXO set and lack sufficient differentiation (for example, via sighash flags or other markers).
  • Lightning exposure: Channels opened on one chain are not automatically valid on another. A node that follows the wrong tip can lose visibility of channel state.
  • Scams and naming confusion: Every meaningful fork attracts opportunistic projects, fake explorers, and social-engineering attempts that trade on the shared history and familiar name.

How Markets Keep Functioning: ISO 24165 and the Digital Ledger Identifier

The market does not need universal agreement on which chain “is Bitcoin.” It needs a reliable way to refer to a specific ledger without relying on contested names.

ISO 24165 provides that mechanism. The standard defines Digital Token Identifiers (DTIs) for tokens and Digital Ledger Identifiers (DLIs) for the ledgers on which they exist. A DLI identifies a ledger through normative data elements unique to it, including its anchor block and fork history. The human-readable name sits in the informative data set and forms no part of the identification.

Because a DTI or DLI is bound to a specific ledger (defined by technical facts such as genesis or anchor block and subsequent fork points), a token that exists on a forked chain receives its own identifier. It does not automatically inherit the original’s identifier. That separation allows exchanges, custodians, and reporting systems to continue operating even when the social and political question of identity remains unresolved.

In practice, this means a holder, exchange, or auditor can point to a concrete set of technical attributes rather than a name that multiple parties claim. The standard does not decide which chain has legitimacy; it records the technical distinctions so that market participants can act without requiring consensus on branding.

What Ordinary Holders Need to Know

  • Coins created before a fork remain spendable on every surviving branch that inherits the pre-fork UTXO set, subject to each branch’s rules.
  • Moving coins on one chain does not automatically move them on another.
  • Software that does not explicitly support a given branch will not see its blocks or transactions.
  • Explorers, wallets, and custodians must be checked against the specific ledger they claim to follow.
  • Naming disputes and marketing claims do not alter the underlying technical history or the identifiers assigned under standards such as ISO 24165.

The recent events around BIP-110 and the BLAKE2b change illustrate the pattern that has repeated across Bitcoin’s history: rule changes that lack broad consensus produce separate ledgers. The technical problem of validation is solvable by software. The identity problem is managed by clear technical identifiers, careful operational practices, and an understanding that names are secondary to the ledger itself.