What is soft fork?

A rule change that only tightens what is valid, so blocks made under the new rules are still accepted by nodes running the old software.

This backwards compatibility is why most Bitcoin upgrades take this form: segwit and taproot were both soft forks, and a node that never upgraded still follows the chain. Tightening is not free of politics, since a soft fork still needs enough of the network to enforce it, and an unenforced rule is not a rule. Compare hard fork, which splits the network if adoption is partial. The quiet cost is that nodes which never upgrade accept blocks they cannot fully validate, following the chain while relying on upgraded nodes to enforce the new rule. See fork.

For a holder, the everyday consequence is that a soft fork does not create a second asset and does not require you to do anything. That is precisely why they are preferred.

How it works

Think of the rule set as a filter. A soft fork makes the filter stricter, so the set of valid blocks shrinks. Anything the new rules accept, the old rules already accepted, which is what backwards compatibility means here. A hard fork widens the filter instead, so new blocks look invalid to old software and the network splits unless everyone upgrades.

Deployment on Bitcoin has generally used miner signaling in the block version field. BIP-9 defined the version-bits mechanism, where a bit is set during a signaling window and the change locks in once a threshold of blocks within a retarget period signal for it (source: BIP-9). Taproot was deployed with a variant of that approach and activated at block 709,632 in November 2021 (source: BIP-341).

The subtlety in the definition is what an un-upgraded node is really doing. It follows the same chain, sees the same balances, and validates the old rules correctly. It cannot check the new rule, so it accepts as valid a transaction that upgraded nodes would reject. It is secure by deference rather than by verification.

Example

Illustrative rule change. Suppose the old rules accept any block up to 4 million units of weight, and a soft fork lowers that ceiling to 2 million. Every block valid under the new rules is under 2 million, and every block under 2 million was already valid under the old rules, so old nodes accept all of them without complaint. Now reverse it: raising the ceiling from 2 million to 4 million would produce blocks old nodes reject outright, which is a hard fork and a chain split for anyone who did not upgrade. Same parameter, opposite direction, entirely different outcome.

Why it matters when you buy

Upgrades of this kind rarely affect a purchase, but they do affect address support. Taproot addresses, for example, only became usable once wallets and exchanges added them, and withdrawals to unsupported address formats still fail today. The exchange pages list what each venue supports, and the block explorer guide covers checking what actually happened to a transaction.

Related terms

• hard fork — the incompatible kind of change
• fork — the general category
• segwit — a soft fork you may still be paying for
• taproot — the most recent Bitcoin example
• node — what enforces or defers to the rule
• consensus — what the rules define

Questions

Do I need to upgrade my wallet for a soft fork?

Not to keep using it. You may need to upgrade to use the new capability, which is why Taproot addresses were unavailable in older wallets long after activation.

Can a soft fork still split the chain?

Yes, if a significant part of the network refuses to enforce it. The compatibility guarantee holds only while a strong majority of block producers apply the tighter rule.

Why not just use hard forks?

Because a hard fork requires effectively everyone to upgrade at once, and anyone who does not ends up on a separate chain. Soft forks avoid coordinating the whole network in lockstep.