Indexed BitlayerBlockchain Data
Bitlayer is a Bitcoin-aligned EVM chain that charges gas in bridged BTC, so its balances are read from account state while the coin behind them keeps no accounts at all.
How to query Bitlayer data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Bitlayer 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 — on request
Used for:
- Analytics teams already on Snowflake that want Bitlayer 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 Bitlayer 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 Bitlayer 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 Bitlayer activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Bitlayer 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
Balances
Enabled on requestTables and REST
Read what a Bitlayer 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
- Real-time balances API for latest and historical balances
- Batch API for wallets, tokens and balances in bulk
Used for:
- Reconstructing Bitlayer 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 Bitlayer balances on page load
- Compliance checks that read one Bitlayer 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 Bitlayer 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 Bitlayer data behind their own API layer
Bitlayer data: frequently asked questions
What is Bitlayer?
Bitlayer is an EVM chain aligned with Bitcoin that has been live since April 2024, and the asset at the center of it is BTC. Its live network produces blocks under proof of stake with its own validator set, and gas is paid in bitcoin bridged in from Bitcoin rather than in a token the chain issued. The network answers to chain ID 200901. Execution is account-based with twenty-byte addresses and the usual token standards, so Solidity contracts and their artifacts port over unchanged, which is the practical reason applications deploy here at all. That leaves a chain whose bookkeeping is Ethereum’s and whose unit of account is Bitcoin’s: balances are read from state rather than derived from unspent outputs, and the coin they are denominated in has no accounts on its own ledger.
Bitlayer data on SonarX
SonarX indexes Bitlayer blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances, with native BTC movement captured as value transfers.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Balance tables and the balance APIs can be enabled for Bitlayer on request. Kafka streaming can be enabled for Bitlayer on request.
How SonarX indexes Bitlayer
One asset with two bookkeeping models is the difficulty here. BTC is an account balance credited by a bridge, while the same coin on Bitcoin exists only as unspent outputs, so following a holding across the two means switching models and rescaling: an EVM chain meters value in wei-scale integers and Bitcoin counts satoshis. Bridge mints and burns are the join between the sides, and only one leg of each is recorded here. And because BTC is native rather than an ERC-20, a pipeline that tracks it through transfer events elsewhere finds nothing.
What teams build with Bitlayer data
Bridged-BTC accounting is the workload this chain creates. Stating how much bitcoin is held on the chain, and reconciling it against what left Bitcoin, is a two-ledger question that no single balance answers. Position-level DeFi analytics is the second, since lending and liquidity here are denominated in BTC and a return series has to be priced in the same asset. Fee analysis is a third and unusual one: transaction costs are quoted in bitcoin, so a cost comparison against an ETH-priced chain is a currency conversion before it is anything else. Desks weighing one Bitcoin layer against another usually pull BOB beside it, where the same coin arrives as a token rather than as gas.
Getting Bitlayer 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. History is available now as a share or a file delivery, and Bitcoin coverage can be scoped beside it for the bridge side. 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 Bitlayer data API?
Real-time and batch APIs over indexed Bitlayer data are enabled on request: the same indexed dataset the Snowflake share reads, served over REST once provisioned. Tell us the lookup pattern you need.
How do I get Bitlayer 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 Bitlayer coverage go?
The historical data-share and file delivery cover the chain from its 2024 launch forward, and are available today. The Bitcoin side of a bridged position is a separate history on a separate chain, so if a reconciliation needs both, say so when the share is scoped and Bitcoin coverage is provisioned alongside it.
How are BTC balances recorded on Bitlayer?
As native account balances, not as a token contract. That inverts the usual pattern, where BTC on an EVM chain is an ERC-20 you can follow through transfer events. Here a BTC movement is a value transfer in a transaction, and the amounts are metered in wei-scale integers rather than in satoshis, so a figure taken from this chain has to be rescaled before it is compared with a Bitcoin record.
