Network Rule

Overview

Network rules can be consensus-critical, such as signature validity and block limits, or local policy, such as mempool fee thresholds and peer bans. Consensus rules must be applied consistently by validating nodes to preserve one ledger.

Changing a consensus rule can require a soft fork, hard fork, governance upgrade, or coordinated activation. Local rules can vary without splitting consensus, although they affect propagation and access. Documentation should never mix the two categories. Implementers must identify rule scope, version, activation point, and failure response. Nodes should reject invalid data before using it in fork choice. Payment providers need to track upgrades because transactions accepted under previous rules may become nonstandard or incompatible after activation.

Changes to Network Rule require clear activation and upgrade authority. Consensus-affecting changes may require coordinated deployment, while local-policy changes can alter propagation or service behavior without changing ledger validity. An accepted request or message is not necessarily proof that the intended state transition or settlement completed. Applications relying on Network Rule should retain the inputs, outputs, network, version, responsible component, and evidence of success or failure.

Network Rule should be tied to a precise scope such as message format, state transition, participant role, contract interface, or operational policy. Similar labels can describe consensus-critical rules, local node policy, application conventions, or business procedures with very different effects. A written rule has no operational effect unless the active components enforce it consistently. Implementations of Network Rule need an exact specification and version, deterministic validation, defined errors, and compatibility tests across independent software.