Indexed Berachain BeaconBlockchain Data

This is the consensus layer of Berachain, running since that network’s 2025 mainnet launch. It is built with BeaconKit, which packages CometBFT with middleware that drives an otherwise standard Ethereum execution client through the engine interface, so the chain keeps EVM behavior on one side and Tendermint-style agreement on the other. Finality lands in the slot that proposed the block, which means there is nothing to reorganize afterwards. Validators are not registered here, though: a deposit is made to a contract on the execution chain, and the validator then moves through eligibility to the active set over epochs of 192 blocks. Voting power is the deposited BERA rounded down to the nearest ten thousand, the active set is capped at sixty-nine validators, and a proposer earns a base BGT emission for each block it produces.

SonarX indexes what this layer records: blocks and their slots, the validator registry and the states a validator passes through, deposits as they take effect, voting-power changes, proposals, exits and the withdrawal credentials funds return to. The same normalized model is used on every chain SonarX covers, so these records join execution activity on the same height.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request.

Every question about a validator here starts on the other layer. The deposit is an EVM transaction, the registry entry it creates is a consensus record, and the emission it later earns is paid by an execution-layer contract, so a single validator’s history is assembled from two datasets that share a height and nothing else. Voting power is the second catch: it is a rounded-down multiple of the stake rather than the stake itself, so using one figure where the other belongs misstates influence. Single-slot finality at least keeps ingestion simple, since a finalized slot never needs revising.

Validator economics is the first workload: what was deposited, what voting power that produced after rounding, how often the validator proposed, and what it earned as a result. Staking analytics is where that work sits across the networks SonarX indexes. Incentive attribution is the second and is specific to this network, since a proposer decides where its emission goes, so the consensus record of who proposed is the key to explaining vault rewards on the execution side. Set-composition research is the third, because a capped active set means entries force exits, and the churn is visible. Reward reconciliation is the fourth, for operators restating per-delegator outcomes. Berachain Testnet carries the same structure for integration work.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Say whether execution records are in scope, because on this network the interesting questions span both layers. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.