Skip to main content
TODO: check links 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
Trace overview

​
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.
  1. 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.
  1. Inspect messages
For each edge, review its payload:
  • value — amount of TON or jettons transferred
  • opcode — instruction type
  • payload — instructions
  1. 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.
  1. 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. NFT transfer
  1. Identify the entry point
At point A (mintmachine.ton), an external-in message initiates the operation, instructing a jetton transfer.
  1. Identify accounts
  • A — sender’s wallet contract (mintmachine.ton).
  • B — jetton wallet contract governed by the jetton master.
  1. Inspect messages
  • A → B: jetton transfer message with TON attached to cover execution fees.
  1. Check transaction phases
The transaction at B failed during execution, with a non-zero exit code.
  1. 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. NFT transfer
  1. Identify the entry point
At point A (address UQDj…D0lN), the user’s wallet sends an external-in message to transfer an NFT.
  1. Identify accounts
  • A — the user’s wallet.
  • B — the NFT contract at address EQCo…gJdV.
  1. Inspect messages
  • A → B: NFT transfer message with 0.04 TON attached.
  • B → A: bounce returning 0.0365 TON.
  1. Check transaction phases
The transaction at B failed in the compute phase, with an exit code of 401.
  1. 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. DEX swap
  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.
  1. 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.
  1. 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).
  1. Check transaction phases
Transactions in A, B, C, D, and E all completed with exit code 0. No phase errors were reported.
  1. 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. DEX swap successful case
  1. Identify the entry point
An external-in message arrives at point A (mintmachine.ton), initiating the swap.
  1. 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.t.me).
  1. 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).
  1. 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.
  1. Find the failure point
No failure point — the operation completed successfully.
⌘I