Indexed Gnosis BeaconBlockchain Data
The Gnosis Beacon Chain is Gnosis Chain's consensus layer, running Gasper at five-second slots and holding a validator registry whose balances are denominated in mGNO, thirty-two to the GNO.
How to query Gnosis Beacon Chain data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Gnosis Beacon Chain 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 Gnosis Beacon Chain 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 Gnosis Beacon Chain 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
Curated Datasets
Available todayPurpose-built tables
Protocol-level Gnosis Beacon Chain datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- Staking
Used for:
- Position-level Gnosis Beacon Chain 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 Gnosis Beacon Chain share with a modelled slice
Realtime API
Enabled on requestREST over the indexed dataset
Query indexed Gnosis Beacon Chain 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 Gnosis Beacon Chain data behind their own API layer
Gnosis Beacon Chain data: frequently asked questions
What is Gnosis Beacon Chain?
This is the consensus layer of Gnosis Chain, and it keeps records of its own. It has produced blocks since 2021, ran alongside the proof-of-authority execution chain for about a year, and took over ordering that chain’s blocks at the merge on 8 December 2022. It runs the same Gasper design as Ethereum’s consensus layer, pairing Casper FFG finality with LMD-GHOST fork choice, but at its own parameters: five-second slots, sixteen slots to an epoch, so an epoch closes every eighty seconds. A validator is registered by depositing 32 mGNO, which is one GNO, through a deposit contract on the execution chain. This layer runs no virtual machine and stores no contract code. What it records is the validator registry, attestations, proposals, slashings, exits and withdrawal payments, keyed by validator index and BLS public key.
Gnosis Beacon Chain data on SonarX
SonarX indexes the objects this layer produces: beacon blocks and their slots, the validator registry and every state change that moves a validator through it, attestations, deposits and exits, penalties, sync-committee duty and withdrawal payments. The same normalized model is used on every chain SonarX covers, so consensus records join execution records on the same height.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request.
How SonarX indexes Gnosis Beacon Chain
The denomination is the trap. Deposits are made in GNO and the beacon layer counts in mGNO at thirty-two to the token, so every balance, reward and penalty in these records carries a factor that has to be applied before a number means anything to an accountant. Second, funding and life are recorded on different layers: the deposit is an execution-layer transaction while activation, duty and exit are consensus records, so attributing a validator to whoever paid for it is a join across the two. Third, eighty-second epochs produce many more epoch rows per day than Ethereum’s.
What teams build with Gnosis Beacon Chain data
Reward accounting is the first workload: what a validator was owed per epoch, what it received, and what the difference cost, restated in GNO rather than in the unit the chain counts in. Staking analytics is the solution area that work belongs to across networks. Penalty and participation research is the second, since missed attestations and slashings are the only public record of how an operator behaved under stress. Withdrawal reconciliation is the third and crosses both layers, because a payment reduces a validator balance here and appears as a credit there. Validator-set research is the fourth, since a one-GNO deposit produces a much wider set than a large minimum does. Ethereum Beacon Chain is the standard comparison.
Getting Gnosis Beacon Chain 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. Consensus history is available now, and it is worth saying whether execution records are in scope too. 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 Gnosis Beacon Chain data API?
APIs over indexed Gnosis Beacon Chain data are enabled on request, reading the same indexed dataset as the Snowflake share. Note that Gnosis Beacon Chain has no user token-balance model: the only balances it records are validator balances, which belong to the staking dataset rather than to a balances API.
How do I get Gnosis Beacon Chain 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 Gnosis Beacon Chain coverage go?
The historical data-share and file delivery cover the consensus layer from its own 2021 genesis forward, which is roughly a year before it took over block production for the execution chain. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
Why are Gnosis validator balances denominated in mGNO?
So the beacon specification could be reused without rewriting its arithmetic. A validator is registered with 32 mGNO, and 32 mGNO is one GNO, which lets the deposit and reward logic written for a 32-unit stake run unchanged. The consequence for analysis is a constant factor: any balance or reward read from consensus records is in mGNO, and reporting it as GNO without dividing by 32 overstates it by that multiple.
Does Gnosis Beacon Chain data include transactions or contracts?
No. There is no virtual machine on this layer and no contract state, so there are no receipts and no event logs to decode. What it records is the validator set and every change to it: deposits, activations, attestations, block proposals, penalties, exits and withdrawal payments, keyed by validator index and BLS public key rather than by an address.