Indexed EOSBlockchain Data
EOS is a delegated proof-of-stake Layer 1, now rebranded Vaulta, where twenty-one elected producers write half-second blocks and an account is a readable name with named permission levels.
How to query EOS data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query EOS 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 EOS 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 EOS 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
Curated Datasets
Available todayPurpose-built tables
Protocol-level EOS datasets modelled for one job, so the decoding and the joins are done before the data reaches you.
- Staking
Used for:
- Position-level EOS lending, swap and liquidity analysis
- Reward, delegation and validator reporting without rebuilding the model
- Token distribution, holder and payment-flow reporting
- Risk and exposure work that needs protocol state, not raw logs
- Skipping the decoding layer an in-house team would have to maintain
- Extending an existing EOS share with a modelled slice
Realtime API
Enabled on requestREST over the indexed dataset
Query indexed EOS 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 EOS data behind their own API layer
EOS data: frequently asked questions
What is EOS?
EOS has produced blocks since its mainnet started in June 2018, and its design choices are unusual enough to change how the history reads. Consensus is delegated proof of stake: token holders vote for twenty-one active block producers, each of which produces a run of consecutive blocks at a half-second interval before handing over. Contracts are WebAssembly, and an account is not a key hash but a short human-readable name of up to twelve characters, with named permission levels such as owner and active deciding who may sign for it. Fees work differently too: an account stakes for CPU and network bandwidth and buys RAM on a protocol market whose price moves with demand. EOS is the native token. The network has since rebranded to Vaulta, with EOS swapping one for one into a token called A.
EOS data on SonarX
SonarX indexes what this chain actually records: blocks and their producer, transactions and the actions they authorize, the inline actions contracts dispatch during execution, action traces, account and permission changes, resource staking and RAM market activity, and derived balances. Everything is normalized into the model SonarX uses across every network it covers, so named-account activity aggregates alongside address-based chains.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request.
How SonarX indexes EOS
The transaction is not the unit of truth here, the action trace is. A contract can dispatch inline actions as it runs, and token transfers commonly arrive that way, so the action tree has to be walked and kept rather than summarized into one row. Identity is the second difference: accounts are names, and the same name can be controlled through several named permission levels whose keys change over time, so attribution follows a permission history rather than a key. Resources are the third, since a transaction’s cost is drawn from staked bandwidth and purchased RAM instead of a per-transaction fee, and cost analysis has to read those records.
What teams build with EOS data
Exchange and custodian accounting is the first workload, and the named-account model helps: a deposit account is a readable name, and the permission history shows when control changed. Wallet analytics covers the address-level side of that work across chains. Token flow analysis is the second, and it is the one that fails without traces, since inline transfers are invisible to anything reading transactions alone. Contract usage research is the third, counting actions per contract over time rather than transaction totals. Teams comparing resource-metered chains usually pull TRON into the same warehouse, and Neo is the usual comparison for a non-EVM chain carrying two native assets.
Getting EOS 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. EOS history is available now as a share or a file delivery, and streaming is provisioned on request. Say which accounts or contracts matter, because that decides the size of the backfill. 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 EOS data API?
APIs over indexed EOS 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 EOS 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 EOS coverage go?
To the mainnet's start in June 2018, and it is available today as a data-share or file delivery. Half-second blocks over that span make this a large history by object count rather than by transaction value, so scoping by contract or by account usually beats taking every block, and depth is confirmed when the share is scoped.
Is EOS the same network as Vaulta?
Yes. The EOS network rebranded to Vaulta and holders swap EOS one for one into the new A token, but the ledger is continuous: the same accounts, the same producers and the same history sit underneath the new name. SonarX indexes one chain, and most tooling and most searches still use the older name, which is why this page keeps it.
Why do some EOS token transfers not appear as transactions?
Because they are inline actions. A signed transaction lists the actions its sender authorized, but a contract can dispatch further actions while it executes, and those exist only in the execution trace. Token transfers are frequently dispatched that way, so a pipeline that reads transactions and stops there will undercount transfers badly, and the trace tree has to be indexed as well.
