Indexed StellarBlockchain Data

Stellar has closed ledgers since 2014, and since the protocol upgrade of November 2015 it has run on the Stellar Consensus Protocol, a federated Byzantine agreement scheme in which each participant chooses the peers whose agreement it depends on. Ledgers close every few seconds, and a closed ledger is final. The model is accounts rather than outputs, but with a twist that shapes every query: an account holds XLM directly and holds every other asset in a trustline it must open first, subject to a minimum balance set by the network’s base reserve. XLM divides into ten million stroops. Assets are identified by a code plus the account that issued them, not by a contract address, and the ledger itself carries an order book, so offers, path payments and liquidity pools are protocol operations rather than applications, a design it shares with the XRP Ledger. General smart contracts arrived late, with the Soroban environment shipping to mainnet in February 2024. It runs WebAssembly, not the EVM.

SonarX indexes closed ledgers, transactions and the operations inside them, payments and path payments, offers and trades from the order book, trustline creation and authorization changes, account settings and balances, and Soroban contract activity. The same normalized model covers every network SonarX indexes, so Stellar payment data can be examined beside other chains’ transfers rather than in a format only this ledger uses.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery keeps the same dataset current to chain tip. Point-in-time balance tables are available for Stellar. Kafka streaming can be enabled for Stellar on request.

The operation is the unit of state change here, not the transaction, and one transaction can carry up to a hundred of them, so a transfer view is assembled from operations and their results rather than from transaction rows. Balances are not one field either: XLM sits on the account while every issued asset sits in its own trustline, keyed by code and issuer and carrying authorization flags that can be revoked, so one holder legitimately has many balance records. Path payments then consume offers across the order book, which means a single payment produces trades, and the assets on each side of it differ.

This is a payments network, so blockchain payment data here means corridor questions: which issuers moved value, between which anchors, in what asset, and what it cost. Stablecoin and issued-asset reporting is the first workload, and it reads trustlines rather than balances, because holder counts and frozen positions are trustline facts. Treasury and reconciliation work is the second, where an institution holding an issued asset has to restate positions as at a date across accounts it controls. Order-book research is the third, and it is unusual in being protocol-native: offers, trades and path-payment fills are ledger records, not contract logs, so market structure can be studied without decoding anything. Token analytics covers the issuance side across chains, and TRON is the frequent comparison when the subject is stablecoin volume.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Stellar history is available now, and streaming is provisioned on request. Say which issuers or assets matter most, because that usually decides how far back the ledger actually needs to be read. 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.