Indexed TONBlockchain Data

TON, The Open Network, is a Layer 1 that Telegram’s engineers designed and that Telegram then walked away from in 2020, under pressure from an SEC action against its token sale. Independent developers have run the network since. It is sharded by construction: a masterchain carries consensus and configuration, workchains sit beneath it, and shardchains split and merge as load moves instead of staying a fixed set. Blocks are produced by a proof-of-stake validator set under Catchain, a Byzantine fault-tolerant protocol. Execution runs on the TON Virtual Machine, where code and data are both stored as cells. Every account is a smart contract, wallets included, and contracts never call each other directly: they send messages that are processed in later blocks, so one user action can span several of them. The native asset is Toncoin, ticker TON, divisible into a billion nanotons. Fungible tokens follow the jetton standard, which gives each holder a wallet contract per token rather than an entry in a ledger inside the token contract.

SonarX indexes TON as the protocol produces it: masterchain and shard blocks, transactions, the messages that move between contracts, account state, and jetton and NFT activity derived from the contracts that hold it. Those records are normalized into the model SonarX uses across every network it covers, so a TON question and a Cardano question can be answered in the same query language rather than in two pipelines.

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

TON chain indexing starts by giving up the idea of a single block height. A block belongs to a shard, identified by its workchain and shard prefix with its own sequence number, and shards divide and recombine under load, so the history is a tree to be walked rather than a line to be counted. Execution is asynchronous, so a transfer is a set of messages landing in different blocks and has to be stitched back into one economic event. Jetton holdings live in a wallet contract per holder, which turns token balance work into contract state tracking across very many small contracts. Addresses also have two spellings, raw and user-friendly, for the same account.

TON’s activity is consumer-shaped, and the analysis follows. Wallet and cohort work is the common request: small accounts created in bulk through applications, then followed over time to separate durable users from one-off activity, which needs address-level history rather than aggregates. Jetton distribution studies are the second, tracking an issuance from mint through the per-holder wallet contracts to the accounts that still hold it. Third is exchange and treasury reconciliation, where a desk’s internal records have to agree with the chain’s message history rather than with a summarized transfer feed. All three hit the same obstacle first: a naive count of transactions on TON counts messages, and messages outnumber the economic events they belong to. Wallet analytics covers the address-level side of this across chains, and teams comparing shard designs often pull MultiversX beside it.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. TON history is available now as a share or a file delivery, and streaming is provisioned on request. 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.