# Using Tonviewer (https://docs-fpm2731fy-ton-core-docs.vercel.app/llms/ecosystem/explorers/tonviewer/content.md)
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]
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](/llms/foundations/status/content.md) — the primary entities representing actors on the blockchain.
* [Addresses](/llms/foundations/addresses/overview/content.md) — unique identifiers for accounts, showing balances and activity in Tonviewer.
* [Messages](/llms/foundations/messages/overview/content.md) — instructions sent between addresses. In explorers, they reveal what actions are initiated and how they lead to transactions.
* [Transactions](/llms/foundations/messages/ordinary-tx/content.md) — 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 [#reading-traces]
### 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 [#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 [#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 [#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 [#jetton-transfer]
Analyze a [jetton transfer](https://tonviewer.com/transaction/d5d50c3e5bde493ddc7853f784bdff75a37bf89473e77ba8d04615323c7c8117) 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](https://github.com/ton-blockchain/jetton-contract/blob/main/contracts/op-codes.fc#L33) 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 [#nft-transfer]
Analyze an [NFT transfer](https://tonviewer.com/transaction/d8b5dbfe1c115178f47b486d03982159ec8abe684cdbe1c75587293e877564d4) 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](https://github.com/ton-blockchain/token-contract/blob/main/nft/nft-item.fc#L65), 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 [#dex-swap]
Analyze a [token swap](https://tonviewer.com/transaction/fa8e119f8911d20bb078b9b81a3fc1f8ff2bcc723eda3ac7e873e97f455812e7) 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](https://docs.ston.fi/developer-section/dex/smart-contracts/v2/op-codes#transfer-exit-codes), 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 [#successful-use-case]
Analyze a [token swap](https://tonviewer.com/transaction/b1dce2881224590a7c60e61594c68bd477f84fe81519b373da8fbed9c0269565) 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, failed compute or action phases reported in the nodes.
5. **Find the failure point**
No failure point — the operation completed successfully.
## Debugging with retracer [#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](https://retracer.ton.org/) lets you replay the transaction and inspect what happened inside the virtual machine.
See [Debugging with TVM Retracer](/llms/contract-dev/debug/content.md) for details.