Indexed FantomBlockchain Data
Fantom Opera, an EVM Layer 1, finalizes its blocks under Lachesis, a leaderless DAG-based aBFT protocol, and kept producing them after FTM holders upgraded to Sonic.
How to query Fantom data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Fantom 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 Fantom 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 Fantom 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 Fantom 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 Fantom activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Fantom 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 todayTables and REST
Read what a Fantom 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 Fantom 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 Fantom balances on page load
- Compliance checks that read one Fantom 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 Fantom 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 Fantom data behind their own API layer
Fantom data: frequently asked questions
What is Fantom?
Fantom’s Opera mainnet has produced blocks since 2019 under Lachesis, a leaderless asynchronous BFT protocol in which validators gossip event blocks and derive an ordering from the resulting graph rather than waiting for a proposer’s turn. Confirmed blocks are emitted as an ordinary chain, so Opera presents an EVM with twenty-byte accounts and Solidity contracts, and finality lands roughly a second after a transaction is submitted. The native asset is FTM, divisible to eighteen decimals, and the network answers to chain ID 250. In December 2024 the same team launched Sonic as a separate chain and opened a one-to-one upgrade from FTM to S, which moved the token without moving the ledger: Opera’s transactions remain Opera’s. Opera has gone on producing blocks since, so the two networks run side by side rather than one replacing the other, and an address can be active on both.
Fantom data on SonarX
SonarX indexes Fantom blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances, in the normalized model used on every chain SonarX covers.
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 Fantom, and the rest can be enabled on request. Kafka streaming can be enabled for Fantom on request.
How SonarX indexes Fantom
Two things make this chain unlike an Ethereum backfill. Finality is immediate and not revisited, so records do not have to be withdrawn and rewritten after the fact, and the pipeline can treat a confirmed block as settled the moment it appears. The other is the token boundary. FTM’s balances live here while its upgraded form lives on a chain with a different genesis, so any question about a holder’s total position crosses two ledgers whose block numbers, timestamps and validator sets have nothing to do with each other. Bridge and upgrade contracts are the only join between them.
What teams build with Fantom data
Historical research is the main use. Opera hosted a full DeFi cycle, and reconstructing how lending markets, liquidity pools and liquidations behaved through it needs decoded logs and internal transfers together rather than a summary series. DeFi analytics covers that work across networks. Migration accounting is the second job: desks that held FTM and now hold S have to state a position that spans two chains, and only the Opera side is recorded here. Fee and throughput research is the third, since a chain with one-second finality produces a long, dense cost series worth comparing against the L1s in the same generation, Avalanche among them.
Getting Fantom 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. Opera history and the balance APIs are available now, and Sonic can be scoped alongside for teams that need both sides of the token move. 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 Fantom data API?
Yes. Real-time and batch APIs over indexed Fantom 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 Fantom 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 Fantom coverage go?
The historical data-share and file delivery cover the Opera mainnet from its 2019 launch forward and are available today. Sonic keeps its own separate history, so if a holder's activity crosses both networks, ask for the two to be scoped together and they are delivered side by side.
Is Fantom the same network as Sonic?
No. Sonic is the successor network and it began at its own genesis in December 2024, without importing Opera's transaction history. FTM can be upgraded to S at one to one, but a wallet's Opera activity stays on Opera, so following a holder across the two means reading two datasets rather than one continuous chain.
How does Lachesis finality change a Fantom backfill?
Lachesis is leaderless: validators gossip event blocks, ordering is derived from the resulting graph, and confirmed blocks are then emitted as an ordinary chain that EVM tooling reads normally. Finality arrives about a second after submission and is not revised afterwards, so an indexed Fantom history needs none of the reorg correction an Ethereum backfill does.
