Indexed AstarBlockchain Data

Astar is a parachain: it produces its own blocks but does not finalize them, and that guarantee comes from the Polkadot relay chain whose validators check them. The project began as Plasm Network, took the Astar name in 2021, and launched on Polkadot as a parachain in January 2022. ASTR is the native token and pays gas. Two contract environments run on the same chain, an EVM for Solidity and a WebAssembly runtime for ink! contracts, so one block can carry both kinds of execution. Accounts follow the same split: an owner has a Substrate address in SS58 form and a twenty-byte address in hex, and Astar’s unified account mapping ties the two together instead of leaving them as strangers. dApp Staking pays rewards to deployed applications and the accounts backing them, which is a runtime feature rather than a contract layered on top.

SonarX indexes Astar blocks and headers, transactions and receipts, decoded event logs, execution traces including internal value transfers, runtime events from the WebAssembly side, and token transfers and balances. Those records land in the normalized model SonarX uses on every network it covers.

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 Astar on request. Kafka streaming can be enabled for Astar on request.

Two properties set this chain apart from an ordinary EVM network. Finality is not local: collators produce blocks and the relay chain confirms them, so ingestion follows that confirmation rather than counting local blocks. And one block can hold EVM execution and WebAssembly execution, which produce different records, logs and receipts on one side and runtime events on the other, so a decoder that reads only one of them sees a partial chain. Identity follows from the same split, since an owner holds an SS58 account and a twenty-byte account and counts twice until the mapping is applied.

Reward accounting is the recurring workload, because dApp Staking accrues to applications and their backers as runtime state, so an accrual has to be derived rather than read off a transfer. Staking analytics covers that work across chains. Cross-environment token accounting is the second, following an asset that can be held by a Solidity contract and an ink! contract in the same period. Cross-chain flow analysis is the third, since assets arrive over Polkadot’s messaging rather than through a bridge contract, and those arrivals look like runtime events rather than transfers. Teams comparing parachains usually pull Moonbeam alongside this one.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Astar coverage is provisioned on request, so tell us the history depth and the delivery target and we will scope it. 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.