cosmoshub-4 chain launched on 2021-02-18 at height 5200791 (the genesis file carries the cosmoshub-3 date of 2019-12-11 in genesis_time) on gaia v4.2.1. It has been upgraded in place ever since. This table says which binary applied which heights. Operators need it to replay history (an archive node built from genesis must switch binaries at every row), to interpret old state, and to see how upgrades are run on the Hub. The process is on Upgrade a node.
How to read the table
Governance rows come from the passedMsgSoftwareUpgrade proposals on chain, checked on 2026-10-15 through the governance REST API (/cosmos/gov/v1/proposals). Each is linked to the proposal on Mintscan. Halt-height rows come from gaia release notes. They have no on-chain plan, so gaiad query upgrade applied <name> returns nothing for them. The binary column names the release line. Where more than one patch could have been in use at that height and the notes do not pin one, the row says so. Heights are the first block produced by the new binary.
Some rows hide a detour. The patches at heights 32830000 and 33086740 first reached validators privately, under the version numbers v28.1.0 and v28.3.0, before the public tags v28.1.1 and v28.3.1 were published. The binary column always names the public tag whose release notes cover that height, so a node replaying from genesis uses the public tags only. Security patches applied as rolling upgrades, with no coordinated height, have no row: v7.1.0 (Dragonberry, 2022-10), v7.1.1, v8.0.1, v9.1.1 (Huckleberry), v25.1.1, and v25.3.1. The v25.3.1 release notes say the fix is not in the tagged commit, so use the release binary rather than a source build if you ever need that version.
To check a governance row yourself:
{"height":"33073000"} on 2026-10-15. The CLI prints the block header at that height on a node that keeps it.
Upgrades on cosmoshub-4
Dates in the pattern column are the day voting ended, not the day the height was reached. The upgrade height usually fell a few days later. The chain registry versions file carries the same sequence with the Cosmos SDK, CometBFT, and ibc-go version of each release. It lagged the chain by one release on 2026-10-15 (it still named v28.0.0 as recommended).
Replay history
A node that must build the full history from genesis switches binaries at every row above, with a Go toolchain old enough for each release. It also replays every migration. Nobody does this to run a node. Restore an archive snapshot instead, as on Sync a node. The table is what you need when you are asked which binary produced a block, or when you export state at an old height withgaiad export --height <height> on the matching binary.
The current binary carries the handler for the most recent governance upgrade only: app/upgrades in gaia v28.3.1 contains v28_2_0. A v28.3.1 node cannot apply any earlier upgrade height. That is why old binaries are kept on the releases page and why the rows above matter.
Earlier chains
Genesis files for every chain id are in cosmos/mainnet with checksums in
genesis/genesis_checksum.md. The Archives page covers where exported state and block data for the earlier chains are kept. The gaia version lines for the earlier chains come from the previous version of this page and were not re-verified.