Network Upgrade

Overview

Network upgrades can add transaction types, modify fees, fix vulnerabilities, change validator rules, or improve performance. Activation may occur at a block height, epoch, timestamp, governance decision, or validator-support threshold.

Backward-compatible changes can still require client updates, while incompatible rules may create a hard fork if participants do not adopt the same version. Applications can break even when consensus remains unified because RPCs, contracts, or address behavior change. Operators should test releases, verify binaries, back up critical data, and stage deployment before activation. Payment services need readiness checks for nodes, signers, indexers, and parsers. Monitoring should cover both chain progress and application behavior, with clear rollback constraints after consensus rules activate.

Deposits and payouts need heightened monitoring around activation, and confirmation policies should account for delayed finality, client disagreement, or temporary service suspension without duplicating or losing transactions. Payment systems should treat Network Upgrade as a controlled operational event. Historical references to Network Upgrade should distinguish the rules introduced at activation from later changes that modified or replaced them. Current behavior must be verified against the active specification and client release rather than inferred from the original upgrade announcement.

A fork name alone does not show whether a node has activated the change, whether another chain adopted it differently, or whether historical documentation still matches the live network. Network Upgrade should be documented with its target network, activation condition, affected rules, and compatible software versions. Before Network Upgrade, operators should test database migration, peer compatibility, RPC behavior, transaction construction, and rollback or recovery procedures. Consensus-critical incompatibility can create divergent histories, while application-level incompatibility can silently produce incorrect fees, signatures, or status interpretation.