Skip to main content

Documentation Index

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

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

BeaconKit consensus layer banner
BeaconKit is both a consensus client and a framework for building EVM chains. BeaconKit leverages CometBFT for its consensus algorithm, wrapped to interface with any EVM-compatible execution environment. As a consensus client, it allows the network (an EVM blockchain like Berachain) to reach agreement based on the data provided by the execution client. By conforming to Eth2 modularity, which separates consensus and execution, BeaconKit can leverage all the benefits that come with EVM execution clients. It achieves this by adhering to the Engine API, a JSON-RPC API that enables communication between consensus and execution clients.

​
Benefits

Some of the key benefits that come with BeaconKit:
  1. Eth2 modularity - Adheres to separation of execution and consensus with communication via Engine API
  2. Promotes execution client diversity - Any EVM execution upgrades can be supported out of the box, avoiding the need to run and maintain a custom forked EVM execution client to work with the chain
  3. CometBFT - Leverages a trusted consensus algorithm
  4. Instant finality - Achieves Single Slot Finality / Instant Finality, compared to Ethereum’s finality of ~13 minutes
  5. Leverages EVM tooling - The majority of all EVM tooling is supported
  6. Modular - BeaconKit is also a modular framework that can allow for the potential implementation of a custom block builder, rollup, data availability layer, and more
Comparison of Berachain BeaconKit architecture versus Ethereum

​
Deposit processing

BeaconKit consumes deposits directly from the execution payload’s request list (EIP-6110), one block at a time. Each EL block that includes deposit transactions surfaces them as a custom Deposit(bytes,bytes,uint64,bytes,uint64) event from the deposit contract; the CL parses that event into a 192-byte deposit request and applies it in the same block. There is no follow distance, no pre-fork queue, and no per-epoch processing window — once the EL block is finalized, the deposit is reflected in validator state. The wire formats and parser are documented in the EIP-6110 deposits specification.

​
EVM inflation parameters

The CL chain spec carries the per-block inflation address and amount that the consensus layer mints to as a withdrawal each block. The Fulu fork introduces two new fields on the chain spec — EVMInflationAddressFulu and EVMInflationPerBlockFulu.