How to Update Consensus Key and Inference URL

When Do You Need This?

You need to update your consensus key in these situations:

  1. Deleted consensus key - If you accidentally deleted your .tmkms folder or consensus key
  2. Migrating to a new Network Node - When you want to use your account key with a new network node (ensure your old cluster is completely shut down first)
  3. Changed IP address - If you just want to update your network node’s IP address, follow this guide and update only the inference URL

Step 1: Check If You Need an Update

Run the setup report command on your server:

curl http://localhost:9200/admin/v1/setup/report | jq

Look for an issue like this in the output:

"issues": [
  "Consensus key mismatch: local=fX.....g0=, registered=fx....Y="
]

If you see this message, it means:

  • local= Your current consensus key on the network node
  • registered= The consensus key registered on-chain

They don’t match, so you need to update the on-chain key.

Step 2: Get Your New Consensus Key

Your new consensus key is shown in the issue description (local= value). You can also fetch it with any of these commands:

Option 1: From node status

docker compose exec node wget -qO- http://localhost:26657/status 2>/dev/null | jq '.result.validator_info.pub_key.value'

Option 2: From tmkms

docker compose run --rm --entrypoint /bin/sh tmkms -c "tmkms-pubkey"

Option 3: From setup report

curl -s http://localhost:9200/admin/v1/setup/report | jq '.checks[] | select(.id == "consensus_key_match")'

All three commands should return the same key

Step 3: Update Your inferenced Binary (Local Machine)

:warning: Important: Make sure your local inferenced binary is up to date, otherwise the transaction may time out or fail.

Check your current version:

./inferenced version

Step 4: Submit the Update Transaction

:warning: This command must be run from your LOCAL machine where you have your cold key (account key), NOT from your server.

./inferenced tx inference submit-new-participant \
    http://<YOUR.NETWORK.NODE.IP>:8000 \
    --validator-key <NEW_CONSENSUS_KEY> \
    --keyring-backend file \
    --unordered \
    --from <GONKA_ACCOUNT_KEY_NAME> \
    --timeout-duration 1m \
    --node http://node1.gonka.ai:8000/chain-rpc/ \
    --chain-id gonka-mainnet

Replace the following:

  • <YOUR.NETWORK.NODE.IP> - Your network node’s external IP address
    • Example: http://124.123.122.121:8000
  • <NEW_CONSENSUS_KEY> - The consensus key you fetched in Step 2
    • Example: fX...0=
  • <GONKA_ACCOUNT_KEY_NAME> - The name of your account key in the keyring
    • Example: gonka-account-key

You will be prompted to enter your keyring password.

Step 5: Verify the Update

Quick Check: Setup Report

The consensus key mismatch issue should disappear within a few seconds:

curl http://localhost:9200/admin/v1/setup/report | jq

Look for the "issues": [] to be empty or the consensus key mismatch to be gone.

Detailed Check: On-Chain Participant Info

Check your participant details on-chain (replace the address at the end with your account address):

http://node1.gonka.ai:8000/chain-api/productscience/inference/inference/participant/gonka1...

Or use curl:

curl http://node1.gonka.ai:8000/chain-api/productscience/inference/inference/participant/gonka1... | jq

Verify:

  • validator_key: field shows your new consensus key
  • inference_url: field shows your new network node IP (if you updated it)

Troubleshooting

Transaction times out

  • Make sure your inferenced binary is updated to the latest version
  • Try using a different node URL: http://node2.gonka.ai:8000/chain-rpc/ or http://node3.gonka.ai:8000/chain-rpc/

“Consensus key mismatch” issue persists

  • Wait a few minutes and check again
  • Verify you used the correct consensus key from Step 2
  • Make sure the transaction was successful (check for transaction hash in the output)

Can’t access cold key

  • Make sure you’re running the command on the machine where your cold key is stored
  • Verify the keyring backend matches your setup (usually file)
  • Check that <GONKA_ACCOUNT_KEY_NAME> matches the actual key name

Important Notes

:warning: Before migrating to a new cluster:

  • Make sure your old cluster is completely shut down
  • Never run two network nodes with the same account key simultaneously

:information_source: URL Changes:

  • When you update your inference URL, the new URL becomes active immediately for new inference requests
  • However, the URL in ActiveParticipants won’t update until the next epoch
  • It’s recommended to keep both old and new URLs operational until the next epoch completes