Skip to main content
This document describes the steps for validators and full node operators to upgrade to Neutron v9.0.0 on the Pion testnet.

Upgrade Information

  • Chain upgrade point: November 12th 2025, 14:00 UTC (approximately) at height 40007500
  • Go version: v1.23
  • Release: v9.0.0
COORDINATED TESTNET UPGRADE ON HEIGHT 40007500. DO NOT APPLY MANUALLY.

Chain ID

The chain-id of the network will remain the same, pion-1. This is because an in-place migration of state will take place, i.e., this upgrade does not export any state.

System Requirements

  • RAM: 64GB RAM is recommended to ensure a smooth upgrade
  • Disk Space: Ensure you have enough disk space for the upgrade, as the state can grow twice during the upgrade process
If you have less than 64GB RAM, you might try creating a swapfile:
sudo fallocate -l 64G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Backups

Prior to the upgrade, validators are encouraged to take a full data snapshot. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the .neutrond directory. If you use Cosmovisor to upgrade, by default, Cosmovisor will backup your data upon upgrade. See below upgrade using cosmovisor section.
It is critically important for validator operators to back-up the .neutrond/data/priv_validator_state.json file after stopping the neutrond process. This file is updated every block as your validator participates in 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.

Current Runtime

The Neutron testnet network, pion-1, is currently running Neutron v8.0.0-rc0. We anticipate that operators who are running on v8.0.0-rc0, will be able to upgrade successfully. Validators are expected to ensure that their systems are up-to-date and capable of performing the upgrade. This includes running the correct binary, or if building from source, building with go 1.23.

Target Runtime

The Neutron testnet network, pion-1, will run Neutron v9.0.0. Operators MUST use this version post-upgrade to remain connected to the network.

Create the Updated Neutron Binary

Clone or Update Repository

Go to neutron directory if present else clone the repository:
git clone https://github.com/neutron-org/neutron.git

Build from Source

Follow these steps if neutron repo already present:
cd $HOME/neutron
git pull
git fetch --tags
git checkout v9.0.0
make install

Verify Installation

Check the new neutron version, verify the latest commit hash:
$ neutrond version --long
build_tags: netgo,ledger
commit: acaebf89c9be287a69471215c2f20863a9dcb5cd
cosmos_sdk_version: v0.50.13-neutron.0.20250512094026-b5afd837c4de
go: go version go1.23.10 darwin/arm64
name: neutron
server_name: neutrond
version: 9.0.0

Or Verify Downloaded Binary

Or check checksum of the binary if you decided to download it:
$ shasum -a 256 neutrond-linux-amd64
c857360077b71782642d755c35da210b6bfc43a48580121cda0376d3e2fe7819  neutrond-linux-amd64

LibWasm Version Check

Make sure you are using the proper version of libwasm. You can check the version you are currently using by running the following command:
$ neutrond q wasm libwasmvm-version
2.2.4
The proper version is 2.2.4. If the version on your machine is different you MUST change it immediately!

Ways to Change LibWasmVM

  • Use a statically built Neutrond binary from an official Neutron release: v9.0.0
  • Manual linking (if built from source): If you built Neutron binary by yourself, libwasmvm should be loaded dynamically in your binary and somehow, the wrong libwasmvm library was present on your machine. You can change it by downloading the proper one and linking it to the Neutron binary manually:
    # Download a proper version of libwasmvm
    $ wget https://github.com/CosmWasm/wasmvm/releases/download/v2.2.4/libwasmvm.x86_64.so
    
    # Tell the linker where to find it
    $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib/
    
    # Check that libwasmvm version is correct
    $ neutrond q wasm libwasmvm-version
    2.2.4
    

Upgrade Steps

There are 2 major ways to upgrade a node:
  • Manual upgrade
  • Upgrade using Cosmovisor
    • Either by manually preparing the new binary
    • Or by using the auto-download functionality (this is not yet recommended)
If you prefer to use Cosmovisor to upgrade, some preparation work is needed before upgrade.

Method I: Manual Upgrade

