Indexed BerachainBlockchain Data
Berachain is a Proof-of-Liquidity EVM Layer 1 where validators are bonded with BERA but the emissions they direct are paid in BGT, a non-transferable token earned by supplying liquidity.
How to query Berachain data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Berachain blockchain data with plain SQL from a live database inside your own Snowflake account, populated with the indexed chain dataset. There is no pipeline to build and no second copy to store. The same dataset ships as file dumps to your own object storage for lakes and warehouses that are not Snowflake.
- Full history as a Snowflake data-share
- File dumps to S3 or your own object storage
- Real-time delivery, current to chain tip
Used for:
- Analytics teams already on Snowflake that want Berachain data beside their existing tables
- Fund accounting and treasury reporting that reconciles against a fixed history
- Cross-chain questions answered in one SQL statement instead of one query per chain
- Loading Berachain history into BigQuery, Databricks, Redshift or a Spark lake
- Replacing a self-hosted indexer and the engineering time that keeps it running
- Serving one governed dataset to several desks without copying it per team
Kafka Streaming
Enabled on requestEvent stream
Consume Berachain activity as a continuous stream of normalized records, produced as the chain is indexed instead of polled for.
Used for:
- Trading and execution systems that act on Berachain activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Berachain wallet or protocol activity
- Feeding a stream processor that already reads from Kafka
- Keeping an internal store hot without waiting for a batch window
- Event-driven services that would otherwise poll on a timer
Curated Datasets
Available todayPurpose-built tables
Protocol-level Berachain datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- Staking
Used for:
- Position-level Berachain lending, swap and liquidity analysis
- Reward, delegation and validator reporting without rebuilding the model
- Token distribution, holder and payment-flow reporting
- Risk and exposure work that needs protocol state, not raw logs
- Skipping the decoding layer an in-house team would have to maintain
- Extending an existing Berachain share with a modelled slice
Balances
Available todayTables and REST
Read what a Berachain address held, either as it stands now or exactly as it stood at a past block or timestamp.
- Point-in-time balance tables, as at any block or timestamp — on request
- Real-time balances API for latest and historical balances
- Batch API for wallets, tokens and balances in bulk
Used for:
- Reconstructing Berachain portfolios and NAV as at a reporting date
- Audit and reconciliation work that has to be repeatable months later
- Wallet and portfolio products that render Berachain balances on page load
- Compliance checks that read one Berachain address at one block height
- Refreshing holdings for a whole book of accounts on a schedule
- Tax and cost-basis workflows that need holdings at each event
Realtime API
Enabled on requestREST over the indexed dataset
Query indexed Berachain records over REST, reading the same dataset the share reads, with no warehouse in the path.
Used for:
- Applications that need one answer rather than a table scan
- Customer-facing screens where query latency is visible to a user
- Services that have no data warehouse and do not want to run one
- Prototyping against production data before committing to a share
- Backend checks that run per request instead of per batch
- Teams that want indexed Berachain data behind their own API layer
Berachain data: frequently asked questions
What is Berachain?
Berachain is an EVM Layer 1 whose mainnet went live in 2025. It splits consensus from execution the way Ethereum does: a CometBFT-based consensus layer, BeaconKit, drives an otherwise standard Ethereum execution client through the same engine interface, which is why contracts, twenty-byte addresses, receipts and event logs behave exactly as an EVM pipeline expects. The reward design is what makes the chain its own. Under Proof of Liquidity, validators are bonded with BERA, but the emissions they direct are paid as BGT, a token earned by supplying liquidity to approved reward vaults rather than by holding a balance, and BGT cannot be sent between accounts. It can be delegated to a validator or redeemed for BERA. BERA pays for gas, and HONEY is the network’s stablecoin, which gives the chain three tokens with three separate jobs and no overlap between them.
Berachain data on SonarX
SonarX indexes Berachain end to end: blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces including internal value transfers, and token transfers and balances. The same normalized model is used on every chain SonarX covers, so Berachain activity can be joined to other networks in one query rather than reconciled between two pipelines afterwards.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery keeps the same dataset current to chain tip. The real-time balances API and the batch wallets, tokens and balances API are available for Berachain, and the rest can be enabled on request. Kafka streaming can be enabled for Berachain on request.
How SonarX indexes Berachain
The reward token is the problem worth naming. BGT is not transferable, so the usual method of following a token by its transfer events returns almost nothing, and earnings have to be rebuilt from vault accrual, claims, delegations and redemptions instead. That makes incentive analysis a state-reconstruction job rather than a log-reading one. The second half sits on the consensus layer: proposals, validator sets and the emissions they steer are recorded by Berachain Beacon rather than in execution blocks, so a complete account of who was rewarded for what spans two datasets that share a height.
What teams build with Berachain data
Emissions analysis is the workload specific to this chain: which vaults received rewards, which validators directed them there, and what liquidity actually arrived as a result. Reward attribution is the second, since a participant’s earnings are an accrual history rather than a balance and have to be restated per account and per block. Position-level DeFi analytics is the third, built from decoded logs and traces together, and on a chain where liquidity provision is also the reward mechanism the two analyses feed each other. Protocol treasury reporting is the fourth, because a protocol that holds vault positions carries exposure no plain token balance shows, and stating it as at a quarter end means replaying accruals rather than reading a figure.
Getting Berachain data from SonarX
Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Berachain mainnet history is available now, and streaming is provisioned on request. 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.
Is there a Berachain data API?
Yes. Real-time and batch APIs over indexed Berachain data are available today, covering historical and latest balances and wallet, token and balance lookups in bulk. They read from the same indexed dataset as the Snowflake share and the file delivery, so an API answer and a warehouse query agree.
How do I get Berachain data into Snowflake?
SonarX provisions a data-share into your own Snowflake account. The share appears as a database you query with SQL, so there is no pipeline to build and no second copy to store, and it stays current as SonarX advances the indexing pipeline.
How far back does Berachain coverage go?
The historical data-share and file delivery cover the mainnet's recorded history from its 2025 launch forward, and are available today. Because consensus and execution run as separate layers, records from the beacon side are covered as their own dataset, so tell us whether your analysis needs both.
Why does BGT not show up as a token transfer?
Because it is not transferable. BGT is earned through liquidity in approved vaults and can be delegated to a validator or redeemed for BERA, but it does not move between accounts the way an ERC-20 does. Reward attribution therefore has to be rebuilt from vault accrual, claims and redemptions rather than read from a transfer log.
Is this Berachain mainnet or the testnet?
Mainnet. The public test network is a separate chain with its own history, its own validators and its own page, and the coverage stated here applies only to mainnet. If your work involves both, say so when the share is scoped and each will be confirmed separately.
