f(x)Core v3.1.0 Manual Upgrade Instructions

f(x)Core Network Upgrades


There are 2 types of network upgrades with similar steps but it is IMPORTANT to differentiate and identify which type of upgrade is required and which to perform before the upgrade height is reached. Hard fork requires validators to upgrade their nodes before the upgrade height and software upgrade requires validators to do so after the upgrade height.

Hard fork upgrade:

The code after the upgrade is backward compatible, so the node can (and needs to) be updated before the upgrade height, and when the upgrade height is reached, the node will automatically switch to the new logic.

Software upgrade:

When the upgrade proposal is passed, we need to wait for the block height to reach the upgrade height set in the proposal. We cannot use the new program to update the node in advance, because the code after the upgrade is backward incompatible. When the block height reaches the upgrade height, the node will automatically stop producing blocks and print the log: "ERR UPGRADE" upgrade proposal plan name "NEEDED at height: upgrade proposal set height...", and then we can use the latest program to update the node

For more information on past upgrades and instructions, refer to Upgrade Versions.

You may refer to this Countdown Timer which will countdown the time till the upgrade height.

Upgrade steps

  1. Ensure you have stopped the node❗

sudo systemctl stop fxcored

2. Get the latest fxcored binary

1. Pulling the latest fx-core code base (ensure that you are in the fx-core folder):

git pull

2. Checkout the branch of the upgrade version:

git checkout <upgradeable version branch>

for example:

git checkout release/v3.1.x


git checkout tags/v3.1.0 -b release/v3.1.x

Check log whether is the latest commit

git log

commit 49d991f692d6662660c2c2dd9e009238f595c438 if you checked out the branch without specifying the tags

3. Update fxcored (ensure that you are in the fx-core folder):

make go.sum
make install

3. Cross reference the latest commit hash to the commit in our official github page:

fxcored version

4. Download genesis (copy and run each line, line by line)

wget https://raw.githubusercontent.com/FunctionX/fx-core/release/v3.1.x/public/mainnet/genesis.json -O ~/.fxcore/config/genesis.json
wget https://raw.githubusercontent.com/FunctionX/fx-core/release/v3.1.x/public/mainnet/config.toml -O ~/.fxcore/config/config.toml
wget https://raw.githubusercontent.com/FunctionX/fx-core/release/v3.1.x/public/mainnet/app.toml -O ~/.fxcore/config/app.toml

5. Restart the node:

sudo systemctl restart fxcored

6. Check whether the node is participating in consensus:

cat $HOME/.fxcore/data/priv_validator_state.json

It should return something similar to the following:

You can cross reference the block "height" field with that of the FunctionX Explorer

  "height": "347450",
  "round": 0,
  "step": 3,

Additional features of client.toml

Users can specify the configuration of certain commands in the configuration file client.toml

Configure priority --flag> client.toml(default)

A point to note is that client.toml configuration are for fxcored CLI, while app.toml and config.toml are configurations for the node.

keydefaultOptional valuedescription



Chain ID-used when signing transactions




Keys storage method os: stored in the system password, file: file, specified password encryption, test: file, no encryption




Output format when querying



Node address to be called




Broadcast transaction mode

Modify client.toml command fxcored config $key $value (example):

fxcored config chain-id fxcore

fxcored config keyring-backend test

fxcored config output json

fxcored config node "tcp://"

fxcored config broadcast-mode block

Last updated