Make sure Neutron v9.0.0 is installed by either downloading a compatible binary, or building from source. Building from source requires Golang 1.23.x.
1

Run Current Version

Run Neutron v8.0.0-rc0 till upgrade height, the node will panic:
ERR UPGRADE "v9.0.0" NEEDED at height: 40007500: upgrade to v9.0.0 and applying upgrade "v9.0.0" at height: 40007500
2

Stop and Switch Binary

Stop the node, and switch the binary to Neutron v9.0.0 and re-start by neutrond start.
3

Wait for Network

It may take several minutes to a few hours until validators with a total sum voting power > 2/3 to complete their node upgrades. After that, the chain can continue to produce blocks.

Method II: Upgrade using Cosmovisor

Preparation

Install the latest version of Cosmovisor (1.5.0):
go install cosmossdk.io/tools/cosmovisor/cmd/[email protected]
Verify Cosmovisor Version:
cosmovisor version
cosmovisor version: v1.5.0

Setup Directory Structure

1

Create Cosmovisor Folder

Create a Cosmovisor folder inside $NEUTRON_HOME and move Neutron v8.0.0-rc0 into $NEUTRON_HOME/cosmovisor/genesis/bin:
mkdir -p $NEUTRON_HOME/cosmovisor/genesis/bin
cp $(which neutrond) $NEUTRON_HOME/cosmovisor/genesis/bin
2

Prepare v9.0.0 Binary

Build Neutron v9.0.0, and move neutrond v9.0.0 to $NEUTRON_HOME/cosmovisor/upgrades/v9.0.0/bin:
mkdir -p  $NEUTRON_HOME/cosmovisor/upgrades/v9.0.0/bin
cp $(which neutrond) $NEUTRON_HOME/cosmovisor/upgrades/v9.0.0/bin
3

Verify Structure

Then you should get the following structure:
.
├── current -> genesis or upgrades/<name>
├── genesis
   └── bin
       └── neutrond  #v8.0.0-rc0
└── upgrades
    └── v9.0.0
        └── bin
            └── neutrond  #v9.0.0

Start with Cosmovisor

Export the environmental variables:
export DAEMON_NAME=neutrond
# please change to your own neutron home dir
# please note `DAEMON_HOME` has to be absolute path
export DAEMON_HOME=$NEUTRON_HOME
export DAEMON_RESTART_AFTER_UPGRADE=true
Start the node:
cosmovisor run  start --x-crisis-skip-assert-invariants --home $DAEMON_HOME
Skipping the invariant checks is strongly encouraged since it decreases the upgrade time significantly and since there are some other improvements coming to the crisis module in the next release of the Cosmos SDK.

Expected Upgrade Result

When the upgrade block height is reached, Neutron will panic and stop. After upgrade, the chain will continue to produce blocks when validators with a total sum voting power > 2/3 complete their node upgrades.

Upgrade Duration

Most likely it takes a couple of minutes.

Rollback Plan

During the network upgrade, core Neutron team will be keeping an ever vigilant eye and communicating with operators on the status of their upgrades. During this time, the core team will listen to operator needs to determine if the upgrade is experiencing unintended challenges. In the event of unexpected challenges, the core team, after conferring with operators and attaining social consensus, may choose to declare that the upgrade will be skipped. Steps to skip this upgrade proposal are simply to resume the pion-1 network with the (downgraded) v8.0.0-rc0 binary using the following command:
neutrond start --unsafe-skip-upgrade 40007500
There is no particular need to restore a state snapshot prior to the upgrade height, unless specifically directed by core Neutron team.
Important: A social consensus decision to skip the upgrade will be based solely on technical merits, thereby respecting and maintaining the decentralized governance process of the upgrade proposal’s successful YES vote.

Risks

As a validator performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing. The riskiest thing a validator can do is 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.

FAQ

No. Most likely the upgrade will be completed successfully. But you get AppHash error after the network gets up. It’s a lot safer to restart full process from scratch (recover the node from a backup).To perform an upgrade you need to keep your ./data/priv_validator_state.json file when you are applying a snapshot from the backup. This will help you avoid the risk of slashing due to double signing.

Additional Resources