<p>Try the 2 commands below to see if they give you the info that you need.</p>
<p>1 - Cardano version 1.34.0 (and 1.34.1?) has a bug that does not show KES calculations correctly - this should be fixed in 1.35.0. Below is from 1.34.1 after I did a KES rotation earlier today.</p>
<pre><code>$cardano-cli query kes-period-info --mainnet --op-cert-file op.cert

✓ The operational certificate counter agrees with the node protocol state counter
✓ Operational certificate's kes period is within the correct KES period interval
{
    &quot;qKesNodeStateOperationalCertificateNumber&quot;: 14,
    &quot;qKesCurrentKesPeriod&quot;: 505,
    &quot;qKesOnDiskOperationalCertificateNumber&quot;: 15,
    &quot;qKesRemainingSlotsInKesPeriod&quot;: 6783509,
    &quot;qKesMaxKESEvolutions&quot;: 62,
    &quot;qKesKesKeyExpiry&quot;: &quot;2022-09-22T21:44:51Z&quot;,
    &quot;qKesEndKesInterval&quot;: 558,
    &quot;qKesStartKesInterval&quot;: 496,
    &quot;qKesSlotsPerKesPeriod&quot;: 129600
}
</code></pre>
<p>2 - Try using the localhost HTTP <code>metrics</code> details via CLI - note your port number may vary:</p>
<pre><code>$curl -s 127.0.0.1:12798/metrics | grep KES

cardano_node_metrics_operationalCertificateExpiryKESPeriod_int 567 
cardano_node_metrics_currentKESPeriod_int 505 
cardano_node_metrics_remainingKESPeriods_int 62 
cardano_node_metrics_operationalCertificateStartKESPeriod_int 505
</code></pre>

CC BY-SA 4.0
2022-07-06T10:01:06.987Z
2022-07-06T10:01:06.987Z
MC_Brisbane - JUST Pool
<p>Things you can verify:</p>
<ul>
<li>Current opcert counter is higher than previous counter on chain in a block created by your pool (you can use dbsync or query a public instance) - you already saw in your previous thread that expected OCert for your node was 6). Starting Vasil fork, it is expected that - upon rotation, your opcert counter is higher by <em>exactly 1</em></li>
<li>Expiry date of KES  (can query EKG or also just check gLiveView).</li>
<li>Make sure your cert was derived using kes from your cold key using which pool was created.</li>
</ul>
<p>Once each of above is verified, it's simply a matter of waiting for your next block to get the proof/assurance. The above are pretty much the only checks you can perform.</p>

CC BY-SA 4.0
2022-03-31T08:24:07.563Z
What if you haven't done any blocks yet? Mine is currently up to 9, no blocks done, and the cert instantly expires.
Cyberience
CC BY-SA 4.0
2022-04-01T03:36:23.287Z
@Cyberience - "instantly expires" => That suggests you're likely not using right start period for KES (assuming you're verifying it correctly using right files and post node restart)
RdLrT
CC BY-SA 4.0
2021-06-20T08:45:13.433Z
2022-06-13T02:26:28.260Z
2022-06-13T02:26:28.260Z
RdLrT
<p>With reference to my previous question regarding <a href="https://cardano.stackexchange.com/questions/2051/invalid-kes-signature-ocert-but-gliveview-shows-kes-is-valid">inconsistent reading of KES validity</a> given by cardano-node and gLiveView, is there any way I could objectively verify KES validity without waiting for the next block?</p>

<stake-pool>
How to verify if KES is valid without needing to wait for the next minted block?
# How to verify if KES is valid without needing to wait for the next minted block?

(Asked by: username_0 on 2021-06-20)

With reference to my previous question regarding [inconsistent reading of KES validity](https://cardano.stackexchange.com/questions/2051/invalid-kes-signature-ocert-but-gliveview-shows-kes-is-valid) given by cardano-node and gLiveView, is there any way I could objectively verify KES validity without waiting for the next block?

**Tags:** stake-pool

---

## 2 answers

### Answer by username_2 on 2021-06-20. Score: 4 | Accepted answer

Things you can verify:

* Current opcert counter is higher than previous counter on chain in a block created by your pool (you can use dbsync or query a public instance) - you already saw in your previous thread that expected OCert for your node was 6). Starting Vasil fork, it is expected that - upon rotation, your opcert counter is higher by *exactly 1*
* Expiry date of KES (can query EKG or also just check gLiveView).
* Make sure your cert was derived using kes from your cold key using which pool was created.

Once each of above is verified, it's simply a matter of waiting for your next block to get the proof/assurance. The above are pretty much the only checks you can perform.

> **Comments:**
> **username_3**: What if you haven't done any blocks yet? Mine is currently up to 9, no blocks done, and the cert instantly expires.  
> **username_2**: @Cyberience - "instantly expires" => That suggests you're likely not using right start period for KES (assuming you're verifying it correctly using right files and post node restart)  

---

### Answer by username_1 on 2022-07-06. Score: 2

Try the 2 commands below to see if they give you the info that you need.
1 - Cardano version 1.34.0 (and 1.34.1?) has a bug that does not show KES calculations correctly - this should be fixed in 1.35.0. Below is from 1.34.1 after I did a KES rotation earlier today.
$cardano-cli query kes-period-info --mainnet --op-cert-file op.cert

✓ The operational certificate counter agrees with the node protocol state counter
✓ Operational certificate's kes period is within the correct KES period interval
{
    "qKesNodeStateOperationalCertificateNumber": 14,
    "qKesCurrentKesPeriod": 505,
    "qKesOnDiskOperationalCertificateNumber": 15,
    "qKesRemainingSlotsInKesPeriod": 6783509,
    "qKesMaxKESEvolutions": 62,
    "qKesKesKeyExpiry": "2022-09-22T21:44:51Z",
    "qKesEndKesInterval": 558,
    "qKesStartKesInterval": 496,
    "qKesSlotsPerKesPeriod": 129600
}

2 - Try using the localhost HTTP metrics details via CLI - note your port number may vary:
$curl -s 127.0.0.1:12798/metrics | grep KES

cardano_node_metrics_operationalCertificateExpiryKESPeriod_int 567 
cardano_node_metrics_currentKESPeriod_int 505 
cardano_node_metrics_remainingKESPeriods_int 62 
cardano_node_metrics_operationalCertificateStartKESPeriod_int 505


---

