Gonka Host Voting Guide

You can find the minimum and recommended hardware specifications clearly outlined in the Hardware section. Review this section to ensure your hardware meets the requirements for effective contribution.

To restore a Network Node in the future, it will be sufficient to back up:

• cold key — most important, everything else can be rotated
• secrets from tmkms: .tmkms/secrets/
• keyring from .inference: .inference/keyring-file/
• node key: .inference/config/node_key.json
• password for warm key: KEYRING_PASSWORD

Your validator has been jailed because it signed fewer than 50 blocks out of the last 100 blocks (the requirement counts the total number of signed blocks in that window, not consecutive ones). This means your node was temporarily excluded (about 15 minutes) from block production to protect network stability.

Common Reasons:

• Consensus Key Mismatch: The consensus key used by your node may differ from the one registered on-chain.
• Unstable Network Connection: Network instability can prevent your node from reaching consensus.

Rewards: Even if your node is jailed, you will continue to receive most of the rewards as a Host as long as it remains active in inference.

To resume normal operation, unjail your validator once the issue is resolved. Use your cold key to submit the unjail transaction:

export NODE_URL=http://<NODE_URL>:<port>
./inferenced tx slashing unjail   --from <cold_key_name>   --keyring-backend file   --chain-id gonka-mainnet   --gas auto   --gas-adjustment 1.5   --fees 200000ngonka   --node $NODE_URL/chain-rpc/

Check unjail status (should show jailed: false):

./inferenced query staking delegator-validators   <cold_key_addr>   --node $NODE_URL/chain-rpc/

1) Disable each ML Node:

curl -X POST http://localhost:9200/admin/v1/nodes/<id>/disable

2) Wait for Stop: Nodes not scheduled to serve inference during the next Proof-of-Compute (PoC) will automatically stop. Active nodes remain active for one more epoch. Once a node is marked as disabled, it is safe to power off the MLNode server.

3) Shut down Network Node:

Recommended backups: .dapi/api-config.yaml, .dapi/gonka.db, .inference/config/, .inference/keyring-file/, .tmkms/

The chain does not verify real hardware. It only validates the total participant weight, which is the sole value used for weight distribution and reward calculation.

Any breakdown of this weight across ML Nodes is purely informational. The API service attempts to auto-detect hardware, but this can be overridden.

Regardless of configuration, rewards rely solely on the Host total weight.

Point it to another one by updating variables in config.env:

• SEED_API_URL — Choose any from the genesis list (e.g., http://node2.gonka.ai:8000)
• SEED_NODE_RPC_URL — Use the same host but port 26657
• SEED_NODE_P2P_URL — Query the node status to find the P2P port

export SEED_NODE_P2P_URL=tcp://node3.gonka.ai:5000

Option 1: Manual Edit (If initialized)

Edit .inference/config/config.toml:

seeds = "<node1_id>@<node1_ip>:<port>,..."

To view known peers:

curl http://47.236.26.199:8000/chain-rpc/net_info | jq

Option 2: Reinitialize (Auto-apply from env)

source config.env
docker compose down node
sudo rm -rf .inference/data/ .inference/.node_initialized
sudo mkdir -p .inference/data/

You can find a dedicated section on Key Management in the documentation. It outlines the procedures and best practices for securely managing your application's keys on the network.

If using tmkms, delete the .tmkms folder and restart it to auto-generate a new key. Then register it:

./inferenced tx inference submit-new-participant   <PUBLIC_URL>   --validator-key <CONSENSUS_KEY>   --keyring-backend file   --unordered   --from <COLD_KEY_NAME>   --timeout-duration 1m   --node http://<node-url>/chain-rpc/   --chain-id gonka-mainnet

1. Back up the cold key locally
2. Stop API: docker compose down api --no-deps
3. Set KEY_NAME in config.env
4. Recreate warm key inside container:

source config.env && docker compose run --rm --no-deps -it api /bin/sh
printf '%s
%s
' "$KEYRING_PASSWORD" "$KEYRING_PASSWORD" |   inferenced keys add "$KEY_NAME" --keyring-backend file

5. Grant permissions using cold key (locally)

6. Start API: docker compose up -d

Simulate PoC on an ML Node to verify readiness. Pause the api node first:

docker pause api

Transition node to stopped state:

curl -X POST "http://<ml-node-host>:<port>/api/v1/stop"   -H "Content-Type: application/json"

Send generation request (payload available in docs):

curl -X POST "http://<ml-node-host>:<port>/api/v1/pow/init/generate" ...

If successful, you will see logs creating GPU groups and sending generated batches.

Cosmovisor creates a full backup in the .inference state folder during updates (approx. 150 GB as of Nov 2025). It is recommended to have 250+ GB of free disk space.

You can safely remove old backups:

rm -rf .inference/data-backup-*

You can pre-download binaries to:

• .dapi/cosmovisor/upgrades/v0.2.5/bin
• .inference/cosmovisor/upgrades/v0.2.5/bin

Make them executable and verify their checksums before the upgrade triggers. See documentation for full script.

NATS stores messages indefinitely by default. Install nats-cli and configure a 24-hour TTL for streams:

nats stream info txs_to_send --server localhost:<port>
nats stream info txs_to_observe --server localhost:<port>

Use the submit-new-participant transaction. This updates the InferenceURL without requiring re-registration.

Note: The chain updates the ActiveParticipants list only at the next epoch, so keep both URLs active if possible to avoid disruption.

./inferenced tx inference submit-new-participant <PUBLIC_URL> ...

application.db stores state history. You can set pruning parameters in .inference/config/app.toml:

pruning-keep-recent = "1000"

To reset the DB, you can resync from a snapshot or use a fresh state sync.

This was due to low gas settings. Fix is in release v0.2.5-post7.

Download the new binary, restart api, and force recover the claim:

curl -X POST http://localhost:9200/admin/v1/claim-reward/recover   -H "Content-Type: application/json"   -d '{"force_claim": true, "epoch_id": 106}'

This is not a critical error. It indicates your node hasn't been assigned a model yet, likely because it hasn't participated in a Sprint or received Voting Power.

Once you pass PoC (every ~24h), this log should disappear.