SonarX

Indexed ScrollBlockchain Data

Scroll is a zkEVM rollup on Ethereum that proves Ethereum bytecode as it is, so the same compiled artifact deploys to both chains and a batch is final once its proof verifies.

Scroll logo

How to query Scroll data with SonarX

Instant Data Share

Available today

Snowflake, and file dumps to your object storage

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

Tables and REST

Read what a Scroll 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 Scroll 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 Scroll balances on page load
  • Compliance checks that read one Scroll 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 Scroll 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 Scroll data behind their own API layer

Scroll data: frequently asked questions

What is Scroll?

Scroll is a zero-knowledge rollup that has been producing mainnet blocks since 2023. A sequencer orders transactions, a prover generates a validity proof for each batch, and a contract on Ethereum verifies that proof, which is what makes the batch final. There is no challenge window, because correctness is proved rather than assumed. The chain’s distinguishing choice is equivalence: its zkEVM proves Ethereum bytecode itself instead of a compiled alternative, so contracts, twenty-byte addresses, opcodes and developer tooling behave as they do on L1 and the same compiled artifact can be deployed to both. Gas is paid in ETH, with SCR a separate governance token that buys no block space. Transactions that start on Ethereum, such as bridge deposits, are delivered into Scroll blocks as messages, which is why some transactions in a block have no ordinary sender paying for them.

Scroll 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 a contract deployed to both Scroll and Ethereum can be analyzed as one deployment across two networks.

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 Scroll on request. Kafka streaming can be enabled for Scroll on request.

How SonarX indexes Scroll

Bytecode equivalence removes one problem and two chain behaviors add others. Because the same artifact runs on both networks, an ABI resolved on Ethereum decodes the identical contract here, so logs are readable without a second registry and proxy resolution follows the same rules. Transactions delivered from Ethereum are harder: they execute inside L2 blocks as their own transaction type, with no sender paying an L2 fee, so per-transaction fee statistics have to exclude them, and tracing a deposit means joining an L1 message to its L2 execution. Timestamps are the other trap. They are not strictly increasing, and consecutive blocks can share a second, so ordering by time is not ordering by block.

What teams build with Scroll data

Bridge accounting is the workload that comes up first. Assets arrive from Ethereum and leave the same way, and stating what is actually held on the rollup at a point in time means matching both legs rather than trusting a bridge contract’s balance. Position-level DeFi analytics is the second, and it is cheap to extend here because the same decoding that works on L1 works unchanged. Deployment comparison is the third: protocol teams running the same contracts on Ethereum and on Linea or Scroll want user behavior and cost per action side by side, which only works when all three histories sit in one place. Proving economics is a fourth: each batch records what was proven and when it was verified, which is the raw material for comparing one rollup’s settlement costs against another’s.

Getting Scroll 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. Scroll history is available now, including the L1 messages that execute inside its blocks. 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 Scroll data API?

Real-time and batch APIs over indexed Scroll 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 Scroll 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 Scroll coverage go?

The historical data-share and file delivery cover the chain's recorded history from its 2023 mainnet launch forward, and are available today. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.

Do bridged deposits look different in Scroll data?

Yes. A deposit begins as a message sent to a contract on Ethereum and is then executed inside a Scroll block, so the resulting transaction has no ordinary sender paying an L2 fee. Averaging fees across every transaction in a block therefore skews low, and matching a deposit end to end means joining the L1 message to the L2 execution rather than reading one record.

Are Scroll contracts the same bytecode as on Ethereum?

Yes, and it simplifies decoding. Because the zkEVM proves Ethereum bytecode rather than a compiled alternative, a contract deployed to both networks has the same artifact and the same ABI on each, so one registry decodes both. That is not true of every ZK rollup: chains with their own virtual machine need their own compiler output before their logs can be read.

Scroll logo

Get Scroll data from SonarX