The Ethereum world has Etherscan — the universal tool for transaction inspection. In TON, the same role is filled by TonScan and its newer competitor Tonviewer. This guide walks through how to read data in both: what every field means, how to parse a chain of messages and where to find errors.
Which explorers exist on TON
As of 2026, the main five:
- tonscan.org — classic, the historical first.
- tonviewer.com — newer, by the Tonkeeper team.
- ton.cx — lightweight and fast.
- toncenter.com — official API + minimal UI from the TON Foundation.
- explorer.toncoin.org — simple and topic-focused.
For end-user purposes, tonscan.org and tonviewer.com cover 99% of cases. We’ll work on those examples below.
What a TON transaction is
Before reading the explorer, you need the transaction model. In Ethereum a transaction is one atomic action: a function call with all nested calls in a single bundle.
In TON it’s different:
- A transaction is the execution of one smart contract in response to one incoming message.
- If contract A sends contract B a message, you get two transactions — one on A (where it sent it) and one on B (where it received and processed it).
- They’re linked via the chain
in_msg → tx → out_msgs → next_tx → ....
In explorers this shows as a message tree.
iA simple TON transfer is one transaction? Not quite
Sending 1 TON from Tonkeeper to another wallet is 2 transactions on TON: tx-1 on the sender (deducted 1 TON, sent the message), tx-2 on the recipient (received 1 TON minus gas). A jetton (USDT) transfer is 3–4 transactions, because both sides’ jetton-wallets are involved.
Lookup by hash
The most common case: you have a hash and want to see the transaction.
- Open tonscan.org (or tonviewer.com).
- Paste the hash into the search bar — it looks like a long hex string
9f8d7e6c.... - Press Enter.
You’ll see the transaction page with fields:
- Hash — the hash itself.
- Block — which block (with workchain, shard, seqno).
- Time — when it was processed.
- Status — success (green tick) or error (red cross).
- In message — who sent what.
- Out messages — what was sent outward.
- Total fees — how much TON was spent on fees.
- EXIT_CODE — contract exit code.
Lookup by address
The second common case — viewing the history of your or someone else’s wallet.
- Copy the EQ…/UQ… address.
- Paste into search.
- The address page opens with:
- Balance — current TON balance.
- Jettons — list of jetton tokens with balances.
- NFTs — NFT list.
- Transactions — feed of all operations.
- State — contract state (uninitialized / active / frozen).
Tonviewer also shows an activity chart — handy for spotting transaction spikes.
Reading a normal TON transfer
Example: Alice sends 1 TON to Bob.
In the explorer you’ll see two transactions:
Transaction 1 — on Alice’s address:
- In message: empty (or signed by an external request from her wallet).
- Out messages: 1 message to Bob, value = 1 TON.
- EXIT_CODE: 0 (success).
- Total fees: ~0.005 TON.
Transaction 2 — on Bob’s address:
- In message: from Alice, value = 1 TON.
- Out messages: empty.
- EXIT_CODE: 0.
- Total fees: ~0.001 TON (deducted from value).
Bob received 0.999 TON, because 0.001 TON went to forward fee and storage fee on his side.
Reading a jetton transfer (USDT, NOT, any token)
A jetton is a separate smart contract per user, not a “balance entry”. So a transfer is more involved:
Alice sends 100 USDT to Bob. The chain in the explorer:
- Tx 1: Alice’s wallet → her USDT jetton-wallet (message “send 100 USDT to Bob”).
- Tx 2: Alice’s jetton-wallet deducts 100 USDT, sends a message to Bob’s jetton-wallet (creating it if it doesn’t exist).
- Tx 3: Bob’s jetton-wallet credits 100 USDT, sends a notification to Bob’s main wallet.
- Tx 4: Bob’s main wallet processes the notification (optional).
Tonviewer renders this as a single tree with a clean “Alice → 100 USDT → Bob”. TonScan shows it as a classic list — you click through related transactions.
Fields that scare beginners
EXIT_CODE
The TVM exit code from contract execution. Standard values:
- 0 — success, normal completion.
- 1 — alternative success (rollback succeeded).
- 2 — Stack underflow.
- 3 — Stack overflow.
- 4 — Integer overflow.
- 5 — Range check error.
- 8 — Cell overflow.
- 9 — Cell underflow.
- 10 — Dictionary error.
- 13 — Out of gas.
- 32 — Action list invalid (typical when sending an incorrectly formed message).
- 34 — Action invalid (e.g. wrong mode).
- 37 — Not enough TON.
- 38 — Not enough extra-currency.
Contracts can also define their own exit codes in the 256+ range. For example, a jetton-wallet throws code 706 “not authorized” when somebody tries to spend tokens not as the owner.
Full table — docs.ton.org/develop/smart-contracts/guidelines/error-handling.
Compute phase / Action phase
A TON transaction has phases:
- Compute — contract code execution in the TVM. EXIT_CODE lives here.
-
Action — handling of the actions the contract accumulated (sending messages, code change). It has its own
action_result_code. - Storage — storage fee deduction.
- Bounce — bounce handling (rollback on error).
If a transaction “failed”, check compute-phase EXIT_CODE first. If it’s 0 but something still went wrong — check action_result_code.
Bounce
If contract A sent a message to contract B and B couldn’t process it (failed with an error), the message bounces back to A. TonScan and Tonviewer mark this as “Bounced”. This doesn’t mean funds were lost — they returned to the sender.
!Bounceable vs non-bounceable
EQ… addresses are bounceable (if the recipient is inactive or errors, funds return to the sender). UQ… are non-bounceable (sent and forgotten, funds settle even on a “broken” address). Exchanges and P2P often require UQ for deposits to avoid bounce issues.
Common debugging cases
”I sent it but the recipient didn’t get it”
- Open your address in the explorer.
- Find the outgoing transaction with the right amount.
- Check status: success or error.
- If success — follow
out_messagesto the recipient’s address. - The recipient’s page should have an incoming transaction with the same parent hash.
If there’s no transaction on the recipient side — network delay (wait 1–2 minutes). If it’s there but the balance hasn’t updated — refresh the app or cross-check in another explorer.
”I paid a huge fee”
Open the transaction, look at total_fees. If it’s above 0.05 TON, something unusual is going on. Possible causes:
- Contract deployment (first transaction of a new dApp).
- Large
forward_feedue to payload size. - Long-tail
storage_fee(contract not used for a long time).
For more on how fees are computed — a separate article.
”I don’t understand why the contract failed”
Open the transaction in Tonviewer (better for debugging). Fields:
-
compute.exit_code— the main hint. -
compute.vm_log— execution log (if enabled). -
action.result_code— if compute itself succeeded.
If exit_code = 13 — out of gas. Codes around 700+ are typically custom contract codes (jetton, NFT). Google by the specific number and contract.
Small tricks
- Tonviewer shows a dApp preview if the transaction maps to a known project (STON.fi, DeDust). Useful to confirm “did I swap on the right curve”.
- TonScan has a public API for batch data processing. Useful for analytics or bots.
- Tonviewer offers OnchainAPI for each transaction — JSON via query.
- Both explorers give permanent links to specific transactions — easy to share in a Telegram chat.
What’s next
If you want to understand what makes up that fee and why it’s so low — the TON fees guide. If you work with testnet — how to switch and verify. If you’re just starting — creating a wallet.
Open TonScan
The universal TON network explorer for any transaction, address, token or NFT. Free, no signup.
→
Top comments (0)