Indexed SyscoinBlockchain Data
Syscoin runs a UTXO ledger and an EVM ledger side by side on one merge-mined chain, with SYS moving between them through a protocol-level burn and mint.
How to query Syscoin data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Syscoin 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 Syscoin 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 Syscoin 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 Syscoin 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 Syscoin activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Syscoin 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 Syscoin 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 Syscoin 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 Syscoin balances on page load
- Compliance checks that read one Syscoin 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 Syscoin 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 Syscoin data behind their own API layer
Syscoin data: frequently asked questions
What is Syscoin?
Syscoin has produced blocks since 2014, and the work that secures them is not its own. Blocks are merge-mined with Bitcoin, so the SHA-256 hashing that seals a Bitcoin block seals a Syscoin one, and Syscoin pays those miners in SYS. A quorum of collateralized validators then signs chainlocks over the tip, which is what rules out deep reorganizations rather than merely making them expensive. Two ledgers run side by side. The original chain records unspent transaction outputs the way Bitcoin does, while the NEVM ledger records EVM accounts and contracts under chain ID 57 with an EIP-1559 fee market. SYS is one coin across both, and moving it between them is a protocol-level burn and mint rather than a third-party bridge. Rollux, an EVM rollup, publishes its batches here rather than to Ethereum.
Syscoin data on SonarX
SonarX indexes both sides of the network: blocks and headers, transactions, and output creation and spends on the UTXO ledger, then transactions, receipts, decoded event logs, execution traces and token transfers on the NEVM ledger. Both land in the normalized model SonarX uses on every chain it covers, so the two are queryable side by side.
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 Syscoin on request. Kafka streaming can be enabled for Syscoin on request.
How SonarX indexes Syscoin
A complete account of SYS spans two bookkeeping models. On the original ledger a balance exists only as the sum of unspent outputs a key can spend, and on NEVM the same coin sits in an account with a nonce, so a holder view means replaying spends on one side and reading state on the other. The burn and mint that carries the coin between them has to be matched in pairs, or supply appears to move when nothing did. Proof of work adds the second problem: the tip stays provisional until a chainlock covers it, so ingestion follows that signal instead of a fixed confirmation depth.
What teams build with Syscoin data
Supply reconciliation is the first workload, because a SYS figure that reads one ledger and not the other is wrong by whatever sits on the other side. Address-level research is the second, and on the output side it works the way Bitcoin analysis works: clustering, output ages and change heuristics rather than account balances. Settlement reconciliation is the third, matching a rollup’s batches against the Syscoin blocks that carry them, which is the check an L2 operator or its auditor actually runs. Wallet analytics covers holder-level work across chains, and teams already indexing Bitcoin find the output model here familiar.
Getting Syscoin 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. Syscoin history is available now as a share or a file delivery, and streaming is provisioned on request. 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 Syscoin data API?
Real-time and batch APIs over indexed Syscoin 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 Syscoin 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 Syscoin coverage go?
The historical data-share and file delivery cover the chain from its 2014 origin forward, and are available today. The NEVM ledger is younger than the network, so records for EVM accounts and contracts begin where that ledger begins rather than at the first block. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.
How does SonarX handle Syscoin's two ledgers?
As two sets of records with one coin moving between them. On the unspent-output side a balance is derived by replaying output creation and spends; on the NEVM side it is read from account state. SYS crossing between the two is a protocol-level burn and mint, so those events are matched in pairs rather than counted twice, which is what keeps a supply figure honest across both.
Is Syscoin secured by Bitcoin's miners?
Its blocks are merge-mined, so miners hashing for Bitcoin can seal Syscoin blocks with the same work, and Syscoin pays them in SYS for it. Chainlocks signed by a collateralized quorum then fix the tip, which rules out deep reorganizations rather than only making them costly. That matters to a pipeline: the rule that decides when a block is safe to treat as settled is the chainlock, not a fixed depth.
