# Epoch change - Determine epoch leader
**URL:** https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879
**Category:** Developers
**Created:** [June 19, 2025, 9:52pm UTC](https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879 "2025-06-19T21:52:10Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@CryptoJaeger](https://forum.klever.org/u/CryptoJaeger)
#### Post date: [June 19, 2025, 9:52pm UTC](https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879/1 "2025-06-19T21:52:10Z")
How can I determine the leader of the epoch at the start of the epoch? ( I don´t mean the blockproducer)
I would prefer a solution via my own Node API.
---
### Author:  [@Pedro\_Henrique](https://forum.klever.org/u/Pedro_Henrique)
#### Post date: [June 20, 2025, 3:58pm UTC](https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879/2 "2025-06-20T15:58:37Z")
Hey @CryptoJaeger ! 👋
There is no specific **epoch leader** in the Klever Blockchain consensus model. Instead, the first block of a new epoch is produced by one of the validators from the **previous epoch’s validator set**. So if you’re trying to figure out who will produce that first block, you should look at the validator list **from the previous epoch** , right before the epoch transition.
---
### Author:  [@CryptoJaeger](https://forum.klever.org/u/CryptoJaeger)
#### Post date: [June 26, 2025, 8:49pm UTC](https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879/3 "2025-06-26T20:49:43Z")
@Pedro_Henrique @fbsobreira
Okay. There are some inconsistencies here that I would like to understand technically. If certain validators are jailed at the beginning of the epoch or in the epoch, then from time to time there is the phenomenon that all validators build up masses of ‘missed blocks’. Several words have already been provided, such as ‘epoch leader’ or ‘block production round leader’.
I would like to understand it and of course be able to determine it for Klever-Radar.
Many thanks in advance.
---
### Author:  [@Pedro\_Henrique](https://forum.klever.org/u/Pedro_Henrique)
#### Post date: [June 30, 2025, 10:54am UTC](https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879/4 "2025-06-30T10:54:17Z")
Hey @CryptoJaeger, sorry for the late response — thanks for your patience!
So first of all i would like to clarify how the consensus structure works in Klever Blockchain. The time hierarchy is organized as follows:
**Epoch** → **Slot** → **Subslot**
- **Epoch:** A longer period where validator sets are defined
- **Slot:** The basic time unit for block production
- **Subslot:** Divisions within each slot for different consensus jobs
At the **epoch level** , we select which validators will participate in consensus. At the **slot level** , we determine who will be the leader from those selected validators. There is **no Epoch Leader** , but there is the **Slot Leader** - the function of that validator is to **produce the block and sign it** , while the other validators’ function is to **sign the block for consensus**.
Each **slot** is divided into **subslots** where different phases of consensus happen:
- **Subslot 1:** Block proposal by the Slot Leader
- **Subslot 2:** Validation and signature collection
- **Subslot 3:** Block finalization and commitment
## Regarding the “Mass Missed Blocks” issue :
Sometimes, a validator selected as a Slot Leader starts failing to perform its duties — either due to being offline, malfunctioning, or other issues. As a result, the consensus jails this validator. However, since the validator set only changes at the epoch level, the jailed validator remains part of the validator pool for the entire epoch.
If that validator recovers and manages to successfully produce a valid block when selected again as Slot Leader, they can return to active participation in the consensus.
But if they do not recover, they may still be selected again — and continue failing to produce blocks, while accumulating missing signatures throughout the epoch.
What we suspect is happening is this:
**KleverRada** r might be counting every instance of a missing signature as a **“missed block”** , even in cases where the jailed validator was not the **Slot Leader** , but simply failed to sign the block.
This could lead to an inflated count of missed blocks, since only **Slot Leaders** can actually “miss” a block.
To confirm that and help us better understand what’s being reported, could you please clarify **how KleverRadar is retrieving the “missed blocks” information**?
---
### Author:  [@CryptoJaeger](https://forum.klever.org/u/CryptoJaeger)
#### Post date: [July 3, 2025, 8:13pm UTC](https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879/5 "2025-07-03T20:13:20Z")
@Pedro_Henrique
Hi and thank you very much for your detailed information.
Klever-Radar removes the jailed validator from the consensus list (as does the validator peerslist: [https://node.mainnet.klever.org/validator/peers](https://node.mainnet.klever.org/validator/peers) ). Radar determines the ‘Missed Blocks’ based on missing signatures for a block.
Just to understand:
- A validator that has been jailed can no longer start working in the same epoch, right? It changes to the status → Eligible at the epoch change
This phenomenon only occurs with some actively selected validators that have been jailed, i.e. all validators have missing signatures.
Now the question would be, does the jails validator remain in the consensus list or does it have to be removed? (so far it has been removed from the list)
---
### Author:  [@Pedro\_Henrique](https://forum.klever.org/u/Pedro_Henrique)
#### Post date: [July 11, 2025, 2:17pm UTC](https://forum.klever.org/t/epoch-change-determine-epoch-leader/3879/6 "2025-07-11T14:17:38Z")
**Hey @CryptoJaeger!**
When an elected validator gets jailed, it remains part of the consensus until the end of the current epoch. It can still be selected as a Slot Leader and may produce blocks during that epoch if it manages to recover. However, at the next epoch change, the validator will be removed from the consensus list and will remain jailed until an **Unjail** transaction is submitted.