A hard fork is a big rule change to a blockchain that is not compatible with older rules. When it happens, the chain splits into two paths that share the same history up to the fork and then go their separate ways. Nodes and validators that want to stay with the new rules must upgrade their software, while others can keep running the old version and follow the original chain. Token holders often find copies of their assets on both sides after the split, depending on how wallets and exchanges handle the event.
Teams and communities use hard forks for different reasons: to fix serious bugs or security issues, to add features that break old rules, to roll back damage after a major exploit, to adjust fees or rewards, or because groups disagree on the project’s direction. These disagreements can be technical, philosophical, or both. Sometimes everyone supports the upgrade, and the old chain becomes inactive; other times, the community divides, and both chains continue with separate goals.
A proposal is discussed among developers, node operators, miners or validators, and users. If the change cannot remain compatible with the old ruleset, a specific block height is chosen for activation. At that block, upgraded nodes start enforcing the new rules. Nodes that do not upgrade keep following the old rules. From that point on, each chain accepts different blocks and transactions. The two chains share all blocks up to the fork height, then diverge.
If both chains keep running, users may hold assets on each chain because the ledger history before the split is the same. In practice, access depends on wallet support and exchange listings. Users who operate nodes or validators need to choose which software to run. Even when an upgrade is widely supported, cautious users wait for clear communication from client teams, wallet providers, and exchanges before interacting with the post-fork network.
Public blockchains rely on voluntary participation. No one can force all nodes to accept new rules. A hard fork is what happens when enough participants adopt an incompatible change while others refuse. That lack of consensus is exactly what creates two chains with different rulebooks.
Both are upgrades, but they differ in compatibility. A hard fork rejects blocks that would have been valid before, so older software cannot follow the new chain. A soft fork tightens the rules without breaking compatibility, which lets older nodes still validate new blocks as acceptable even if they do not understand every new feature.
Hard forks can bring upgrades and speed up development, but they also carry risks. Splits can confuse users, fragment developer effort, and reduce network effects if liquidity and community attention are divided. Attack surfaces may grow during the transition window when not all nodes agree on the rules. On the flip side, a clean break can remove legacy constraints and open space for new features that would not fit the old design.