SonarX

Indexed XPLABlockchain Data

XPLA is the Cosmos SDK appchain the game publisher Com2uS built as the settlement layer for its own titles, running CosmWasm and an EVM on one ledger, now rebranded CONX.

XPLA logo

How to query XPLA data with SonarX

Instant Data Share

Available today

Snowflake, and file dumps to your object storage

Query XPLA 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 XPLA 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 XPLA 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

Balances

Enabled on request

Tables and REST

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

XPLA data: frequently asked questions

What is XPLA?

XPLA has produced blocks since 2022 as a sovereign Cosmos SDK chain, built by the Korean game publisher Com2uS as the settlement layer for its own titles and the studios around them. Validators run CometBFT under proof of stake, XPLA is the native token, and accounts are bech32 strings with an xpla prefix. Two execution environments sit on that one ledger: CosmWasm, where contracts are WebAssembly modules, and an EVM built on go-ethereum, where the same Solidity a developer would deploy to Ethereum runs unchanged. Because that EVM uses Ethereum’s key format, one account has two written forms, a bech32 string and a twenty-byte hex address, and IBC keeps the chain connected to the Cosmos Hub. The community has since voted to rename the token and the brand to CONX, which changed the name without changing the ledger.

XPLA data on SonarX

SonarX indexes both halves of the chain: blocks and transactions with their typed messages, CosmWasm instantiate and execute calls, EVM transactions with their receipts and decoded logs, IBC transfers, staking records, and derived balances across all of it. Everything is normalized into the model SonarX uses on every network it covers, so a wasm transfer and an ERC-20 transfer read the same way.

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 XPLA on request.

How SonarX indexes XPLA

A token here can be three things, and a holder total is wrong unless all three are counted: a native bank denomination held as protocol state, a CW20 balance inside a wasm contract, and an ERC-20 balance inside EVM storage. Each has its own transfer semantics and its own way of reporting a change, so one asset can move through all three representations in a day. Identity compounds it: the same keys produce a bech32 address and a hex address, both appear in the history, and attribution has to canonicalize the pair before any balance is summed.

What teams build with XPLA data

In-game economy analysis is the first workload: how much of a title’s currency is minted, spent and withdrawn, measured per period rather than per session, which is the only view that shows whether an economy is closed. Holder and item analysis is the second, and it is where the three token systems have to be reconciled into one holder set. Treasury and issuance reporting is the third, since a publisher operating several titles needs one statement across them. Token analytics covers issuance work of this kind across chains, and teams comparing company-run networks usually pull Chiliz into the same warehouse.

Getting XPLA 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. XPLA history is available now as a share or a file delivery, and streaming is provisioned on request. Say which contracts matter, because scoping by contract usually beats taking the chain whole. 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 XPLA data API?

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

The historical data-share and file delivery cover the chain's recorded history from its 2022 launch forward, and are available today. Contract activity did not start evenly across the chain's two execution environments, so a token's own history begins where it was deployed rather than at the first block, and depth is confirmed when the share is scoped.

Is XPLA EVM-compatible?

Yes, alongside CosmWasm. The chain runs an EVM module built on go-ethereum next to its wasm runtime, so Solidity contracts deploy here and so do Rust wasm contracts. SonarX classifies the chain under the Cosmos schema family because that is how its blocks, transactions and typed messages are modeled, which is a statement about the data shape rather than about what the chain can execute.

Is XPLA the same network as CONX?

Yes. The chain's community voted to rename the token, the symbol and the brand to CONX, and the network now presents itself that way. What sits underneath is unchanged: the same validator set, the same genesis and the same address format, so SonarX indexes one continuous history and most tooling still shows the older name.

XPLA logo

Get XPLA data from SonarX