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.

Analyzing operations

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

Steps to analyze an operation

1. Identify the entry point

Start with the external-in message that initiates the trace. It defines the intent of the operation, such as a transfer, swap, or staking action.

2. Identify accounts

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

3. Inspect messages

For each edge, review its payload:

• 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.

5. Find the failure point

Even if all transactions succeed, failures can still occur due to message or payload constraints.

Failed use cases

The following examples illustrate common operation failures in Tonviewer. Each case demonstrates how to systematically analyze traces to identify the failure point, even when transactions appear to be successful or partially executed.

Jetton transfer

Analyze a jetton transfer attempt.

1. Identify the entry point

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

2. Identify accounts

• A — sender’s wallet contract (mintmachine.ton).
• B — jetton wallet contract governed by the jetton master.

3. Inspect messages

• A → B: jetton transfer message with 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. Identify the entry point

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

2. Identify accounts

• A — the user’s wallet.
• B — the NFT contract at address EQCo…gJdV.

3. Inspect messages

• A → B: NFT transfer message with 0.04 TON attached.
• B → A: bounce returning 0.0365 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. Identify the entry point

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

2. Identify accounts

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

3. Inspect 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. Identify the entry point

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

2. Identify accounts

• A — mintmachine.ton account.
• B — user’s jetton wallet.
• C — DEX jetton wallet.
• D — DEX smart contract executing the swap.
• E — jetton master (minter) of the token.
• F — DEX payout account (mergesort.ton).

3. Inspect 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, failed compute or action phases reported in the nodes.

5. Find the failure point

No failure point — the operation completed successfully.

Debugging with retracer

Sometimes, reading messages and transaction phases is not enough. A transaction may show successful compute and action phases, exit codes of 0, and no errors in messages — yet still produce no effect on-chain.

In such cases, you need to trace the TVM execution path. Retracer lets you replay the transaction and inspect what happened inside the virtual machine.

See Debugging with TVM Retracer for details.