Skip to main content

​
Overview

A validator in Berachain is a participant responsible for proposing and attesting to new blocks, helping secure the network and maintain consensus. Validators stake a required amount of the network’s native token ($BERA) as collateral, which serves both as an economic incentive to behave honestly and as a mechanism for penalizing malicious behavior. Validators can operate independently with direct staking, or they can operate staking pools that allow community members to stake BERA through smart contracts and receive liquid shares (stBERA). Staking pools follow the same validator lifecycle described in this document. For information about operating staking pools, see the Staking Pools documentation. Validators have several key responsibilities:
  • Proposing new blocks when selected
  • Attesting to blocks proposed by other validators
  • Participating in consensus by voting on the canonical chain
  • Maintaining network security through their staked tokens
The Validator’s Voting Power is the amount of $BERA they have deposited, rounded down to the nearest 10,000 BERA. Their Voting Power, as a proportion of the total Voting Power among all validators, is their probability of being selected to propose a block.
Diagram showing the Berachain validator lifecycle states: Deposited, Eligible, Active, Exited, and Withdrawn
The labeled states are as follows:
  • Deposited
    Deposit event captured by Beacon-kit and deposit message signature is verified.
  • Eligible
    Validator has been marked as EligibleForActivationQueue.
  • Active
    The validator is marked as Active after 1 epoch from the Eligible state. Currently, the Active Set consists of 69 Validators, which is the number of Validators that can propose blocks.
  • Exited
    The validator is marked for exit if the ValidatorSetCap limit is hit and the validator has the lowest effective balance or a lower-order pubKey if it has the same effective balance as another validator.
  • Withdrawn
    Once the validator is marked as exited, after a delay of 1 epoch, validator funds are fully withdrawn. All $BERA staked to a Validator is returned to the Validator’s Withdrawal Credentials Address.

​
Deposited state

The validator’s journey begins with a deposit transaction on the Execution Layer (via the Deposit Contract). Once this deposit transaction is successful and emits an event, beacon-kit nodes capture it and process it for signature verification. The initial deposit transaction establishes a connection between a validator’s Consensus Layer identity and its Execution Layer identity and decides the withdrawal address for the $BERA stake.
  • Verification Delay
    It takes 2 ETH1 blocks (on the EVM layer) from the event emission to verify the event on the Consensus Layer. If the deposit event is processed at epoch N, the validator is then considered in the Deposited state, provided the validator’s balance equals (or exceeds) the minimum required for staking.
  • Minimum Requirement
    A total of 250,000 BERA is required for a validator to reach the Deposited state. (Multiple deposits can accumulate to this amount.)
  • Signature Verification
    • On the first deposit, the validator’s signature is fully verified (similar to ETH2).
    • Subsequent deposits simply increase the validator’s balance (no additional signature verification is done).
After remaining in the Deposited state for 1 epoch, the validator automatically moves to the Eligible state and becomes eligible for activation.

​
Eligible state

Once the validator enters the Deposited state at epoch N, the system marks it as EligibleForActivationQueue as soon as epoch N+1 starts. This is guaranteed because there is no cap on the activation queue size. The validator remains in this Eligible state for 1 epoch. Afterward, it is added to the Active set, provided the ValidatorSetCap is not exceeded, or if the validator is of higher priority (i.e., higher effective balance or lower-order pubKey among equals).

​
Active state

After spending 1 epoch in the Eligible state (say at N+1), the validator is marked Active at the start of epoch N+2. A validator remains active indefinitely until it is forced out by a validator with a higher stake or voluntarily exits. Once Active:
  • CometBFT Consensus will use the validator for block proposals, validations, and voting.
  • The higher a validator’s EffectiveBalance, the higher its voting power—and thus, the more frequently it will be polled for block proposals.

​
Exited state

A Validator may choose to exit by withdrawing their complete stake. Otherwise, the only reason for a validator to be evicted from the set (and have its funds returned) is if the ValidatorSetCap is reached and another validator with a higher priority enters. Higher priority is determined by:
  1. Larger Effective Balance
  2. If Equal Effective Balance, a lower-order pubKey (alphabetically).
When the validator is evicted from the validator set, it is marked Exited.

​
Withdrawn state

Once the validator is marked Exited (say at epoch M), its funds are fully withdrawn at epoch M+1. Because BeaconKit does not currently enforce a cap on validator churn, this finalizes the validator’s lifecycle.

​
Extended validator lifecycle

Putting it all together, the following diagram shows the complete Berachain validator lifecycle:
  1. Deposited → 1 epoch → Eligible → 1 epoch → Active
  2. Potential forced exit due to ValidatorSetCap → Exited → 1 epoch → Withdrawn
  3. Deposited → 1 epoch → Eligible → 1 epoch → Exited due to ValidatorSetCap + balance too low → 1 epoch → Withdrawn
Extended validator lifecycle diagram showing all state transitions including forced exits
Note that the system processes state transitions via a queue, on a FIFO basis, with a cap on the number of transitions in each state to limit excessive churn in the validator set.