SonarX

Indexed NeoBlockchain Data

Neo, a dBFT Layer 1 in its N3 form since 2021, finalizes inside a single block and carries two native assets: indivisible NEO for governance and GAS for fees.

Neo logo

How to query Neo data with SonarX

Instant Data Share

Available today

Snowflake, and file dumps to your object storage

Query Neo 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 Neo 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 Neo 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 request

REST over the indexed dataset

Query indexed Neo 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 Neo data behind their own API layer

Neo data: frequently asked questions

What is Neo?

Neo, in the form covered here, is Neo N3, whose mainnet started in 2021 and replaced the protocol the project had run since 2016. Consensus is dBFT, delegated Byzantine fault tolerance, which reaches agreement inside a single block, so a written block is final and there is no confirmation depth to respect. Two native assets sit in the protocol rather than in contracts: NEO, capped at 100 million units and indivisible, which votes and elects the committee, and GAS, with eight decimals, which pays fees and is generated for NEO holders as blocks are produced. Contracts run on the NeoVM, and core functions such as the two assets, policy and contract management are native contracts inside the protocol itself. Tokens follow NEP-17, addresses begin with the letter N, and the older ledger, Neo Legacy, keeps its own history and its own address format.

Neo data on SonarX

SonarX indexes what N3 records: blocks and their committee, transactions and their system and network fees, contract invocations and the notifications they emit, native contract activity, NEP-17 transfers, committee votes and candidate registrations, GAS generation and claims, and derived balances for both native assets. Everything is normalized into the model SonarX uses across every network it covers, so this ledger aggregates alongside chains that look nothing like it.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request.

How SonarX indexes Neo

Two properties change the bookkeeping. NEO is indivisible, so a balance is a whole-unit count and any pipeline that stores it as a decimal quantity is wrong in a way that only shows up in aggregates. GAS is generated for NEO holders block by block and then claimed later, so income exists before any transfer records it, and a holder’s earnings have to be derived from generation and claim records rather than read from movements. Activity also arrives as contract notifications rather than as logs decoded against an ABI, and the most important come from native contracts inside the protocol.

What teams build with Neo data

Holder and governance analysis is the first workload, and the dual-token model makes it unusually direct: NEO positions are whole units and votes are on chain, so ownership and participation are countable rather than inferred. Reward accounting is the second, reconstructing GAS generated and claimed per holder per period, which is the closest thing this chain has to a yield series. Token issuance reporting is the third, tracking NEP-17 assets from deployment onward. Token analytics covers that work across chains, and teams needing anything from before 2021 pair this share with Neo Legacy.

Getting Neo 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. N3 history is available now as a share or a file delivery, and streaming is provisioned on request. Say whether the older ledger is in scope, because that is a second share rather than a longer one. 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 Neo data API?

APIs over indexed Neo 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 Neo 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 Neo coverage go?

This dataset is the N3 ledger, whose genesis was in 2021, and it is available today as a data-share or file delivery. The chain Neo ran before that is a separate network with its own blocks and its own dataset, indexed as Neo Legacy, so anything older than N3 is a second share rather than an earlier part of this one.

How does Neo differ from Neo Legacy?

They are two ledgers. Neo Legacy is the chain that ran from 2016; N3 launched in 2021 with its own genesis and a rebuilt protocol, and balances move between them through a migration contract at one to one rather than by being carried over. Token standards changed with it, from NEP-5 on Legacy to NEP-17 here, and addresses begin with N on N3 where Legacy addresses begin with A.

Why does Neo have two native tokens?

To separate ownership from usage. NEO is the governance asset, capped at 100 million units and indivisible, so the smallest holding is one whole NEO and there are no decimals to carry. GAS pays fees and contract deployments, has eight decimals, and is generated for NEO holders as blocks are produced, which they then claim. One asset votes and the other pays, and they are accounted separately.

Neo logo

Get Neo data from SonarX