Configure companion processes

Axelar validators need two companion processes called vald and tofnd.

Download binaries and initialize configuration

Similar to Node configuration, run setup-validator.sh to download and configure vald and tofnd binaries. In the axelerate-community (opens in a new tab) repo do:

./scripts/setup-validator.sh -n [mainnet|testnet]

The binary tofnd is placed in your ${AXELARD_HOME}/bin directory. The binary vald is actually part of axelard.

Verifying Binaries

By default, the binary signatures are downloaded and the binary is verified using the axelardev (opens in a new tab) PGP key. To verify the binary manually, you can download the PGP signature and verify using the following commands:

curl https://keybase.io/axelardev/key.asc | gpg --import
gpg --verify [axelard_binary_signature_path] [axelard_binary_path]

On github the signatures are attached to the releases. To download the signatures from the axelar-releases AWS Bucket, you can add .asc to the end of the binary URL. For example, if the path of the binary is:

https://axelar-releases.s3.us-east-2.amazonaws.com/axelard/v0.26.0/axelard-darwin-arm64-v0.26.0

The path for the signature will be:

https://axelar-releases.s3.us-east-2.amazonaws.com/axelard/v0.26.0/axelard-darwin-arm64-v0.26.0.asc

Directory structure of a running validator

Later, after you've launched your companion processes and created your validator, your directory structure should look like:

.axelar
├── bin
│   ├── axelard -> /Users/gus/.axelar/bin/axelard-vx.y.z
│   ├── axelard-vx.y.z
│   ├── tofnd -> /Users/gus/.axelar/bin/tofnd-va.b.c
│   └── tofnd-va.b.c
├── config
│   ├── app.toml
│   ├── config.toml
│   ├── genesis.json
│   ├── node_key.json
│   ├── priv_validator_key.json
│   ├── priv_validator_state.json
│   └── seeds.toml
├── data
├── logs
├── tofnd
└── vald
    └── state.json

Relevant files:

• priv_validator_key.json, node_key.json : Created when you first launched your node as described in Basic node management.
• priv_validator_state.json : Last block height signed by the validator. This prevents double signing old blocks. If it’s content is {}, it’ll start signing from a synced node’s latest block
• vald/state.json : State file specifying the last block processed. If it’s not present, or is too old, vald starts from the latest block instead.