Indexed MovementBlockchain Data
Movement is a Move VM network where assets are typed resources stored under account addresses rather than balances in a contract's mapping, and it settles to Ethereum rather than finalizing alone.
How to query Movement data with SonarX
Instant Data Share
Available todaySnowflake, and file dumps to your object storage
Query Movement 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 Movement 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 Movement 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 Movement 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 Movement activity within seconds
- Fraud and anomaly detection that has to fire before settlement
- Live dashboards and alerting on Movement 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
Realtime API
Enabled on requestREST over the indexed dataset
Query indexed Movement 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 Movement data behind their own API layer
Movement data: frequently asked questions
What is Movement?
Movement is a Move network: its documentation lists the production chain as Movement Mainnet under chain ID 126, with a test network on chain ID 250, and groups both under Movement L1. Execution is the Move VM, and Move is the language Meta developed for handling financial assets, which shows in how state is held. Assets are typed resources stored under account addresses rather than balances in a contract’s mapping, and a resource cannot be copied or discarded, so ownership moves by writing it out of one account and into another. Contracts are modules published under an address, and a call names a module and a function. Addresses are fixed-length hex values, longer than the twenty bytes EVM tooling expects. MOVE is the native token, and the architecture settles to Ethereum rather than finalizing alone.
Movement data on SonarX
SonarX indexes what a Move ledger produces: blocks and their transactions with the versions attached, module publications, entry-function calls, the resource changes each transaction wrote, the typed events modules emit, and derived account balances. Everything is normalized into the model SonarX uses across every network it covers, so resource-based activity aggregates alongside account-based chains.
Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Kafka streaming can be enabled for Movement on request.
How SonarX indexes Movement
The resource model is what makes this chain unlike an EVM one. A balance is a field inside a typed resource held at an account address, so a transfer is two resource writes rather than an event, and reading transfers means reading state changes rather than decoding logs. Events are typed by the module that emits them, so decoding is keyed to a published module and its structs rather than to an ABI registry looked up by address. Transaction versions and block heights are separate axes through the same history, an easy source of double counting. Network naming has also changed during this chain’s life, so a long series has to name the identifier it came from.
What teams build with Movement data
Position reconstruction is the first workload, and on a Move chain it is a state question: what resources an address held at a height, rather than a running total of events. Protocol-level analysis is the second, reading one module’s resources over time to see how an application’s own state moved. Token accounting is the third, following a coin type from publication through its transfers, and treasury reporting is a fourth, since a fund holding the native asset has to restate it from the same resource records. DeFi analytics covers position-level work across chains, and teams comparing the Move networks usually hold Aptos in the same warehouse.
Getting Movement 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. Movement history is available now as a share or a file delivery, and streaming is provisioned on request. Say which modules matter, because resource history scoped to a module is far smaller. 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 Movement data API?
APIs over indexed Movement 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 Movement 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 Movement coverage go?
The historical data-share and file delivery cover the recorded history of the network its documentation calls Movement Mainnet, and are available today. This is a young chain whose naming and network layout changed during its build-out, so a long series is pinned to the chain identifier it was recorded under, and depth is confirmed when the share is scoped.
Is Movement a Layer 1 or an Ethereum Layer 2?
Its own documentation groups the production network under Movement L1 and gives it chain ID 126, with a separate test network on 250, while the architecture was built to settle to Ethereum rather than to stand entirely alone. For data work the label matters less than the format: what SonarX indexes is a Move ledger with its own transaction versions, not an EVM history.
How does Movement differ from Aptos and Sui?
All three execute Move, and that is where the similarity ends. Sui makes objects the primitive, so a coin is an object with an owner and a version. Aptos and Movement keep accounts and store typed resources under them, so a balance is a field inside a resource. The consequence for analysis is that a Movement transfer reads as resource writes at two addresses rather than as a log or an object mutation.
