Soft Fork
A soft fork is a backward-compatible change to a blockchain protocol, where only valid blocks under the new rules are considered valid by older nodes.
A soft fork is a change to a blockchain's consensus rules that is backward-compatible. This means that nodes running the updated software will enforce stricter rules, but blocks created under these new rules will still be considered valid by nodes running the older software. However, blocks created under the old rules might be rejected by nodes running the updated software if they violate the new, stricter rules. Soft forks are often implemented to introduce new features or fix security vulnerabilities without requiring the entire network to upgrade simultaneously. The process typically involves a period where both old and new rules are somewhat tolerated, followed by a 'miner activation' phase where miners signal their support for the new rules. Once a sufficient majority of mining power adopts the new rules (often 95% or more), the soft fork is considered active, and blocks violating the new rules will be orphaned. This approach allows for gradual adoption and reduces the risk of a contentious hard fork, but it relies heavily on miner consensus and can be complex to coordinate. Examples include Segregated Witness (SegWit) on Bitcoin.
graph LR
Center["Soft Fork"]:::main
Rel_hard_fork["hard-fork"]:::related -.-> Center
click Rel_hard_fork "/terms/hard-fork"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Knowledge Check
🧒 Explain Like I'm 5
Think of a soft fork like a software update for a text editor. If the update adds a new font, people with the old version can still open and read the documents, but they might just see everything in the default font. They can still participate, even if they don't have the new bells and whistles.
🤓 Expert Deep Dive
Technically, soft forks often leverage 'anyone-can-spend' script outputs or NOP opcodes to remain backward compatible. In SegWit (BIP-141), witness data was moved outside the base transaction block, so old nodes saw the transaction as having no signature (making it valid under old loose rules) while new nodes looked in the witness field for the cryptographic proof. Activation methods are critical: MASF (Miner-Activated) relies on mining pool signaling (e.g., BIP-9), while UASF (User-Activated, BIP-148) represents the 'economic majority' forcing miners to adopt changes. Taproot (BIP-341) further refined this by introducing Schnorr signatures and MAST (Merklized Abstract Syntax Trees) via a soft fork, enhancing privacy by only revealing the executed spend condition.