Indexed CoreBlockchain Data
Core elects its validators from Bitcoin: Satoshi Plus scores delegated mining hash power, staked CORE and timelocked BTC into one ranking on an EVM Layer 1.
How to query Core data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Core 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 Core 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 Core 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 Core 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 Core activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Core 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 Core datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- Staking
Used for:
- Position-level Core 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 Core share with a modelled slice
Balances
Enabled on requestTables and REST
Read what a Core 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 Core 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 Core balances on page load
- Compliance checks that read one Core 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 Core 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 Core data behind their own API layer
Core data: frequently asked questions
What is Core?
Core is an EVM-compatible Layer 1 whose validator set is elected from Bitcoin. Its Satoshi Plus consensus folds three inputs into one hybrid score: Bitcoin miners delegate hash power by writing metadata into the coinbase transaction’s OP_RETURN, CORE holders delegate stake, and Bitcoin holders lock BTC behind a CLTV timelock whose redeem script names the validator they back. The thirty-one highest-scoring validators are elected for a round lasting one day and take turns producing blocks in three-second slots. The native asset is CORE, capped at 2.1 billion units, with block rewards paid out over an eighty-one-year emission schedule. Execution is account-based over twenty-byte addresses on a client derived from Geth, the chain answers to chain ID 1116, and mainnet has produced blocks since 2023.
Core data on SonarX
SonarX indexes Core blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances, in the normalized model used on every chain SonarX covers.
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 Core on request. Kafka streaming can be enabled for Core on request.
How SonarX indexes Core
Part of what decides a Core block is recorded on Bitcoin. Hash-power delegation arrives as metadata in a Bitcoin coinbase transaction, and a BTC stake is a Bitcoin timelock whose validator target sits in an OP_RETURN output, so the votes that elect a validator set exist as Bitcoin records before they exist as Core records. Core’s own state holds the verified result, relayed in through its Bitcoin light client, which means a full account of who secures the chain is a join across two histories with different block intervals and different reorg behavior. Rewards are then accounted per daily round rather than per block.
What teams build with Core data
Validator and reward accounting is the first workload, and it is a two-chain question: the delegations that decide an election are Bitcoin records, while the rewards they earn are Core records. Bitcoin locking analysis is the second job, following when coins were committed, for how long, and what moved when a timelock expired, which is a Bitcoin-side series with consequences recorded here. Position-level DeFi analytics is the third, built from decoded events with internal transfers attached, and a good deal of the collateral on this chain is Bitcoin-denominated. Teams weighing the ways to build around Bitcoin usually read this page beside Stacks.
Getting Core 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, and Bitcoin can be scoped beside it when a question spans both chains. 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 Core data API?
Real-time and batch APIs over indexed Core 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 Core 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 Core coverage go?
The historical data-share and file delivery cover Core from its 2023 mainnet forward and are available today, with exact depth confirmed when the share is scoped. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
Is Core the same thing as Bitcoin Core?
No. Bitcoin Core is the reference client software that runs Bitcoin. Core, also written Core Chain and governed by the Core DAO community, is a separate EVM Layer 1 whose consensus reads Bitcoin blocks to elect its own validators, with CORE as its native asset. Bitcoin's own records are a different dataset with its own page, so ask for both when a question crosses the two.
