VRFKeyWrongVRFKeyOVERLAY, couldnt mint our block

Hello guys,

i am really sad. We couldnt mint our block today. Here is the error msg:

(HeaderProtocolError (HardForkValidationErrFromEra S (S (S (Z (WrapValidationErr {unwrapValidationErr = ChainTransitionError [OverlayFailure (VRFKeyWrongVRFKey)
(“failures”,Array [Object (fromList [(“kind”,String “VRFKeyWrongVRFKeyOVERLAY”)

As you have to know:

I think i did a mistake right at the beginng with the “cold-key” node.counter file. As i setup the stakepool we changed the ticker one time, next we changed the pledge and so on. At one time i think i used an “old” backup file of node.counter. At the moment it shows the next number will be 4. but we changed the pool infos 5 times :frowning:

What i did 4 now was: i updated our pool margin and updateted our kes rotation files again and got no errors. but is there a way to check if this could fix the problem or do i have now a fatal problem cause of the maybe wrong node.counter file ?

Ticker FFM01

Plzzz help :frowning:


Or may it possible to create a new cold.counter („delete“ the old) and then create a new node.cert … then do the pool registration process again and at last do the kes, vrf verification process again again ?

maybe related:

nearly the same problem. so i have to shut down the pool ? i don’t get it at the moment. is this node.counter file that important ?

also this:

cold.counter comes from cold key… but I dont know what happens if the cold.counter contains “wrong” number…

does the node.counter file has always the same entries or changes after rotate kes keys ?

yes, it is changes - but I dont know what happens if the counter has wrong value…

it looks like you are not able to produce blocks anymore. i think at one kes rotation update i used an backup node.counter file instead of latest one.

I am now also wondering: when you rotate your KES, a new counter file is created. Isn’t that always the right one with the right number? In other words would you not always fix this possible problem by just rotating your kes? Or will the newly created counter file also be wrong if the previous one is wrong?

yes thats what i thought. but it looks like that doesn’t work. and i think if i would try to setup a fresh node.cert (1st i would make a new kes pair, 2nd create new node.counter, node.skey and node.vkey, and 3rd make a vrf key pair, 4: reregister pool) that would neither fix the problem or can i connect my old poolid with the fresh certificates?

just an example node.counter 1 : 123 / node.counter 2 : 123456 / node.counter 3: 123789 / 456 are missing cause of an kes update with the wrong node.counter

So what would be the best way to confirm if your files are in order or not? and how to fix it?

that’s the question my friend. you can compare like losing the node.counter file relating to node.cert otherwise the node.counter file would not be necessary i think.

Could this work:

  1. I create a new kes.v and skey
  2. i delete my old node.counter and create a new node.v and skey and node.counter
  3. sign the new certs
  4. create a new vrf key pair
  5. update the pool and deleg cert with old stake and payment keys

should this clean the overlay error

Do not delete your node keys!
Just repeatedly run any command that increases node.counter value. Do it so many times until you are sure the counter value is higher than it was before you overwrote it from backup. Then it will work for you again.

1 Like

:blush: i won’t delete them but i am not sure this will work. because no one would need their node.counter file associated to the node.vkey then. to increase the counter i need to update the kes files again.

correct me if i am wrong but don’t the blockchain checks earlier vrfkeys, like is the previous hash deregistered correctly and the new one registered correctly.?

The node.counter is a security measure. If your node.cert is stolen, they can impersonate your pool. Luckily for you, you can generate a new node.cert (auromatically with higher counter value encoded inside). The network accepts the node.cert that has highest counter value and rejects all others.
Just run cardano-cli node issue-op-cert .... several times. You can watch the counter value increasing cat node.counter
When you are sure your counter value is high enough, take the node.cert and copy to BP.


Thanks @Triton-pool for the description about the purpose of node.counter

ok i will try this one. keep u update