Skip to main content
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 participants 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 a specific address
  • messages are edges
Together, they form the sequence of account state changes triggered by a single external message. This view illustrates how execution propagates across contracts, making both the flow and the outcome of an operation clear.

​
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. Track participants
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. Locate the root cause
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 root cause of an issue, 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.
  2. Track participants
  • 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. Locate the root cause
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. Track participants
  • 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. Locate the root cause
Exit code 401 (per NFT standard documentation) 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 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. Track participants
  • A — user’s mintmachine, 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. Locate the root cause
The issue appears in the payload of E → D. The exit_code: 962605456 corresponds (per Ston.fi docs) 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.
⌘I