Indexed Sei EVMBlockchain Data
Sei EVM is not a rollup but the EVM execution environment inside the Sei Layer 1, executing in the same blocks and under the same Tendermint validator set as Sei's CosmWasm surface.
How to query Sei EVM data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Sei EVM 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 EVM 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 EVM 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 Sei EVM 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 Sei EVM activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Sei EVM 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 Sei EVM 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 EVM 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 EVM balances on page load
- Compliance checks that read one Sei EVM 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 EVM 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 EVM data behind their own API layer
Sei EVM data: frequently asked questions
What is Sei EVM?
Sei EVM is the EVM execution environment inside the Sei Layer 1, and it is not a rollup. It has no consensus of its own and settles to no other chain. It executes in the same blocks, under the same Tendermint BFT validator set, as the CosmWasm surface covered on Sei, and it reached mainnet with the v2 upgrade in 2024. Above that boundary the environment behaves the way an EVM team expects: Solidity bytecode deploys, addresses are twenty bytes, ERC-20 and ERC-721 contracts decode against their ABIs, and gas is paid in SEI, the network’s native token. Two things are local to this network. An account’s twenty-byte address and its bech32 address derive from one public key, and the chain treats them as separate accounts until a transaction associates them. And a token that already exists as a CosmWasm contract can be registered with a pointer contract that presents it through an ERC-20 interface, so one asset is reachable from either side under two addresses.
Sei EVM data on SonarX
SonarX indexes the EVM side in the shapes an EVM team already queries: blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces with internal value transfers, and token transfers and balances. Those records go into the normalized model SonarX uses across every network it covers, so this surface joins to activity elsewhere directly.
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 EVM on request. Kafka streaming can be enabled for Sei EVM on request.
How SonarX indexes Sei EVM
This EVM does not stand alone, and that is the engineering story. Its blocks are the network’s blocks, so the EVM dataset and the native dataset advance on one height and have to be indexed in step or cross-surface analysis quietly mismatches. Pointer contracts are the second trap: an ERC-20 here can be a presentation of a CosmWasm token rather than the asset itself, so supply and holder counts that treat the pointer as an independent token double count. Identity is the third, since the same owner reaches this surface through a twenty-byte address and the native surface through a bech32 address.
What teams build with Sei EVM data
Protocol analytics is the direct case: lending, perpetuals and vault contracts deployed on a chain whose native side already carries order flow, studied through decoded logs and traces rather than through transfers alone. Token accounting is the recurring one, and it hinges on resolving pointers, because a treasury report that counts a CosmWasm balance and its ERC-20 presentation states the same holding twice. Contract-level risk work is the third, tracing which deployments reach across to the native surface and what that exposure looks like over time. Token analytics covers the issuance side across chains, and teams comparing dual-environment designs usually pull HyperEVM alongside it.
Getting Sei EVM 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. This surface and its balance APIs are available now, and most first deliveries are scoped alongside the native 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 Sei EVM data API?
Real-time and batch APIs over indexed Sei EVM 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 EVM 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 EVM coverage go?
The historical data-share and file delivery cover the EVM surface from its 2024 arrival forward, and are available today. The network itself is older than this surface, so if a workflow needs the years before it, that history sits on the native side and the two are scoped together.
Do Sei and Sei EVM share one dataset?
No. They share a chain, a validator set and a block height, but they produce different records, so SonarX indexes them as two datasets with a common height to join on. That join is usually the point: an asset held as a CosmWasm token and traded through an ERC-20 pointer contract is one position described in two sets of records.
Are Sei and Sei EVM the same network?
Yes. They are two execution environments inside one network. The native surface runs Cosmos SDK modules and CosmWasm contracts and has its own page. Sei EVM, covered here, 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.
