Ethereum Beacon Chain Data: Index Blobs, Validators, and Consensus
Index Ethereum consensus-layer data: EIP-4844 blobs with KZG commitments, proposers, attestations, withdrawals, and deposits, delivered to your own database before nodes prune them.
The Beacon Chain is Ethereum's consensus layer. Every slot, a validator proposes a beacon block that carries attestations, deposits, exits, withdrawals, and the execution payload that becomes the familiar Ethereum block. Since EIP-4844, beacon blocks also commit to blobs: large data packets that rollups post for cheap data availability, verified with KZG commitments and kept outside the EVM. You can read how blobs work at ethereum.org.
Blobs are the data problem. They are not accessible to the EVM, they are not in execution-layer RPC responses, and consensus nodes prune them after roughly 18 days. Indexing Co delivers beacon blocks with their blobs attached, runs your transform over them server-side, and lands the rows in your own PostgreSQL, warehouse, or webhook. For contract events and transactions, see the Ethereum page. This page covers what the execution layer does not show.
Why Beacon Chain data is hard
What Indexing Co delivers for the Beacon Chain
Stand up and maintain the whole stack yourself.
- Run a consensus client alongside an execution client, or rent beacon API access.
- Fetch beacon blocks and blobs per slot from the beacon API (/eth/v1/beacon/blobs since Fusaka), handling missed slots.
- Capture blobs continuously before the pruning window drops them.
- Build retries, storage, and real-time delivery from scratch.
One pipeline sources, shapes, and delivers consensus data to your store.
- Beacon blocks with blobs, KZG commitments, and proofs attached.
- Shaped by your JavaScript transform into the schema you define.
- Lands in your PostgreSQL, BigQuery, warehouse, or webhook.
- Runs next to your Ethereum execution pipeline. No beacon node.
What you can index
| Consensus data type | For example |
|---|---|
| EIP-4844 blobs | Blob index, raw blob data, KZG commitment and proof per blob |
| Block header | Slot, proposer index, parent and state roots |
| Attestations and slashings | Attestation data, aggregation bits, proposer and attester slashings |
| Validator lifecycle | Deposits, voluntary exits, BLS to execution changes, execution requests |
| Execution payload | Execution block number and hash, withdrawals, blob gas used, excess blob gas |
A transform, not a subgraph
You write the transform in JavaScript, not AssemblyScript, and change it without re-indexing from slot zero. Indexing Co runs your function over each beacon block server-side. This one returns a row per blob with its KZG commitment and the blob gas context from the execution payload.
// Indexing Co transform: one row per EIP-4844 blob in a beacon block
function transform(block) {
const results = [];
const payload = block.body?.execution_payload || {};
for (const blob of block.blobs || []) {
results.push({
chain: block._network,
slot: Number(block.slot),
proposer_index: Number(block.proposer_index),
execution_block_number: Number(payload.block_number),
blob_index: Number(blob.index),
kzg_commitment: blob.kzg_commitment,
kzg_proof: blob.kzg_proof,
blob_bytes: (blob.blob.length - 2) / 2, // hex string, 0x-prefixed
blob_gas_used: payload.blob_gas_used,
excess_blob_gas: payload.excess_blob_gas,
});
}
return results;
}
The Beacon Chain with Indexing Co
You want full control of node infrastructure and have the team to operate a consensus client, pull blobs every slot before they are pruned, and build storage and delivery in-house.
You want blobs, proposers, attestations, and withdrawals delivered to your own database alongside your Ethereum execution data, with no beacon node to run.
Related Reading
- Ethereum Data Infrastructure
- Base Data Infrastructure
- Starknet Data Infrastructure
- Indexing Co vs Building Your Own
FAQ
How is this different from the Ethereum page?
The Ethereum page covers execution-layer data: contract events, token transfers, and transactions. This network covers the consensus layer: beacon blocks by slot, blobs, attestations, validator deposits, exits, and withdrawals.
Can I get blobs older than the pruning window?
Consensus nodes prune blobs after about 18 days. Run a pipeline in real time and every blob lands in your own store permanently. For historical blob coverage beyond that window, talk to us about your start slot.
Does Indexing Co decode blob contents?
No. Blobs are opaque data posted by rollups, delivered as hex with their KZG commitment and proof. What a blob means depends on the rollup that posted it, so decoding is up to your transform or downstream code.
Are withdrawals and deposits included?
Yes. Withdrawals arrive in the execution payload with validator index, address, and amount. Deposits, voluntary exits, and execution requests are in the block body.
Where does the Beacon Chain data go?
Into your own destination: PostgreSQL, BigQuery, a warehouse, or a webhook. You define the output schema and own the storage.
Get Started
Index Ethereum consensus data in minutes. Set up your first blob or validator pipeline without running a beacon node.