Indexed Ethereum BeaconBlockchain Data

The Beacon Chain is the consensus layer of Ethereum, and it keeps a ledger of its own. It began producing blocks on 1 December 2020, ran alongside the execution chain for nearly two years, and took over ordering Ethereum’s blocks at the Merge in September 2022. Consensus runs under Gasper: Casper FFG supplies finality, LMD-GHOST supplies fork choice, and validators are assigned to twelve-second slots grouped into epochs of thirty-two. There is no virtual machine here and no contract state. The records are a validator registry keyed by index and BLS public key, attestations, block proposals, slashings, deposits, voluntary exits and, since the Shapella upgrade of April 2023, withdrawal payments. Balances are denominated in ETH but held against validator indices rather than twenty-byte addresses, and since the Pectra upgrade in 2025 a validator’s effective balance is no longer fixed at thirty-two ETH.

SonarX indexes the consensus layer’s own objects: beacon blocks and the slots they fill, the validator registry and the state transitions that move a validator through it, attestations and where they were included, deposits, exits, slashings, sync-committee duty and withdrawal payments. The same normalized model is used on every chain SonarX covers, so consensus records sit beside execution records and can be joined in one query.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Point-in-time balance tables can be enabled for Ethereum Beacon Chain on request.

The join key is the work. Consensus records identify a validator by index and by a BLS public key, execution records identify an account by a twenty-byte hash, and no beacon block carries the second. Tying a validator’s rewards back to whoever funded it means following the deposit that created it and the withdrawal credentials it was registered with. The volumes are lopsided too. A slot holds one block and tens of thousands of attestations, and those attestations are aggregated before inclusion, so participation per validator has to be expanded out of bitfields rather than read off a row.

Validator and reward accounting is the workload this dataset exists for: what a validator was owed per epoch, what it actually received, and where the gap came from. Staking operators restate that per customer, which means attributing each validator to the deposit that funded it and to the address its withdrawals land on. Penalty research is the second, because missed attestations, inactivity leaks and slashings are the record of how an operator and its client software behaved under stress, and none of it is visible from execution data. Withdrawal reconciliation is the third and crosses both layers by construction. Gnosis Beacon Chain presents the same split for a different network, and staking analytics is the solution area this work sits in across the chains SonarX indexes.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Consensus history is available now, and it is worth saying at the start whether execution records are in scope as well, since most questions here span both. 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.