Indexed SeiBlockchain Data
Sei is a Cosmos SDK Layer 1 built for trading, reaching finality inside a second under Twin Turbo and running CosmWasm and an EVM against one state machine since its v2 upgrade.
How to query Sei data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Sei 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 Sei 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 Sei 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
Balances
Enabled on requestTables and REST
Read what a Sei 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 Sei 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 Sei balances on page load
- Compliance checks that read one Sei 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 Sei 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 Sei data behind their own API layer
Sei data: frequently asked questions
What is Sei?
Sei’s mainnet has produced blocks since 2023, and it was built for one workload: trading. It is a Cosmos SDK Layer 1 whose validators run a Tendermint BFT protocol Sei calls Twin Turbo, which processes and propagates blocks optimistically to reach finality inside a second, and transactions that touch unrelated state execute in parallel rather than in single file. SEI is the native token and pays for gas, and native accounts carry bech32 addresses with a sei prefix. The v2 upgrade, which reached mainnet in 2024, put an EVM inside the same state machine, so Solidity and CosmWasm contracts execute against one ledger instead of on two chains; that surface has its own page at Sei EVM. One consequence matters to anybody reading the history. A single public key produces both a sei address and a twenty-byte address, and the chain treats them as separate accounts until a transaction proves they share a key.
Sei data on SonarX
SonarX indexes the native side of the network: blocks, transactions and the typed messages inside them, module events, CosmWasm contract activity, token denominations including assets that arrived over IBC, staking records, and the balances derived from all of it. Those records are normalized into the model SonarX uses across every network it covers, so a Sei question and an Ethereum question are asked in one dialect.
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 Sei on request.
How SonarX indexes Sei
The difficulty here is identity and representation rather than volume. Because one key holds two addresses, a holder can appear twice until the chain learns the pair belongs together, so positions are resolved across both forms rather than read per address. Tokens carry the same problem in another shape: a CosmWasm token can be registered with a pointer contract that presents it through an ERC-20 interface, and adding both counts one asset twice. The two execution surfaces share blocks, so the native dataset and the EVM dataset advance on a single height and are meant to be joined on it.
What teams build with Sei data
Market-structure research is the recurring request, since the venues that matter here settle onchain and their history is therefore complete rather than sampled through a venue’s own reporting. Cross-surface flow analysis is the second, following funds between the CosmWasm side, the EVM side and IBC channels to see where positions are actually financed. Validator and reward accounting is the third, because delegation rewards accrue as module state and a fund reporting them has to derive the numbers rather than count transfers. Token supply work is a fourth, and it is where the pointer duplication bites hardest. DeFi analytics covers the contract side across chains, and teams comparing venue-first designs usually pull Hyperliquid alongside it.
Getting Sei data from SonarX
Tell us which surface you need, the native side or the EVM side or both, how far back, and where the data should land. History is available now as a share or a file delivery, 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 Sei data API?
Real-time and batch APIs over indexed Sei 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 Sei 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 Sei coverage go?
The historical data-share and file delivery cover the chain's recorded history from its 2023 mainnet forward, and are available today. The EVM surface only exists from the v2 upgrade onward, so depth differs by surface, and the share is scoped against whichever side of the network your workflow reads.
Why can one Sei holder appear as two accounts?
Because a single public key yields both a bech32 address and a twenty-byte address, and the chain cannot know they belong together until a transaction associates them. Before that, the two carry separate balances. Holder counts and balance histories therefore have to be stitched across the pair, which is a step that does not exist on a chain with one address format.
Are Sei and Sei EVM the same network?
Yes. They are two execution environments inside one network. The native surface, covered on this page, runs Cosmos SDK modules and CosmWasm contracts. Sei EVM is the EVM environment in the same state machine, under the same validators and the same blocks, so the network is EVM-compatible without being two chains. They produce different records, so SonarX indexes them as two datasets and gives each its own page.
