Skip to main content

Documentation Index

Fetch the complete documentation index at: https://berachain-422fce37-feat-nodes-section-reno.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

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). 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 Active Set & Stake Requirements

The Active Set is the limited group of validators currently participating in the consensus layer and proposing blocks. The current limit of validators in the active set is 69. To enter the active set, you must meet the minimum stake requirements. This requirement depends on whether the active set is full:
  • If the active set is not full, the minimum stake requirement is 250,000 $BERA.
  • If the active set is full, the minimum stake requirement is 10,000 $BERA more than the amount staked by the last validator in the active set.
It can take up to 3 epochs (192 blocks per epoch) for deposits to be processed and for a validator to be included in the active set. For step-by-step instructions on spinning up a validator, see the Become a Validator guide.

Direct Staking & Withdrawal Addresses

Berachain follows Proof-of-Stake (PoS) direct staking, which allows $BERA holders to directly stake their $BERA to a validator. When a validator makes their first deposit, they define a Withdrawal Credentials Address. If funds are withdrawn from a validator, or if the validator is evicted from the active set, all funds are returned to this single address. This means that validators must communicate clearly with their delegators about how they will handle and manually return funds if the validator is removed from the active set.
Avoid staking to validators without knowing how they handle funds when a validator is removed from the active set.

Lifecycle States

The validator lifecycle flows through five main states:

1. Deposited

The validator’s journey begins with a deposit transaction on the Execution Layer (via the Deposit Contract). Once this transaction is successful, beacon-kit nodes capture it and process it for signature verification.
  • Verification Delay: It takes 2 ETH1 blocks from the event emission to verify the event on the Consensus Layer.
  • Signature Verification: On the first deposit, the validator’s signature is fully verified. Subsequent deposits simply increase the validator’s balance.

2. Eligible

After remaining in the Deposited state for 1 epoch (192 blocks), the system automatically marks the validator as EligibleForActivationQueue. The validator remains in this state for 1 epoch.

3. Active

After spending 1 epoch in the Eligible state, the validator is marked Active and joins the Active Set (provided the 69-validator limit is not exceeded, or if the validator has a higher priority than an existing validator). A validator remains active indefinitely until it is forced out by a validator with a higher stake, or until it voluntarily withdraws its stake.

4. Exited

A validator is evicted from the set and marked Exited 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).

5. Withdrawn

Once the validator is marked Exited, its funds are fully withdrawn after a delay of 1 epoch. Because BeaconKit does not currently enforce a cap on validator churn, this finalizes the validator’s lifecycle and returns all $BERA to the Withdrawal Credentials Address. A validator can decide to become active again, but will need to generate new CometBFT validator keys and start the deposit process again as if they were a new validator.
Staking with a previously-used CometBFT identity — a validator that was removed from the active set — will result in the funds being returned to that validator’s withdrawal address at the end of the current epoch. The old identity can never be re-activated.

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.

Block Rewards & Distribution

Once active, validators receive block rewards for proposing blocks. Block rewards are in the form of $BGT, with a base reward of 0.4 $BGT per block proposed. The network distributes block rewards automatically through the Distributor contract. Validators no longer need to manually trigger this distribution. w For ongoing operational guides, see the Being a Validator section: