FOLLOW THE MECHANISM
- 1Existing history
Participants share rules and a chain.
- 2Branch or proposal
Competing blocks or new rules appear.
- 3Selection or adoption
- 4Outcome
Histories converge, upgrade together or remain split.
A conceptual sequence. Real implementations can add steps, intermediaries, and conditions.
A temporary branch can be ordinary
Two valid blocks may appear with the same parent because producers and peers do not receive information instantly. A fork-choice rule determines which branch nodes follow as more information arrives. When a node changes its selected branch, some previously included transactions may be displaced. This reorganization does not necessarily mean the network changed its rules or suffered a permanent political split. It can arise under the existing rules.
A rule change is another kind of fork
A soft-fork change tightens validity conditions so new-rule-valid blocks remain acceptable under the old broader rules. A hard-fork change allows behavior that older rules reject. These describe compatibility between rule sets, not whether a change is good or controversial. A well-coordinated hard fork can be an ordinary upgrade without leaving a persistently used competing chain. Older software still needs to understand the applicable rules.
A lasting split creates separate contexts
If groups continue using incompatible histories, assets and contract state may initially appear on both branches. Their subsequent behavior, accepted identity and market value can diverge. External issuers cannot duplicate real-world backing merely because ledger entries were copied. A stablecoin issuer or bridge may recognize only one branch. Replay protection and application support also matter; a copied address is not a complete guarantee of independent safe use.
Software does not adopt itself
Developers can publish a proposal and implement code, but operators choose what to run and economic participants decide what systems to use. This social layer is distinct from routine onchain consensus about transactions. Governance differs across networks; some also use explicit token voting. Describing an upgrade therefore requires identifying who proposes, reviews, implements, activates and accepts it, rather than attributing the entire process to a single founder or miner.
MAKE IT CONCRETE
A copied claim is not copied collateral
Imagine a token issuer holding 100 real currency units against 100 tokens when a chain permanently splits. Both branches may show 100 token entries, but the issuer still holds only 100 currency units. Which branch has a supported redemption claim depends on the issuer’s actual arrangement. The fork has copied records, not doubled the reserve.
FAILURE PATHS & COMMON MISREADINGS
Where the model can break
- A temporary chain reorganization is not automatically a protocol upgrade.
- A hard fork does not automatically create a valuable second asset.
KEEP EXPLORING