Testnet upgrade: v1.4.7

Instructions for the testnet upgrade to axelar-core v1.4.7.

The release for the upgrade can be found here.

Upgrade height: 30546580. Proposal: #578. Upgrade time: ~12:00 UTC, 2026-05-19. See countdown.

The v1.4.7 release provides two Linux binaries:

  • Static binary (axelard-linux-amd64-v1.4.7-static)

    • Contains a statically linked libwasmvm
    • Does not require installing or configuring libwasmvm

  • Dynamically linked binary (axelard-linux-amd64-v1.4.7)

    • Requires libwasmvm v2.2.4 (same version as v1.3.x, no change if you already run the v1.3.x dynamic binary)
    • Must have the library directory on LD_LIBRARY_PATH

⚠️

axelard must be built with go-1.25 for this release (same as v1.3.x).

If using the static binary, no wasmvm setup is required.

If using the dynamic binary, keep libwasmvm v2.2.4 (libwasmvm.x86_64.so) on LD_LIBRARY_PATH.

The v1.4 upgrade is a consensus-breaking release. Highlights:

  • Removes the link-deposit protocol. The legacy non-GMP token-transfer paths (linked deposit addresses, direct token transfers) that were deprecated in v1.3.1 are now fully removed. Pending link-deposit state is cleaned up in the upgrade handler.
  • Bumps CosmWasm wasmd to v0.54.7.
  • Reduces maxBitmapSize in nexus maintainer state (32,768 → 1,024) to lower per-validator memory pressure.
  • CometBFT v0.38.23.
  • Vald correctness: reject votes on failed polls.

No CosmWasm contract migrations are required for this upgrade. No config.toml / app.toml changes are required relative to a node already running v1.3.x with the post-v1.3.0 settings (iavl-cache-size = 0, iavl-disable-fastnode = true, timeout_commit = 1s).

  1. If you’re a validator or have delegated to one, please vote for the upgrade proposal via:
Terminal window
axelard tx gov vote <PROPOSAL_ID> yes --from validator
  1. Wait for the proposed upgrade block. Your node will panic at that block height with a log: {"level":"error","module":"consensus","err":"UPGRADE \"v1.4\" NEEDED at height: <UPGRADE_HEIGHT>",.

Stop your node after chain halt:

Terminal window
pkill -f 'axelard start'
# Validators also need to stop vald/tofnd
pkill -f 'vald-start'
pkill -f tofnd
  1. Backup the state:
Terminal window
cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-1.4.7/.core/data

⚠️

⚠️ Important: If you backup the entire folder, ~/.axelar_testnet/.core, that’ll also include your private keys (inside config and keyring-file subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.

  1. Restart your axelard node with the new v1.4.7 build.

  2. If you’re a validator also restart vald with v1.4.7 and tofnd with v1.0.1 (unchanged from v1.3.x).

Terminal window
# in axelarate-community repo
git checkout main
git pull
KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n testnet -a v1.4.7
# For validators, restart vald/tofnd
KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n testnet -a v1.4.7 -q v1.0.1

For verifiers, refer to the matching ampd release notes under axelar-contract-deployments/releases/ampd for the version compatible with axelard v1.4.7. The ampd upgrade must be done after the axelard upgrade.

This is a state-machine-breaking upgrade. There is no in-place rollback to v1.3.x once your node has executed the v1.4 upgrade handler. The link-deposit removal and parameter changes are persisted to state. If rollback is required, restore from the pre-upgrade snapshot you took in step 3.

If you encounter a hash error, ensure you have libwasmvm v2.2.4:

https://github.com/CosmWasm/wasmvm/releases/download/v2.2.4/libwasmvm.x86_64.so

Before restarting your node:

  1. Make sure LD_LIBRARY_PATH includes the directory of libwasmvm (dynamic binary only).
  2. Docker users do not need to modify anything.

If you see the error undefined symbol: migrate_with_info, switch to the statically linked binary (axelard-linux-amd64-v1.4.7-static).

If you see the error app hash mismatch after the upgrade, verify all replicas in your fleet were swapped to v1.4.7 before the upgrade height. Mixed binaries across replicas after the upgrade height will fork.

Edit on GitHub