25 Feb•

development•9 min read

TON on-chain data analysis: quickstart on Dune

Daniil Okhlopkov

This article is contributed by Daniil Okhlopkov. The views expressed are those of the contributor and do not necessarily represent the opinions or endorsements of TON. This content is for informational purposes only and should not be considered financial or investment advice.

With TON now the exclusive blockchain for Telegram’s mini app ecosystem, Web3 is reaching over 950 million users—bringing crypto into the hands of everyday people like never before. But with this kind of explosive growth, how do we track what’s actually happening on-chain?

This is where data comes in. As TON’s ecosystem expands, on-chain analytics are key to understanding user behavior, adoption trends, and DeFi activity. In this article, we’ll break down TON’s architecture and how you can use Dune’s blockchain data tools to make sense of this fast-growing network.

TON Blockchain: architectural features

In TON Blockchain's unique asynchronous architecture, transactions are driven by messages—data packets exchanged between users, applications, and smart contracts. Each message carries specific instructions for the recipient, such as updating storage or initiating further messages, and can be inbound (sent to a contract) or outbound (sent from a contract).

To ensure messages are processed in the correct order, TON employs Logical Time (LT) to sequence events. Unlike traditional blockchains that process transactions sequentially, TON’s asynchronous nature and sharding allows any single action—for example, a DEX swap—to generate multiple messages which may be processed in multiple blocks. This design enables high scalability and parallel transaction processing, making TON well-suited for handling large transaction volumes efficiently.

Because of these structural differences, TON operates differently from EVM-based chains, which can make it challenging to onboard new builders into the ecosystem. To bridge this gap, TON Foundation has organized TON’s blockchain data into a public data lake (see ton-etl for details), making on-chain data more accessible and allowing analysts to work with familiar tools like SQL and Dune.

This guide will use Dune as an example to explore and analyze TON Data. A full list of supported tables is available in the official Data Catalog.

Getting started with TON data on Dune

Dune is a blockchain analytics platform that simplifies querying, visualizing, and interpreting on-chain data. It supports both EVM and non-EVM chains, including TON, allowing users to analyze public datasets, run SQL queries, and compile them into dashboards.

To get started:

Sign up for a free account on Dune.
Once registered, click Create, then select New query from the dropdown menu.

Understanding TON data on Dune

All available data on Dune can be divided into the following categories:

Raw data
Decoded data
Views and materialized views
Off-chain data uploads

Tables: blocks, transactions, and messages

TON Blockchain’s raw data is presented in a handy tabular format:

ton.blocks
ton.transactions
ton.messages

These tables contain fundamental and low-level information about TON’s network activity, including account states, flags, opcodes, sources and destinations of the interaction.

Querying TON transactions

Let’s write our first query. For each date in the last 30 days, we’ll calculate the average number of transactions per second.

SELECT
    block_date,
    COUNT(*) * 1e0 / (24 * 60 * 60) AS tps_avg
FROM ton.transactions
WHERE block_date >= NOW() - INTERVAL '30' DAY
GROUP BY 1

Source: https://dune.com/queries/4681120

We can calculate the same transaction count not only using the ton.transactions table but also ton.blocks and ton.messages. Note that some transactions do not generate any messages, such as system tick-tock transactions by Elector Contract.

Source: https://dune.com/queries/4711221

Direction of a message

Source: https://docs.ton.org/v3/documentation/smart-contracts/message-management/messages-and-transactions

In TON Blockchain, a transaction has one incoming message (excluding some special cases) but can generate multiple outgoing messages (including zero), forming a graph-like structure that's complex to analyze. Most of the messages have two transactions involved—one for source and another for destination. To make data structure immutable, those messages are stored twice and ton.messages table includes a "direction" column with:

‘in’: Generated once a message is sent
‘out’: Generated once a message is received

Note that there are three types of messages:

External: Source is null, only direction = ‘in’ is present
Internal: Both source and destination are non null, both direction = ‘in’ and direction = ‘out’
Logs (also known as External Out): Destination is null, only direction = ‘out’ is present

If you are filtering messages, it is recommended to add a direction filter. For most analyses, it is better to use direction = ‘in’ if you don’t need to check the resulting transaction, and direction = ‘out’ otherwise.

For example, to find who executed a smart contract, filter for direction = ‘in’ and destination = [contract address]. This structured approach helps navigate TON’s asynchronous message-driven architecture.

How to make queries faster

TON’s blockchain produces terabytes of data, meaning poorly optimized queries can be slow. To write fast queries, you need to select only the data you actually need—the columns and date partitions.

When you do SELECT COUNT(*) FROM ton.transactions, you load more than 2 billion rows—that takes a lot of computation and your query may take a while. For the majority of the analysis, you need to work with the latest data only. All the raw TON tables are partitioned by the “block_date” column so each time you filter by it, you load less data and make your query faster.

To optimize queries:

Don’t use SELECT: Read only columns you actually need
Filter by block_date: Read only rows you actually want to

Address format

There are several widely used ways to present a TON Blockchain address: raw bytes (starts with ‘0:’), user-friendly (starts with ‘EQ’), and bounceable user-friendly (starts with ‘UQ’). The upper raw format is used in all Dune tables.

