qKesNodeStateOperationalCertificateNumber "null"

While querying the kes-period-info for our node we noticed that the value for “qKesNodeStateOperationalCertificateNumber” is null. We have not minted a block yet and we understand that this number would go up if our node happens to mint one. Is null just stating that we haven’t minted a block yet? An error? Or have we messed up somewhere in the process? Thank you in advance for your time.

1 Like

Bump. Also curious. YYC has yet to mint a block and has

✓ Operational certificate’s KES period is within the correct KES period interval
✗ No blocks minted so far with the operational certificate at: /home/cardano/node/myPool.node.opcert
“qKesCurrentKesPeriod”: 534,
“qKesEndKesInterval”: 569,
“qKesKesKeyExpiry”: null,
“qKesMaxKESEvolutions”: 62,
“qKesNodeStateOperationalCertificateNumber”: null,
“qKesOnDiskOperationalCertificateNumber”: 3,
“qKesRemainingSlotsInKesPeriod”: 4480498,
“qKesSlotsPerKesPeriod”: 129600,
“qKesStartKesInterval”: 507

1 Like

Since there is only a number on the chain, when a block has been minted, null seems plausible.

If you still haven’t minted a block, when the Vasil hard fork finally happens, it might become a problem that qKesOnDiskOperationalCertificateNumber is 3. After Vasil, the difference between last KES used on-chain and the one on-disk is not allowed to be more than one. I don’t know if null is counted as 0 and your on-disk certificate has to have 1, then.

1 Like

With Vasil upgrade the qKesOnDiskOperationalCertificateNumber must be just one count higher than qKesNodeStateOperationalCertificateNumber value for your last block. If this value needs to be adjusted, there is a guide available (Coincashew Method):