Skip to content

hard fork upgrade

One of the significant limitations of the normal upgrade procedure via governance is that it needs to wait for the entire voting period.

This duration makes it unsuitable for automated upgrades involving patches for security vulnerabilities or other critical components.

A faster alternative to using governance is to create a hard fork procedure. This process automatically applies changes to upgrade plans, allowing them to execute at a given block height without creating a governance proposal.

The high-level strategy for coordinated upgrades is as follows:

  1. Bugfixes are on private branches that contain breaking changes.
  2. Need to create a new patch release (e.g. v8.0.0 -> v8.0.1) which contains the hard fork logic and performs upgrades to the next breaking version (e.g. v9.0.0) pre-defined blocks high.
  3. Validators upgrade their nodes to a patched version (eg "v8.0.1"). In order to successfully perform a hard fork, it is important that enough validators upgrade to the patched version such that they represent at least 2/3 of the total validator voting power.
  4. One hour before the upgrade time (corresponding to the upgrade block height), a new main version (such as v9.0.0) containing bug fixes will be released.

IMPORTANT: Posts need to be created 1 hour in advance because It takes about 30 minutes to create release binaries, validators need buffer time to download them and update them cosmovisor setting.