This document explains how to perform a chain upgrade from v0.39 to v0.42. {synopsis}
::: tip
Please note that the three SDK versions v0.40, v0.41 and v0.42 are functionally equivalent, together called the "Stargate" series. The version bumps are consequences of post-release state-breaking bugfixes.
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and
being slashed: if your validator node votes for a block, and, in the same block time, restarts the upgraded node, this may lead to double-voting on a block.
The riskiest thing a validator can do is to discover that they made a mistake and repeat the upgrade procedure again during
the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start
before correcting it. If the network is halted and you have started with a different genesis file than the expected one,
seek advice from the validator community.
## Recovery
- Prior to exporting the state, the validators are encouraged to take a full data snapshot at exported height. Exported
height will be determined by a governance proposal. Data backup is usually done by copying daemon home directory,
e.g.: `~/.simd`
**Note:** we use "simd" as our app throughout this doc, be sure to replace with the name of your own binary.
It is critically important to back-up the validator state file, e.g.: `~/.simd/data/priv_validator_state.json` file
after stopping your daemon process. This file is updated every block as your validator participates in a consensus
rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails, and the previous chain needs
to be restarted.
In the event that the upgrade does not succeed, validators and operators must downgrade back to old version of the
software and restore to their latest snapshot before restarting their nodes.
## Upgrade procedure
1. The procedure is to export the state from the old binary, and import it with the new binary. First, verify your old binary version (which should use `github.com/cosmos/cosmos-sdk@0.39.*`) before exporting the state.
```shell
simd version --long
```
1. Export the state from existing chain using the old binary.
**Note:** The migrate command takes an input genesis state and migrates it to a targeted version. New `genesis-time` is usually mentioned in the governance proposal, and should be passed as flag argument. If the flag is omitted, then the genesis time of the upgraded chain will be the same as the old one, which may cause confusion.
1. All the necessary state changes are handled in the `simd migrate v0.42` migration command. However, Tendermint parameters are **not** handled in this command. You might need to update these parameters manually.
In the recent versions of Tendermint, the following changes have been made:
-`consensus_params.evidence.max_num` has been renamed to `consensus_params.evidence.max_bytes`.
-`consensus_params.evidence.max_age` has been removed, and replaced by `consensus_params.evidence.max_age_duration` and `consensus_params.evidence.max_age_num_blocks`.
Make sure that your genesis JSON files contains the correct values specific to your chain. If the `simd migrate` errors with a message saying that the genesis file cannot be parsed, these are the fields to check first.
1. Verify the SHA256 of the migrated genesis file with other validators to make sure there are no manual errors in the process.
1. Make sure to update the genesis parameters in the new genesis if any. All these details will be generally present in
the governance proposal.
1) If your chain is using IBC, make sure to add IBC initial genesis state to the genesis file. You can use the following command to add IBC initial genesis state to the genesis file.
**Note:** This would add IBC state with IBC's `send_enabled: false` and `receive_enabled: false`. Make sure to update them to `true` in the above command if are planning to enable IBC transactions with chain upgrade. Otherwise you can do it via a governance proposal.
1) Reset the old state.
**Note:** Be sure you have a complete backed up state of your node before proceeding with this step.
See Recovery for details on how to proceed.
```shell
simd unsafe-reset-all
```
1) Move the new genesis.json to your daemon config directory. Ex
1) Update `~/.simd/config/app.toml` to include latest app configurations. [Here is the link](https://github.com/cosmos/cosmos-sdk/blob/v0.42.0-rc6/server/config/toml.go#L11-L164) to the default template for v0.42's `app.toml`. Make sure to