Indexed NyxBlockchain Data
Nyx is the Cosmos SDK chain that coordinates the Nym mixnet, holding node bonds, the network topology and credential deposits as CosmWasm state and nothing about the traffic the mixnet carries.
How to query Nyx data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Nyx 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 Nyx 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 Nyx 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
Realtime API
Enabled on requestREST over the indexed dataset
Query indexed Nyx 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 Nyx data behind their own API layer
Nyx data: frequently asked questions
What is Nyx?
Nyx is the Cosmos SDK blockchain that coordinates the Nym network, and its purpose is administrative rather than transactional. Validators run the chain’s own binary under proof of stake, and NYM, the native token, pays for staking, rewards and credentials. The chain is CosmWasm-enabled and three contracts carry almost everything worth reading: a mixnet contract holding bonded node information and the network topology, a vesting contract tracking release schedules, and a zk-nym contract recording credential deposits and a blacklist that stops a credential being spent twice. That topology registry is why the chain exists: publishing the active node list and its keys on chain removes the need for a central directory anyone would have to trust. A subset of validators also issues credentials as a quorum under threshold cryptography, so no single member can issue one alone, and IBC connects the chain to the Cosmos Hub.
Nyx data on SonarX
SonarX indexes the chain’s record: blocks and transactions with their typed messages, CosmWasm execute calls with the attributes they emit, node bonding and unbonding, delegations and reward distributions, credential deposits, and derived account balances. Everything is normalized into the model SonarX uses across every network it covers, so these records read next to any other chain’s without a bespoke parser.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request.
How SonarX indexes Nyx
Almost nothing here is a transfer. The interesting facts are contract state: which nodes were bonded, what the topology looked like and which delegations stood at a given height, all of which change through execute calls rather than through payments. Reconstructing the network as it stood on a date means replaying those calls, since the contract stores only the current view. Rewards are the second awkward part, since they follow the mixnet’s own reward logic and are distributed by the protocol, so income exists before any signed transaction records it. The traffic the network carries is absent by design, and no amount of indexing produces it.
What teams build with Nyx data
Operator accounting is the first workload: what a bonded node earned over a period, netted against its delegations and commission, which is the reconciliation any validator business runs. Staking analytics covers that work across chains. Network-composition research is the second and it is specific to this chain, tracking how many nodes were active and how concentrated the bonds were over time. Token accounting is the third, since vesting schedules sit in a contract rather than in a spreadsheet. Teams studying privacy systems usually hold Zcash alongside it for the ledger-level case.
Getting Nyx 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. Nyx history is available now as a share or a file delivery, and streaming is provisioned on request. Say whether contract state matters as much as transactions, because on this chain it usually matters more. 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 Nyx data API?
APIs over indexed Nyx 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 Nyx 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 Nyx coverage go?
The historical data-share and file delivery cover the chain's recorded history, and are available today. This is a small chain by transaction count and most of what matters sits in three contracts, so a backfill is usually scoped by contract rather than by date range, and depth is confirmed when the share is scoped.
Does Nyx data show what the Nym mixnet carries?
No, and it is not supposed to. The chain records who bonded a node, which nodes are in the topology and which credentials were paid for; the traffic itself is mixed and routed outside the chain and is never written to it. Anyone expecting network telemetry here will find a registry and a payment record instead, which is the whole design rather than a gap in the data.
Is Nyx the same thing as Nym?
They are two layers of one project. Nym is the privacy network: the mixnet nodes, the clients and the credential system. Nyx is the Cosmos SDK blockchain that coordinates it, holding the bonding contracts, the topology registry and the NYM token used for staking, rewards and credential payments. SonarX indexes the chain, so the dataset is the coordination record rather than the network itself.
