Skip to content
LogoLogo

15. Versioning

  • Any change to §§2–11 is a consensus change. It needs a new spec version and updated vectors.
  • After mainnet, changes go through soft forks:
    • define a reserved lock kind (§4.3), add rules for transaction versions above 2, or tighten an existing rule;
    • each is activated through a version-bits deployment (§9.4).
  • Loosening a rule (making something invalid valid) is a hard fork and needs every node to upgrade by a flag height.
  • Changes to §§12–14 are versioned through VERSION.protocol and the /v1 API prefix.
  • PST (§16) is versioned by its own version byte. New fields need a new version.