If you need to cast a user-friendly address to a raw format or vice-versa, you can use these exclusive transform functions on Dune:

ton_address_raw_to_user_friendly()
ton_address_user_friendly_to_raw()

For more details, check out the TON-specific Dune functions.

Why is this useful? Sometimes, TON wallet addresses appear in a shortened format in wallets or screenshots. This query helps retrieve the full address from its abbreviated version.

Transaction hash formats

Imagine you found an interesting transaction on TON and want to see its representation in Dune. You may notice that the format of transaction hash in Dune tables differs from the one you see in Tonviewer:

Tonviewer: 692263ed0c02006a42c2570c1526dc0968e9ef36849086e7888599f5f7745f3b
Dune: aSJj7QwCAGpCwlcMFSbcCWjp7zaEkIbniIWZ9fd0Xzs=

Use this snippet to convert Tonviewer’s format to the Dune’s:

SELECT *
FROM ton.messages
WHERE tx_hash = to_base64(
    from_hex(            
        '692263ed0c02006a42c2570c1526dc0968e9ef36849086e7888599f5f7745f3b'
    )
)

Tables: jetton events, DEX trades and DEX pools

Some on-chain activity has been decoded and presented in a handy tables, such as:

Ton.jetton_events: Transfers, mints, and burns of jetton tokens
Ton.dex_trades: Trades made on decentralized exchanges (DEXs) and launchpads
Ton.dex_pools: Snapshots of LP pool TVL at each block

There is more decoded data yet to come. Tables for NFT activity may already be available, so be sure to check the full list of tables here: TON Data Catalog

Let’s calculate the total transaction volume and number of active wallets that used USDT on TON over the past 30 days:

SELECT
    block_date
    , SUM(amount) * POWER(10, -6) AS volume_usd
    , COUNT(DISTINCT source) AS active_wallets
FROM ton.jetton_events
WHERE 1=1
    AND block_date >= NOW() - INTERVAL '30' DAY
    AND jetton_master = UPPER('0:b113a994b5024a16719f69139328eb759596c38a25f59028b146fecdc3621dfe')  - USDT jetton master
    AND type = 'transfer'  -- only transfers
    AND tx_aborted = FALSE  -- only successful trx
GROUP BY 1
ORDER BY 1 DESC

Source: https://dune.com/queries/4711590

To find the addresses with the highest DEX trading volume in the last 30 days, you can use the ton.dex_trades table:

SELECT
    GET_HREF(
    'https://tonviewer.com/' || trader_address,
    trader_address
    ) trader,
    SUM(volume_usd) volume_usd
FROM ton.dex_trades
WHERE block_date >= NOW() - INTERVAL '30' DAY
GROUP BY 1
ORDER BY 2 DESC
LIMIT 100

Source: https://dune.com/queries/4711814

Dune’s GET_HREF function allows you to add clickable links to your table, making your queries and dashboards more interactive and user-friendly.

Materialized views

A materialized view is a SQL query transformed into a real table to simplify calculations of more complex queries.

Jetton metadata latest values

Some jettons allow metadata updates even after contract deployment. To track these changes, all snapshots of metadata values are stored in ton.jetton_metadata. That said, it’s more practical to use the latest value of a jetton metadata to extract decimals or symbols. That’s why we created this materialized view: dune.ton_foundation.result_ton_jettons_metadata_latest_values (Source query: https://dune.com/queries/4412605)

DEX pools latest and daily values

The ton.dex_pools table contains all snapshots of a liquidity pool’s TVL. However, most queries only require:

Latest values: dune.ton_foundation.result_dex_pools_latest (Source query: https://dune.com/queries/4423827)
Daily values: dune.ton_foundation.result_dex_pools_daily (Source query: https://dune.com/queries/4414366)

Jetton and TON daily prices

When working with multiple tokens, determining their USD or TON values is essential. The price of a jetton can be defined using the ton.dex_trades table, but if you need daily price data, you can use the ton.prices_daily table. If you’re interested in how we generate this price feed for TON, jettons, LP, and SLP tokens from raw data, you can explore the code here: GitHub.

Bonus: labels

At TON Foundation, we find and label addresses that belong to popular DeFi, GameFi, and other apps built on TON. All labels are stored in github and uploaded to Dune (table dune.ton_foundation.dataset_labels).

You can use the labels like this:

SELECT
    COUNT(DISTINCT M.source) total_users
FROM ton.messages M
INNER JOIN dune.ton_foundation.dataset_labels L
    ON M.destination = L.address
WHERE 1=1
    AND M.direction = 'in'
    AND L.organization = 'evaa'

Check Application Activity dashboard to see how these labels can be used: https://dune.com/ton_foundation/application-activity.

Continue exploring TON data

Want to dive deeper? For additional materialized views and resources, check out:

TON Quick Start
Popular dashboards on Dune
- Application Activity
- STON.fi Analytics

Join the TON Data Hub community

Stay updated with the latest news, integrations, and data insights. The TON Data Hub is a space for devs, analysts, and ecosystem contributors to collaborate.