Assets
Exchange
Buy Crypto
Products

A soft fork is a backward-compatible change to blockchain consensus rules that makes some previously valid blocks or transactions invalid without requiring every participant to upgrade.
In practice, the new rules become stricter, not broader. Old nodes can still accept blocks produced under the new rules because those blocks also fit within the older, less restrictive rule set. However, old nodes do not understand or enforce the new restrictions themselves. Bitcoin’s BIP documentation defines a soft fork in essentially this way: structures valid under the old rules can become invalid under the new ones, while anything already invalid stays invalid.
A successful soft fork normally keeps the network on the same blockchain and does not create a second coin. Bitcoin upgrades such as SegWit and Taproot were deployed through soft forks rather than launching separate versions of BTC.
A soft fork works by narrowing the set of valid blockchain activity, so anything that follows the new rules still remains acceptable under the broader old rules.
A simplified example makes the logic easier to see.
Imagine the old consensus rules allow blocks up to 2 MB. A soft fork introduces a stricter rule that upgraded nodes will accept only blocks up to 1 MB.
A 1 MB block passes both rule sets:
But a 1.5 MB block produces a different result:
That relationship is the key to backward compatibility. The new valid set fits entirely inside the old valid set.
Old rules: 0–2 MB valid
New rules: 0–1 MB valid
The old software therefore does not need to understand the new rule to keep following compliant blocks. It simply sees those blocks as valid according to the rules it already knows.
This distinction matters because “backward compatible” is sometimes explained too loosely. Old nodes do not start enforcing the soft fork automatically. They continue enforcing only their original rules and may accept blocks that upgraded nodes would reject. Bitcoin’s own SegWit specification demonstrates this directly: non-upgraded nodes continued operating, but they did not validate the new witness data introduced by the upgrade.
That is also why a soft fork still requires coordination. If miners or other block producers continue creating blocks that satisfy the old rules but violate the activated new ones, upgraded nodes can reject those blocks. A soft fork is compatible by design, but compatibility does not eliminate the need for successful activation and enforcement.
Why 2,016 blocks? At Bitcoin’s 10-minute target block time, that is roughly two weeks — the same interval used for difficulty adjustments.
The core difference is compatibility: a soft fork tightens existing rules so old nodes can remain on the same chain, while a hard fork introduces rules that old software cannot fully accept.
A hard fork does not automatically create a second cryptocurrency. If nearly everyone upgrades and the old rule set is abandoned, the network can continue as one chain. A lasting split happens when meaningful groups continue supporting both incompatible rule sets.
That is different from a soft fork, where upgraded blocks are deliberately constructed to remain acceptable to older nodes.
Ordinary holders often do not need to take any immediate action after a soft fork, but nodes must upgrade if they want to enforce the new consensus rules themselves.
The impact depends on how you interact with the network:
This is an important distinction: remaining on the chain is not the same as fully validating the upgraded protocol. An old Bitcoin node could continue following the chain after SegWit activation, for example, but it could not independently enforce SegWit’s new witness rules.
For most holders, a successful soft fork should therefore feel uneventful. The major changes happen at the protocol and validation level rather than through a mandatory migration of users’ coins.
Bitcoin has used soft forks to add major features without forcing every existing node to adopt a completely incompatible set of consensus rules.
Three examples show how flexible this upgrade path can be:
These upgrades also show that “soft” does not mean minor. SegWit and Taproot changed important parts of Bitcoin’s transaction and scripting system while preserving compatibility with nodes that had not yet upgraded.
A soft fork is designed to preserve one canonical blockchain, but temporary splits can still occur if some block producers fail to follow the newly activated rules.
After activation, upgraded nodes reject blocks that violate the soft fork. Older nodes may still accept those same blocks because they do not know about the new restriction.
That creates a coordination risk. If enough miners continue building on a block that upgraded nodes reject, the network can temporarily diverge until one branch loses support and is reorganized.
This is why saying “soft forks cannot split a blockchain” is too absolute. Backward compatibility reduces the need for a permanent split, but it does not eliminate activation or coordination risk.
The key distinction is the expected outcome: a successful soft fork is intended to converge on one chain under the stricter rules, whereas a hard fork can sustain two incompatible chains if separate communities continue supporting each rule set.
A soft fork does not have one universal activation method — “soft fork” describes compatibility between rule sets, not a specific voting threshold or governance process.
Bitcoin has used different activation mechanisms over time. One example is BIP 9, where miners signal readiness for a proposed rule change through version bits in mined blocks. If the required threshold is reached within the defined activation window, the new rules can lock in and later become active.
Other mechanisms, such as BIP 8, were designed with different activation parameters, including the possibility of activation by a predetermined block height.
What matters after activation is enforcement: blocks that violate the new rules are rejected by upgraded nodes, even if older nodes would still consider them valid.
There is no universal “51% rule” for soft forks. Bitcoin’s BIP 9 framework used a 95% signaling threshold, while Taproot’s 2021 Speedy Trial used 90%.
For most holders, a successful soft fork changes the protocol rather than the ownership of their coins.
In a normal soft-fork activation:
This is why a soft fork such as SegWit or Taproot is very different from a chain split like Bitcoin Cash. SegWit and Taproot changed Bitcoin’s consensus rules while BTC remained the same asset on the same canonical blockchain.
For ordinary users, the main practical question is therefore not “Will I get new coins?” but “Do I need updated software to use the new functionality?”
Yes. Soft forks remain an active part of Bitcoin protocol development, although a proposed BIP is not the same thing as an approved or activated upgrade.
Bitcoin’s current BIP repository still includes multiple proposals explicitly categorized as Consensus (soft fork). Examples include BIP 347 (OP_CAT), BIP 348 (CHECKSIGFROMSTACK), and newer proposals such as BIP 448 and BIP 449.
BIP 347 is a useful example of the distinction between specification and activation. Its current specification is marked Complete and describes reintroducing OP_CAT into Tapscript through a soft fork. That does not mean OP_CAT is active on Bitcoin today; it means the technical proposal itself has reached that specification status.
So when reading about a “new Bitcoin soft fork,” check whether it is:
Soft forks are therefore not just part of Bitcoin history. They remain one of the mechanisms developers can use to propose stricter consensus rules while preserving compatibility with older nodes.
Want a simple way to manage your crypto through network upgrades? Get Atomic Wallet to store, send, receive, and swap assets while keeping control of your private keys.

Learn what DeFi means, how decentralized finance works, how lending, DEXs, liquidity pools, and yield work, and the key benefits and risks.