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
$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 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
$BERAmore than the amount staked by the last validator in the active set.
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.
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 asEligibleForActivationQueue. 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:- Larger Effective Balance
- 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.
Extended Validator Lifecycle
Putting it all together, the following diagram shows the complete Berachain validator lifecycle:- Deposited → 1 epoch → Eligible → 1 epoch → Active
- Potential forced exit due to ValidatorSetCap → Exited → 1 epoch → Withdrawn
- Deposited → 1 epoch → Eligible → 1 epoch → Exited due to ValidatorSetCap + balance too low → 1 epoch → Withdrawn

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: