After performing an upgrade on a remote node that includes a new pallet in my runtime, I attempted to sync a local node with the remote one, but I encountered the following error:

Bootnode with peer id `12D..` is on a different chain (our genesis: 0x40b7…db79 theirs: 0xa82a…1bc2)

I have been using the same chain spec JSON file for both nodes. To test this, I compiled both the remote and local codebases, the latter of which includes the new pallet's code. I ran both nodes using the same chain spec JSON file. However, as I stated earlier, I encountered an error in the second case.

I'm unable to understand why this is occurring when I'm using the same chain spec for both nodes, which should mean they have the same genesis. Am I wrong or missing something here?

How can I debug this issue?


1 Answer 1


Bootnode with peer id 12D.. is on a different chain (our genesis: 0x40b7…db79 theirs: 0xa82a…1bc2)

The above error occurs when you are trying to connect to your node with a node that has a different peerId that you have provided in --bootnodes command. So just check it once and also double check that you are giving the right IP address .

./target/release/node-template \
  --base-path /tmp/node02 \
  --chain ./customSpecRaw.json \
  --port 30334 \
  --ws-port 9946 \
  --rpc-port 9934 \
  --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" \
  --validator \
  --rpc-methods Unsafe \
  --name MyNode02 \
  --bootnodes /ip4/ \

The other scenario in which this error comes is when you haven't deleted the chain data of a previously, so what you need to do is purge the chain and start it again. You can use the below commnand to purge the chain.

./target/release/substrate purge-chain --base-path /tmp/node02 --chain staging -y
  • thanks for the answer. I'm using the same bootnode when running both binary versions, and it fails only once, as I've already described. I assume that if the bootnode was incorrect, both binary versions would fail with the same error, am I wrong?. In reality, I'm only running one node within the parachain, which I've verified is the correct one. As I've just mentioned, the parachain is running only one node, so purging it would result in the loss of all the state.
    – magecnion
    Jul 1, 2023 at 16:18
  • @magecnion can you edit your answer and tell how to reproduce this error, in case purging the chain I told you to purge the data of local chain not remote chain, when it connects to remote chain it will automatically sync with it. Jul 3, 2023 at 4:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.