Indexed AxelarBlockchain Data

Axelar has produced blocks since its genesis in December 2021, and it is a Cosmos SDK chain whose job is to carry messages between other networks. Validators run a Tendermint BFT protocol under proof of stake, AXL is the native token, and accounts are bech32 strings with an axelar prefix. Nobody deploys an application here. Instead each validator watches the chains Axelar connects to, votes on the events it observed, and takes part in threshold signing, so the chain’s own business is agreeing what happened elsewhere and authorizing a response. Assets cross as locked-and-minted representations rather than as native issuance of the kind Noble does, and arbitrary calls cross the same way through general message passing, which lets a contract on one chain invoke a contract on another. Signing keys are rotated and re-shared as the validator set changes, and those rotations are recorded on chain too.

SonarX indexes what the chain commits: blocks and transactions with their typed messages, the confirmation votes validators cast on external events, key rotations and threshold signatures, the command batches signed for other networks, routing records for each connected chain and asset, staking and reward records, and derived 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.

The record here describes events that happened somewhere else, which inverts the usual indexing problem. A transfer’s Axelar side is a set of votes and a signature, not a movement of value, so counting transactions on this chain measures how much agreement was needed rather than how much money crossed. Votes also arrive per validator, so one external deposit produces many rows that have to be collapsed to a single confirmed event. Because the same asset exists under a wrapped denomination here and a native one on its home chain, following supply means holding both sides and knowing which direction each leg went.

Bridged-supply accounting is the recurring request: how much of an asset exists as a wrapped representation, on which chain, against what was locked to back it. Route analysis is the second, measuring which corridors actually carry volume rather than which ones are connected, and it pairs naturally with venue data from Osmosis, where much of that supply ends up. Validator and reward accounting is the third, and it is specific to this chain, because rewards follow voting and signing participation rather than block proposal alone. Token analytics covers the cross-chain supply side of this work.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Axelar history is available now as a share or a file delivery, and streaming is provisioned on request. Say which connected networks matter, because the counterparty histories are scoped alongside this 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.