A blockchain fork can refer either to a temporary branch caused by two competing blocks or to a change in consensus rules. A soft fork preserves old nodes' ability to accept blocks produced under the new rules, while a hard fork introduces rules that old nodes reject.
These two meanings are often confused. A temporary branch can resolve automatically during normal network operation, whereas a protocol fork involves software versions, activation conditions, and whether participants accept the new rules.
While blocks are propagating through the network, two producers may propose new blocks based on the same parent at nearly the same time. Some nodes see block A first, while others see block B, temporarily giving the ledger two candidate chain tips. As additional blocks are produced, nodes use the protocol's fork-choice rule to converge on one history.
Protocol upgrades are another cause. When developers release new rules, whether nodes upgrade, whether the rules are backward compatible, and whether participants activate them at the same time all affect the network's ability to remain on a single chain.

| Comparison | Soft fork | Hard fork |
|---|---|---|
| Rule change | Usually narrows the existing set of valid rules | Introduces new rules that old nodes do not recognize |
| How old nodes view new blocks | May still consider them valid but cannot check every new rule | Reject blocks that comply only with the new rules |
| Upgrade requirement | Unupgraded nodes can continue following the chain, but with reduced verification capability | Nodes that participate in the new chain must upgrade |
| Does it inevitably create two chains? | No | No; it depends on whether anyone continues maintaining the old rules |
Compatibility in a soft fork does not give old nodes the same level of security. They cannot enforce the added restrictions and must accept the results produced by upgraded nodes. A hard fork can also leave only one active chain if all key participants coordinate their upgrades.

Nodes do not choose a chain solely by which block arrived first or which branch has more blocks. Proof-of-work networks generally compare cumulative work; see Proof of Work (PoW) for details. Proof-of-stake networks may select a chain tip based on validator weight, voting, and finality rules.
Ordinary transactions on the unselected branch do not necessarily disappear forever. If a transaction does not conflict with the main chain, it may return to the pending pool and be included later. Applications that already relied on that transaction may see its confirmation reversed, which is one reason to wait for sufficient confirmation depth.
No. Two chains can persist only when some participants continue maintaining the old rules while others adopt the new rules, and both sides form sustainable networks. Whether two tradable assets emerge also depends on wallets, trading platforms, replay protection, liquidity, and community support.
Many planned hard forks are simply protocol upgrades. Nodes switch together at an agreed block height, and no one continues maintaining the old chain. The term hard fork alone does not mean that users will receive an equal amount of a new coin.
Users should verify the upgrade height, client version, and trading platform arrangements through official project channels. Never submit a private key or seed phrase to an unfamiliar website to claim a supposed forked coin.
Both rule compatibility and adoption must be considered. First determine whether the change affects consensus, networking, or only wallet functionality. Then review the activation conditions, node and validator support, behavior of old versions, replay protection, and whether producers and economic participants will continue maintaining the old rules.
A code release or miner signal alone is not enough to determine the outcome. Nodes, validators, users, developers, and trading platforms each play different roles, and the final chain state emerges from actual operation and economic coordination.
To learn how nodes select and verify blocks, read What Is a Node?. To understand how hashes connect blocks, return to What Is Blockchain?.
No. Updates to interfaces, performance, wallet features, or non-consensus network parameters may leave block validity rules completely unchanged. A consensus fork occurs only when a change affects how participants determine their shared history.
The names alone do not determine safety. Security depends on rule design, implementation, testing, activation, and participant adoption. Soft forks offer stronger compatibility, but old nodes cannot verify the added rules, which introduces its own trade-offs.
If both chains share the pre-fork account history and key system, the original private key may correspond to addresses on both chains. Importing that key directly increases exposure and replay risks, so users should first verify official tools, chain identifiers, and isolation procedures.
No. In a reorganization, a node follows consensus rules and switches from one candidate branch to another, changing the status of related transactions. A database rollback is an internal software operation that other network nodes may not recognize.


