Indexed XDC NetworkBlockchain Data
XDC Network is an enterprise EVM Layer 1 for trade finance, launched as XinFin in 2019, running XDPoS consensus and writing the same twenty bytes with an xdc prefix instead of 0x.
How to query XDC Network data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query XDC Network 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 XDC Network 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 XDC Network 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 XDC Network 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 XDC Network activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on XDC Network 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 XDC Network 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 XDC Network 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 XDC Network balances on page load
- Compliance checks that read one XDC Network 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 XDC Network 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 XDC Network data behind their own API layer
XDC Network data: frequently asked questions
What is XDC Network?
XDC Network has produced blocks since its mainnet opened in 2019, launched under the name XinFin, which still appears in older tooling. Consensus is XDPoS, a delegated proof of stake in which stake elects the validator set that signs blocks, and blocks arrive about every two seconds. XDC is the native coin and pays gas. Execution is EVM-compatible, so Solidity contracts deploy unchanged and token transfers decode against their ABIs, and the network answers to chain ID 50. The visible difference is the address convention: the same twenty bytes are conventionally written with an xdc prefix instead of 0x, so one account has two spellings depending on which tool printed it. Its stated focus is trade finance and tokenization, which shows in the record as instrument contracts and settlement state rather than trading activity. Contract standards come from Ethereum.
XDC Network data on SonarX
SonarX indexes XDC Network blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, and token transfers and balances. Those records land in the normalized model SonarX uses on every network it covers.
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 XDC Network on request. Kafka streaming can be enabled for XDC Network on request.
How SonarX indexes XDC Network
The address convention is the first thing to get right. A holder written as xdc in one system and 0x in another is one account, so a join keyed on the string rather than on the bytes will either split a holder in two or lose them, and every address is normalized before balances are derived. What the traffic contains is the second. Tokenized instruments live in contract state, so a position is read at a height rather than accumulated from transfers, and a settlement often appears as a state change with a document reference attached rather than as a payment. Two-second blocks also make the row count larger than the value moved would suggest.
What teams build with XDC Network data
Instrument reporting is the first workload: which contracts hold which tokenized positions, when they changed, and what the state was on a given date. Token accounting is the second, covering issuance, redemption and the transfers between them for assets that represent something offchain. Tokenization and RWA solutions cover that work across chains. Counterparty analysis is the third, and it depends on address normalization, because a report that treats the xdc and 0x spellings as two participants will double its counterparty list. Teams comparing enterprise ledgers usually pull VeChain into the same warehouse.
Getting XDC Network 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. XDC Network history is available now, so a first delivery is provisioning rather than engineering. 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 an XDC Network data API?
Real-time and batch APIs over indexed XDC Network 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 XDC Network 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 XDC Network coverage go?
The historical data-share and file delivery cover the chain from its 2019 mainnet forward, and are available today. That span is the whole record, since the network has run without a migration or a restart behind it. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
Is XDC Network EVM-compatible?
Yes. The chain executes Solidity bytecode, contracts follow the same token interfaces an Ethereum team already decodes, and it answers to chain ID 50. Coverage tables that file it under a non-EVM heading are describing how SonarX models the dataset, not the chain. The practical difference is the address convention: the same twenty bytes are usually printed with an xdc prefix instead of 0x.
Is XDC Network the same as XinFin?
Yes. XinFin is the project that launched the network and the name that still appears in older tooling and documentation; XDC Network is what it is called now, and XDC is the coin that pays for gas. There is one chain and one history behind both names, and SonarX indexes it as a single dataset.
