Indexed AlgorandBlockchain Data

Algorand’s mainnet has been running since June 2019 on Pure Proof of Stake, where a verifiable random function privately selects a block proposer and a voting committee for each round, weighted by stake that never has to be bonded or delegated away. Agreement is reached before the next round begins, so the chain does not fork and a written round is settled. The native asset is ALGO, capped at ten billion and divisible into a million microalgos, and addresses are 58-character base32 strings. Tokens are not contracts, as on Cardano: an Algorand Standard Asset is created by a transaction and carried as ledger state, and a receiver has to opt in before it can hold one. Contracts, called applications, run TEAL programs on the Algorand Virtual Machine, can send inner transactions from their own account, and are commonly composed through atomic groups of up to sixteen transactions that succeed or fail together. Accounts also carry a minimum balance that grows with each asset and application they touch.

SonarX indexes rounds and their block headers, transactions and the groups they belong to, payments and asset transfers, asset creation, configuration and opt-in records, application calls with the inner transactions they generate, rekey operations, and account and asset balances. The same normalized model covers every network SonarX indexes, so Algorand activity can be aggregated alongside other chains rather than through a format only this ledger uses.

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

Finality removes work and the object model adds it back. Nothing has to be treated as provisional, so there are no orphaned rounds to withdraw and no confirmation depth to respect. What does need care is grouping and identity. The atomic unit can be sixteen transactions, so a swap read one transaction at a time looks like an unmatched transfer, and application calls emit inner transactions that move value without appearing in the outer transaction’s fields. Opt-in records mean an account with no balance row for an asset is a different fact from an account holding zero of it. Rekeying then splits control from address, so signing authority has to be tracked as its own history.

Issued-asset reporting is the first workload and the cleanest, because the opt-in rule makes holder sets exact rather than inferred: an asset’s holders are the accounts with a balance record for it, full stop. Settlement monitoring is the second, and immediate finality changes the question from “has this confirmed” to “what settled in this round”, which is a simpler reconciliation than on a probabilistic chain. Application-level analysis is the third, and the group is its unit, since a position change usually spans several transactions that only make sense together. Custody and controls auditing is a fourth, reading rekey history to show when signing authority over an account moved. RWA and tokenization analytics is the solution area this work sits in across the chains SonarX indexes, and Stellar is the usual comparison when the subject is issued assets.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Algorand history is available now, and streaming is provisioned on request. Say which asset IDs or applications matter, since that usually decides how much of the round history a workload really touches. 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.