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.
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.
The validator’s journey begins with a deposit transaction on the Execution Layer to the deposit contract at 0x4242424242424242424242424242424242424242. The deposit emits a custom deposit event.
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.
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.
-
No Verification Delay: On the first deposit, the validator’s signature is fully verified (similar to ETH2), but deposits are not assessed until end of epoch. Subsequent deposits simply increase the validator’s balance (no additional signature verification is done).
-
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. Subsequent deposits simply increase the validator’s balance.
-
Per-block deposit cap
Up to 8192 deposits can land in a single block. With ~45,000 gas per deposit and a 30M gas block limit, the cap is unreachable in practice.
After remaining in the Deposited state for 1 epoch, the validator automatically moves to the Eligible state and becomes eligible for activation.
2. Eligible
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).
3. Active
After spending 1 epoch in the Eligible state (say at N+1), the validator is marked Active at the start of epoch N+2 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.
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.
4. Exited
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:
- Larger Effective Balance
- If Equal Effective Balance, a lower-order pubKey (alphabetically).
When the validator is evicted from the validator set, it is marked Exited.
5. Withdrawn
Once the validator is marked Exited (say at epoch M), its funds are fully withdrawn at epoch M + 256 on mainnet (M + 32 on Bepolia). 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.
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.
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:
- Deposited → 1 epoch → Eligible → 1 epoch → Active
- Potential forced exit due to the validator set cap (69) → Exited → 256 (mainnet) / 32 (Bepolia) → Withdrawn
- Deposited → 1 epoch → Eligible → 1 epoch → Exited due to the validator set cap (69) + balance too low → 256 (mainnet) / 32 (Bepolia) → 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.
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.
For ongoing operational guides, see the Being a Validator section:
