How do rule changes become soft or hard forks?

How does the mechanism work?

Think in sets of permitted blocks. With a soft fork, blocks obeying the new restrictions also fit within the older validity set. Older nodes may accept those blocks without checking the newly introduced condition. Upgraded nodes enforce it. That compatibility explains how enforcement can tighten while some older participants continue following the same history.

With a hard fork, some newly permitted blocks fall outside the earlier validity set. Older nodes reject those blocks under their unchanged rules. If participants continue building incompatible histories, a chain split can result. A code repository fork, a software release and a sustained asset split are different events and should not be treated as synonyms.

Activation can use different mechanisms. A proposal needs specified conditions for when its rules take effect. Signalling can contribute to such a mechanism, but a bit in a header is not itself execution of the new checks. A node must actually run and apply the relevant validation rules. A deployment description should identify both its trigger and what enforcement means.

An activation discussion should make its assumptions visible. Which nodes implement the rule? What condition changes enforcement state? What can an unchanged participant still verify? Asking those questions gives a technical description without claiming unanimous adoption. The same proposed feature can have different deployment discussions, while compatibility still depends on the actual validity rules. A flow diagram showing proposal, signalling and enforcement illustrates the roles, not a universal chronology for every historical upgrade. Read the cited mechanism for its precise transitions and avoid transferring its parameters to a different deployment merely because both use the word activation.

How do the protocol numbers work in an example?

For a concrete protocol comparison, SegWit defines a maximum block weight of 4,000,000 units and a separate witness-validation model. Its design allows older validation to view a compatible base-block representation while upgraded validation checks the added witness restrictions. This is a compatibility mechanism, not a claim that both node types perform identical checks.

For an invented hard-fork example, suppose new rules permit a particular output spend that old rules reject. A block including it remains invalid to an unchanged old node even if every miner announces support. The node needs different rules to accept it. If no one produces such an incompatible block, a software change alone does not demonstrate that the chains have split.

One activation framework, version bits, specifies states named DEFINED, STARTED, LOCKED_IN, ACTIVE and FAILED. Its deployment parameters determine transitions over block periods. LOCKED_IN and ACTIVE have different meanings: a completed signalling condition can precede the period when enforcement starts. The source defines the mechanism; this lesson gives no current deployment status or universal activation threshold.