SonarX

Indexed UnichainBlockchain Data

Unichain is the OP Stack rollup Uniswap Labs built on Ethereum, producing one-second blocks from a builder inside a trusted execution environment and preconfirming them as sub-second Flashblocks.

Unichain logo

How to query Unichain data with SonarX

Instant Data Share

Available today

Snowflake, and file dumps to your object storage

Query Unichain 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 Unichain 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 Unichain 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 request

Event stream

Consume Unichain 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 Unichain activity within seconds
  • Fraud and anomaly detection that has to fire before settlement
  • Live dashboards and alerting on Unichain 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

Available today

Tables and REST

Read what a Unichain 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 — on request
  • Real-time balances API for latest and historical balances
  • Batch API for wallets, tokens and balances in bulk

Used for:

  • Reconstructing Unichain 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 Unichain balances on page load
  • Compliance checks that read one Unichain 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 request

REST over the indexed dataset

Query indexed Unichain 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 Unichain data behind their own API layer

Unichain data: frequently asked questions

What is Unichain?

Unichain is an Ethereum Layer 2 built by Uniswap Labs on the OP Stack, opened to the public in February 2025 after producing its first blocks in late 2024. It is an optimistic rollup with permissionless fault proofs, settling to Ethereum, where its batch data is posted as blobs. Blocks arrive every second. Inside each one the builder publishes Flashblocks: partial blocks issued several times a second as preconfirmations, which are not canonical blocks and carry no block number of their own. Block building itself runs inside a trusted execution environment kept separate from the sequencer. Execution is the EVM, with ordinary twenty-byte addresses. Gas is paid in ETH, while UNI is Uniswap’s governance token on Ethereum and pays for nothing here. The workload the chain was built around is Uniswap v4, where every pool is state inside one contract rather than a deployment of its own.

Unichain data on SonarX

SonarX indexes blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces including internal value transfers, and token transfers and balances. The same normalized model is used on every chain SonarX covers, so trading on Unichain can be compared with the same protocol’s deployments elsewhere without reconciling two schemas.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. The real-time balances API and the batch wallets, tokens and balances API are available for Unichain, and the rest can be enabled on request. Kafka streaming can be enabled for Unichain on request.

How SonarX indexes Unichain

Two habits from other EVM chains fail here. The first is treating everything the sequencer emits as a block: Flashblocks are preconfirmations with a position inside the block being built, not entries in the chain, and only the one-second block is settled, so SonarX indexes canonical blocks and a transaction lands once. The second is keying pools by contract address. Uniswap v4 holds every pool as state in a single manager, so swaps arrive as events from one address carrying a pool identifier, and the per-pool address older pipelines join on does not exist. Netting makes it worse: a transaction moves only its net balance, so transfer records understate the trading that produced them.

What teams build with Unichain data

Market-structure research is the first workload and the most chain-specific: pool-level behavior under v4, how hooks change execution, and how one-second blocks and sub-second preconfirmations affect where trades land in a block. Liquidity accounting is the second, reconstructing what a position earned over time when the position is state inside a manager contract rather than a balance in a pool. Flow reconciliation is the third, following assets between Ethereum, Ink and the other rollups where the same protocols are deployed. DeFi analytics work spans all three, and none of it needs a live lookup: it is range queries over a full history, run once a quarter or once a day rather than once a second.

Getting Unichain 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, canonical blocks only, so nothing has to be de-duplicated afterwards. 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 Unichain data API?

Yes. Real-time and batch APIs over indexed Unichain data are available today, covering historical and latest balances and wallet, token and balance lookups in bulk. They read from the same indexed dataset as the Snowflake share and the file delivery, so an API answer and a warehouse query agree.

How do I get Unichain 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 Unichain coverage go?

Back to the chain's first blocks in late 2024, which is before the February 2025 public launch, so the earliest period is thin rather than missing. The historical data-share and file delivery cover that history and are available today, with real-time delivery and Kafka streaming provisioned on request.

Are Flashblocks part of the indexed Unichain data?

No, and that is deliberate. Flashblocks are partial blocks the builder publishes as preconfirmations several times a second; they have a position inside the block being assembled rather than a block number of their own, and only the one-second canonical block is settled. SonarX indexes canonical blocks, so a record appears once. Treating the preconfirmation stream as block data is how pipelines end up double-counting.

How does Uniswap v4 change what Unichain swap data looks like?

Pools are no longer separate contracts. In v4 they are state inside one manager contract, so swap events come from a single address and identify the pool by an identifier rather than by its own address. Anything keyed on a per-pool contract address finds nothing. Netting is the second change: a transaction settles only its net balance change, so token transfers understate the trading behind them.

Unichain logo

Get Unichain data from SonarX