Using Tonviewer

Tonviewer is a TON Blockchain explorer that allows you to inspect blocks, transactions, contracts, and tokens, as well as analyze activity.

High-level entities

High-level entities provide the foundation for exploring TON Blockchain, understanding and tracking operations. They are essential for identifying transactions and tracing data flow across the network.

• Accounts — the primary entities representing actors on the blockchain.
• Addresses — unique identifiers for accounts, showing balances and activity in Tonviewer.
• Messages — instructions sent between addresses. In explorers, they reveal what actions are initiated and how they lead to transactions.
• Transactions — records of executed messages. Explorers display their details linked to a specific address.
• Blocks — containers of transactions. In explorers, they expose block metadata and configuration parameters, allowing you to trace activity and understand how the blockchain operates.

Reading traces

Traces

In Tonviewer, operations are visualized through traces. A trace is a directed acyclic graph (DAG) where:

• transactions are nodes on an account’s address
• messages are edges between addresses

Using the UI

Tonviewer provides a visual interface for exploring traces:

• Hover over a node to see details about the account where a transaction succeeded or failed.
• Hover over an edge to inspect the message contents.
• Use Show details to examine full transaction and message information.

The UI may change, but the approach to reading traces remains consistent.

Steps to read a trace

1. Determine the operation

The external-in message initiates the trace and defines the operation, such as a transfer, swap, or staking action.

2. Clarify accounts’ roles

Examine the accounts involved — wallet addresses, jetton wallets, jetton master wallets, and DEX contracts. It clarifies the role of each account in the operation flow.

3. Read messages

Examine each message (edge in the trace). Its payload defines the intended actions and the transferred value:

• value — amount of TON or jettons transferred
• opcode — instruction type
• payload — instructions

4. Check transaction phases

Each transaction executes in phases. In the compute and action phases, an exit code of 0 indicates success; a non-zero code signals an error. This identifies which action succeeded and which failed.

5. Find the failure point

Some failures can occur even if all transactions are successful. Examine messages and payloads to identify where an operation was constrained or prevented from proceeding.

Failed use cases

The following examples illustrate traces where operations did not complete as intended, even when transactions appear successful. They demonstrate a general approach to reading traces and identifying the point of failure.

Jetton transfer

Analyze a jetton transfer attempt.

1. Determine the operation

At point A (mintmachine.ton), an external-in message initiates the operation, instructing a jetton transfer.

2. Clarify accounts’ roles

• A — sender’s wallet contract (mintmachine.ton), initiates the transfer.
• B — jetton wallet contract governed by the jetton master, holds the tokens and executes the transfer.

3. Read messages

• A → B: jetton transfer message with 0.2 TON attached to cover execution fees.

4. Check transaction phases

The transaction at B failed during execution, with a non-zero exit code.

5. Find the failure point

Exit code 48 per jetton contract logic indicates that there isn’t enough gas to complete the transfer. The attached TON was insufficient to cover execution and forwarding, so the contract aborted the transfer.

NFT transfer

Analyze an NFT transfer attempt.

1. Determine the operation

At point A (address UQDj…D0lN), the user’s wallet sends an external-in message to transfer an NFT.

2. Clarify accounts’ roles

• A — the user’s wallet, initiates the transfer.
• B — the NFT contract at address EQCo…gJdV, validates ownership and executes the transfer.

3. Read messages

• A → B: NFT transfer message with 0.04 TON attached.
• B → A: bounce returning 0.036514 TON.

4. Check transaction phases

The transaction at B failed in the compute phase, with an exit code of 401.

5. Find the failure point

According to the NFT standard, exit code 401 means that the sender is not the owner of the NFT. Because the ownership check failed, the contract rejected the transfer and returned the unused funds to A.

DEX swap

Analyze a token swap attempt from DYX to pTON.

1. Determine the operation

The trace begins at point A (the user’s mintmachine.ton contract). An external-in message initiates the token swap attempt.

2. Clarify accounts’ roles

• A — user’s mintmachine.ton account, sending the initial funds.
• B — user’s jetton wallet, holds the tokens.
• C — DEX jetton wallet, forwards tokens to the DEX.
• D — DEX smart contract executing the swap.
• E — jetton master (minter), authorizes token operations.

3. Read messages

• A → B: 0.3 TON transferred via a jetton transfer.
• B → C: jetton internal transfer to the DEX wallet.
• C → D: swap request sent to the DEX contract.
• C → A: return of excess funds.
• D → E: request to the jetton master.
• E → D: reply with exit_code: 962605456 (0x39603190).

4. Check transaction phases

Transactions in A, B, C, D, and E all completed with exit code 0. No phase errors were reported.

5. Find the failure point

The issue appears in the payload of E → D. According to Ston.fi docs, the exit_code: 962605456 corresponds to Swap out token amount is less than provided minimum value.

This explains why, despite all transactions succeeding, the swap reverted: the output did not satisfy the minimum slippage tolerance.

Successful use case

Analyze a token swap from REDO to TON.

1. Determine the operation

An external-in message arrives at point A (mintmachine.ton), initiating the token swap.

2. Clarify accounts’ roles

• A — mintmachine.ton account, provides initial funds for the swap.
• B — user’s jetton wallet, holds the tokens.
• C — DEX jetton wallet, forwards tokens to the DEX.
• D — DEX smart contract executing the swap.
• E — jetton master (minter), authorizes token operations.
• F — DEX payout account (mergesort.t.me), receives the swapped tokens.

3. Read messages

• A → B: 0.2 TON transferred via a jetton transfer.
• B → C: internal jetton transfer to the DEX wallet.
• C → D: valid amount forwarded to the DEX contract for swap execution.
• C → A: return of excess funds.
• D → E: request to the jetton master (minter) to mint/settle token movements.
• E → external-out: issues an external-out message — confirmation that the operation succeeded.
• E → F: sends an internal message to the payout pool account.
• F → A: forwards the swap result to the initiator (mintmachine.ton).

4. Check transaction phases

All transactions along the trace completed their phases without error, no warning markers; exit codes are 0. There are no bounces or failed compute or action phases reported in the nodes.

5. Find the failure point

No failure point — the operation completed successfully.