Indexed OsmosisBlockchain Data

Osmosis has produced blocks since June 2021, and it exists to be the trading venue for chains built with the Cosmos SDK, Cosmos Hub included. Validators run CometBFT under proof of stake, OSMO is the native token, and accounts are bech32 strings with an osmo prefix. What makes the chain unusual is where its exchange lives: the automated market maker is a module inside the protocol rather than a set of deployed contracts, so creating a pool, swapping through it and claiming incentives are transitions the chain performs itself. Later upgrades added concentrated-liquidity pools, where a position holds a tick range instead of a uniform share of one curve, and CosmWasm contracts beside the native modules. Two mechanisms shape the record. Emissions and liquidity incentives are handed out at a daily epoch boundary rather than continuously, and superfluid staking lets a bonded liquidity position also secure the chain, so the same capital is liquidity and stake at once. Almost every asset traded here arrived from another chain over IBC.

SonarX indexes Osmosis where the venue actually works: blocks and transactions with their typed messages, pool creation and pool state, swaps and the routes they took, liquidity positions and their lock-ups, epoch distributions, the denominations assets arrived under, and derived balances. Everything is normalized into the model SonarX uses across every network it covers, so this venue’s history compares directly with trading data from very different chains.

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

Because the exchange is protocol state, there are no swap logs to subscribe to and the pipeline follows the module’s own transitions instead. Routing is where that bites: one swap message can cross several pools, so price impact and the liquidity that absorbed it are visible only if the whole path is kept. Concentrated-liquidity positions add a second shape, since a position is bounded by a tick range rather than by a share of a single curve, and both kinds coexist in one history. Superfluid positions are the third, because the same bonded capital counts as liquidity and as stake, so an aggregate has to say which it means.

Liquidity-provider accounting is the recurring request: fees earned, incentives received and the divergence between holding a pair and pooling it, reconstructed per position rather than read from a dashboard. Execution research is the second, since routed swaps make this chain a good record of what size actually costs. Incentive-program analysis is the third, and it is the one that most needs epoch state, because a program’s real cost is emissions per pool over time. Interchain flow work is a fourth, following assets in and out over IBC channels. DeFi analytics covers position-level work across chains, and teams comparing pooled and order-driven markets usually pull Injective into the same warehouse.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Osmosis coverage is provisioned on request, so tell us the history depth and the delivery target and we will scope it. Say early whether pool-level detail or account-level detail is the priority, because that shapes 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.