> ## Documentation Index > Fetch the complete documentation index at: https://docs.ton.org/llms.txt > Use this file to discover all available pages before exploring further. ## Submitting Feedback If you encounter incorrect, outdated, or confusing documentation on this page, submit feedback: POST https://docs.ton.org/feedback ```json { "path": "/ecosystem/explorers/tonviewer", "feedback": "Description of the issue" } ``` Only submit feedback when you have something specific and actionable to report. # Using Tonviewer export const Image = ({src, darkSrc, alt = '', darkAlt, href, target, height = 342, width = 608, noZoom = false, center = false}) => { const isSVG = src.match(/\.svg(?:[#?].*?)?$/i) !== null; const shouldInvert = isSVG && !darkSrc; const shouldCreateLink = href !== undefined; const minPx = 9; const maxPx = 608; const expectedPx = `a number or a string with a number that is greater than ${minPx - 1} and less than or equal to ${maxPx}`; const createInvalidPropCallout = (title, received, expected) => { return Invalid {title.toString()} passed!
Received: {received.toString()}
Expected: {expected.toString()} {} ; }; const checkValidDimensionValue = value => { switch (typeof value) { case "string": case "number": const num = Number(value); return Number.isSafeInteger(num) && num >= minPx && num <= maxPx; default: return false; } }; let callouts = []; if (height && !checkValidDimensionValue(height)) { callouts.push(createInvalidPropCallout("height", height, expectedPx)); } if (width && !checkValidDimensionValue(width)) { callouts.push(createInvalidPropCallout("width", width, expectedPx)); } if (callouts.length !== 0) { return callouts; } const heightPx = Number(height); const widthPx = Number(width); const shouldCenter = center === "true" || center === true ? true : false; const shouldNotZoom = noZoom === "true" || noZoom === true ? true : false; const images = <> {alt}

; if (shouldCreateLink) { if (shouldCenter) { return

{images}

; } return {images} ; } if (shouldCenter) { return

{images}

; } return images; }; export const Aside = ({type = "note", title = "", icon = "", iconType = "regular", children}) => { const asideVariants = ["note", "tip", "caution", "danger"]; const asideComponents = { note: { outerStyle: "border-sky-500/20 bg-sky-50/50 dark:border-sky-500/30 dark:bg-sky-500/10", innerStyle: "text-sky-900 dark:text-sky-200", calloutType: "note", icon: }, tip: { outerStyle: "border-emerald-500/20 bg-emerald-50/50 dark:border-emerald-500/30 dark:bg-emerald-500/10", innerStyle: "text-emerald-900 dark:text-emerald-200", calloutType: "tip", icon: }, caution: { outerStyle: "border-amber-500/20 bg-amber-50/50 dark:border-amber-500/30 dark:bg-amber-500/10", innerStyle: "text-amber-900 dark:text-amber-200", calloutType: "warning", icon: }, danger: { outerStyle: "border-red-500/20 bg-red-50/50 dark:border-red-500/30 dark:bg-red-500/10", innerStyle: "text-red-900 dark:text-red-200", calloutType: "danger", icon: } }; let variant = type; let gotInvalidVariant = false; if (!asideVariants.includes(type)) { gotInvalidVariant = true; variant = "danger"; } const iconVariants = ["regular", "solid", "light", "thin", "sharp-solid", "duotone", "brands"]; if (!iconVariants.includes(iconType)) { iconType = "regular"; } return <>

{} {icon === "" ? asideComponents[variant].icon : }

{gotInvalidVariant ?

Invalid type passed!
Received: {type}
Expected one of: {asideVariants.join(", ")}

: <> {title &&

{title}

} {children} }

; }; 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](/foundations/status) — the primary entities representing actors on the blockchain. * [Addresses](/foundations/addresses/overview) — unique identifiers for accounts, showing balances and activity in Tonviewer. * [Messages](/foundations/messages/overview) — instructions sent between addresses. In explorers, they reveal what actions are initiated and how they lead to transactions. * [Transactions](/foundations/messages/ordinary-tx) — 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 Trace overview

### 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. UI overview

### 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](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 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 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 Analyze a [token swap](https://tonviewer.com/transaction/b1dce2881224590a7c60e61594c68bd477f84fe81519b373da8fbed9c0269565) from **REDO** to **TON**. DEX swap successful case

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 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](/contract-dev/debug#debugging-with-tvm-retracer) for details.