Berachain’s network relies on validator nodes and RPC nodes. Each can be configured as a full node or archive node.
Berachain follows a decoupled node architecture standard in modern Ethereum-equivalent networks. Every node consists of two separate software clients running in tandem: an execution client and a consensus client. Berachain supports any EVM execution client paired with BeaconKit, a consensus framework built by Berachain.
RPC vs Validator Nodes
Architecturally, RPC nodes and validator nodes are nearly identical. Both maintain a complete copy of the blockchain state and participate in peer-to-peer transaction gossip.
An RPC node can become a validator node by joining the Active Set through interaction with the BeaconDeposit contract by
meeting the $BERA stake requirements. To learn about the economics of becoming a validator,
see the Validator Lifecycle and the Be A Validator guides.
Client Separation
The separation of concerns between the two clients is strictly defined:
- Execution Client (e.g., Bera-Reth, Bera-Geth): Responsible for transaction execution, managing the Ethereum Virtual Machine (EVM) state, maintaining the state trie, and serving user-facing JSON-RPC requests (like
eth_call or eth_sendRawTransaction).
- Consensus Client (BeaconKit): Responsible for the Proof-of-Stake consensus mechanism, determining the chain’s head, managing the validator set, and proposing new blocks. It does not execute transactions, gossip transactions, or hold EVM state.
Because these are separate databases, “archival” status usually refers to the execution client retaining historical EVM state, whereas the consensus client manages its own independent pruning settings.
The Engine API and JWT
The execution and consensus clients must communicate continuously to keep the node synced. They do this over a local HTTP interface called the Engine API.
Because the Engine API allows the consensus client to command the execution client to build and execute blocks, this API must be highly secured. Communication is authenticated using a JSON Web Token (JWT) secret. Both clients must be configured to read the exact same jwt.hex file on disk to authorize communication.
Dual P2P Networks
Because the node is split into two clients, it participates in two entirely separate Peer-to-Peer (P2P) networks simultaneously:
- Execution P2P (devp2p): The execution client connects to other execution clients to gossip pending user transactions (the mempool).
- Consensus P2P (CometBFT): The consensus client connects to other consensus clients to gossip proposed blocks, validator attestations, and consensus votes.
For firewall and networking configurations, operators must ensure both P2P ports are open and publicly dialable. For more details on securing and optimizing these networks, see the Production Checklist.
Validator active set
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.
Berachain follows Proof-of-Stake (PoS) direct staking, which allows $BERA holders to directly stake their $BERA to a validator. However, note that if funds are withdrawn from a validator, currently all funds are returned to a single address: the validator’s Withdrawal Credentials Address.
This means that validators will have to communicate how they handle funds when a 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.
Staking pools
Validators can also operate staking pools, which enable liquid staking services for their communities. Staking pools use smart contracts to manage deposits and withdrawals, allowing stakers to receive liquid shares (stBERA) that automatically grow in value as rewards accumulate. Staking pools provide validators with a way to build and monetize their own community of stakers while offering stakers lower barriers to entry and flexible withdrawals. For information about setting up and operating staking pools, see the Staking Pools documentation.
Removed from active set
If a validator is removed from the active set, all $BERA staked to that validator will be returned to the validator’s Withdrawal Credentials Address, which is set when the validator makes their first deposit.
A validator can decide to become a validator 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 validator can never be re-activated.
Voluntary withdrawals
A Validator can withdraw all or part of their stake.
Validator block rewards and distribution
Block rewards are distributed as WBERA emissions at a fixed rate per block proposed.
The network does not distribute rewards automatically. You must distribute block rewards through the Distributor contract. Distribution must occur before 8,191 seconds have passed, or validators risk losing those rewards. 
