Validator Lifecycle

Validator states and transitions: Deposited, Eligible, Active, Exited, and Withdrawn; activation queue and stake requirements.

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.

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 eligible for the activation queue.

• 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 validator set cap (69) 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 256 epochs on mainnet (32 on devnet), 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 eligible for the activation queue 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 validator set cap (69) 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 effective balance, 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 validator set cap (69) 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 + 256 on mainnet (M + 32 on devnet). Because BeaconKit does not currently enforce a cap on validator churn, this finalizes the validator’s lifecycle.

Effective balance and hysteresis

A validator’s voting power is its effective balance, the actual stake rounded down to a 10,000 BERA increment. Effective balance updates lazily: the consensus state only moves it at the turn of an epoch when actual balance crosses an asymmetric buffer around the next increment, which prevents minor balance fluctuations from churning voting power.

The buffer is asymmetric because protecting against unintentional drops matters more than keeping pace with top-ups:

• Downward buffer: 100 BERA. Actual balance must fall more than 100 BERA below an increment boundary before effective balance steps down to the next-lower increment.
• Upward buffer: 1,000 BERA (~110% of the 10,000 BERA increment). Actual balance must exceed an increment boundary by more than 1,000 BERA before effective balance steps up.

For example, a validator who wants to lift effective balance from 250,000 to 260,000 BERA needs an actual balance of 261,000 BERA: 260,000 BERA at the increment boundary plus 1,000 BERA over the upward buffer. The Increase validator stake guide walks through this.

These buffers are consensus chain spec parameters. See BRIP-0008 for the derivation.

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 the validator set cap (69) → Exited → 256 (mainnet) / 32 (devnet) → Withdrawn
3. Deposited → 1 epoch → Eligible → 1 epoch → Exited due to the validator set cap (69) + balance too low → 256 (mainnet) / 32 (devnet) → Withdrawn

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.