TON blockchain explorers

An explorer displays blockchain data through a searchable web interface. Use one to inspect an account, follow a transfer, or investigate contract execution.

What explorers show

TON explorers display account balances, Gram and token transfers, contract code and storage, transactions and messages. Available views depend on the explorer and its data sources.

Some explorers also show masterchain and shardchain block details, validator activity, and network metrics such as transaction volume, gas usage, and fees. Contract views may identify known contract types or show disassembled code.

Data sources

Explorers take data from TON Center's API v2 and API v3. The former is a direct wrapper for liteservers in TON, and the latter is an indexer — it organizes blockchain data and helps with sophisticated data retrieval. Indexers also connect transactions into traces and recognize common contract operations such as jetton or NFT transfers.

Actonscan

Actonscan is the official open-source TON explorer for smart-contract developers that combines account and transaction browsing with tools for inspecting and interacting with contracts.

Networks

Actonscan supports browsing TON Mainnet and Testnet networks, as well as custom networks managed by Acton Studio's virtual environments or configured with compatible API v2 and API v3 endpoints. To switch a network, use the menu on the top right.

Additionally, Actonscan links specify the network with ?network=mainnet or ?network=testnet. For example, a link to an address on the mainnet takes the following form: https://actonscan.com/address/EQCxE6mUtQJKFnGfaROTKOt1lZbDiiX1kCixRv7Nw2Id_sDs?network=mainnet.

Accounts and assets

Account pages show status, balances, history, jettons, and non-fungible tokens (NFTs). Contract views expose code and storage; available application binary interfaces (ABIs) describe messages and get-methods. Verified source files are available for contracts with matching published sources. The ABI catalog exposes known contract interfaces.

• Find an account or transaction.
• Check a transfer.
• Inspect jettons and NFTs.
• Inspect a smart contract and call get-methods.

Transactions and execution

A transaction page combines an operation summary, value flow, transaction details, and a message tree. Select individual transactions to inspect their incoming messages, fees, and execution phases. The debugger replays a transaction to expose its virtual-machine execution.

• Read a trace.
• Investigate a failed operation.
• Decode a message body.
• Replay a transaction.

Additional tools

• Blocks, elections, and configuration expose network activity and parameters.
• Address converter displays alternative address forms.
• Cell inspector parses BoC-serialized cell data.
• Transaction emulator evaluates transactions out of constructed messages without submitting them to the blockchain.

Find an account or transaction

To find an account, copy its address from a wallet app or the application being investigated. Paste it into search and press Enter. Actonscan accepts raw and user-friendly addresses. Check the address and network on the result, then open History for transactions, Tokens for jettons, or Collectibles for NFTs. An account can hold Gram without deployed code; check its status before treating it as an active contract.

To find a transaction, open its link from the wallet app. If there is no link, search the sender or recipient address and find the entry in History by time, counterparty, and amount. If application logs or an API response provide a transaction hash, paste it into search. A wallet submission may instead return a message hash — use message lookup to find its transaction.

Check a transfer

1. Open the transaction and check Event overview for the asset, amount, sender, and recipient.
2. Open Transactions and follow the messages to the recipient. A successful sender transaction shows that a message was sent; check the receiving transaction too.
3. Inspect the receiving transaction's Compute phase and Action phase for errors. Check Value flow or State changes for the resulting balance or owner.
4. Follow any bounce or refund before concluding that the transfer arrived.

For a jetton, compare the master address with the intended token. The jetton amount is in the message body; attached Gram pays for processing. For an NFT, compare the item address and owner. Names and images do not identify either asset. The account page shows the latest state; use the historical transaction to check what happened at a particular time.

Read a trace

A trace follows messages across accounts. Each node in Actonscan's message tree shows one account's transaction.

1. Start at the sender's transaction. Event overview summarizes recognized operations, but its label does not establish that every step succeeded.
2. Follow the message to the next account. Select its node and check Message route, attached Gram, and Parsed body.
3. Check Compute phase and Action phase, then follow outgoing messages until reaching the intended recipient, a bounce, or a refund.
4. Use Value flow and State changes to confirm the result. If a branch is pending or missing, let the explorer load or index it before declaring failure.

This NFT mint trace runs from a wallet to a collection and then to an NFT item. Select each node to distinguish the wallet's request from the item's deployment.

Investigate a failed operation

Find the transaction that should have produced the missing result. One operation can span several transactions, and a successful sender transaction does not establish that the recipient accepted its message.

1. Follow the trace from the sender to the intended recipient.
2. Select the receiving transaction. Check Compute phase for its success flag and exit code. A skipped phase differs from failed execution.
3. Check Action phase separately: computation can succeed while an outgoing action fails.
4. Follow any Bounced message or refund. Not every failed request bounces, and fees can reduce returned Gram.
5. If the phases succeeded but the result is missing, inspect the decoded response and refund branch. A contract can reject a request through its own messages without a TVM error.

In this failed jetton transfer, the receiving jetton wallet's compute phase exits with 48, labeled WalletErrors.NotEnoughGas by its ABI. The failure belongs to the receiving transaction; 48 is a contract-specific code. Record the failing account, transaction link, and exit code before changing the contract or resending the request.

Inspect jettons and NFTs

Jettons

1. On the owner's account, open Tokens and select the jetton. Its balance belongs to a separate jetton wallet contract.
2. Open that wallet and check its owner and jetton master addresses. Compare the master address with the one supplied by the token project or application.
3. Use the token's decimals to interpret the raw amount. The jetton wallet's Gram balance pays fees; it is not the token balance.

To verify the wallet relationship, call get_wallet_data on the jetton wallet using the get-method steps. See jetton wallet data for the returned fields.

NFTs

1. On the owner's account, open Collectibles and select an item, or search its address directly.
2. Check the item address, owner, and collection. The address identifies the NFT; its name and image can change or be copied.
3. To check a past owner, open the item's History and inspect the transfer. The account page shows the latest owner.

Missing images or metadata do not establish that a token is absent. Check its contract address and account state.

Inspect a smart contract

Open a contract address in Actonscan. For example, open the Tether USD (USDT) master.

1. Check the account status. An uninitialized account has no deployed code.
2. Open the Contract tab. Use Source for published code, Storage for current account data, and ABI for recognized messages and methods.

Call a get-method

Get-methods (or getters) are used to read contract state without sending a transaction or modifying the state.

1. On the contract page, open the Methods tab and select a method. Most of the get-methods of standard contracts do not require arguments.
2. Select Run and inspect the returned values.

Decode a message body

Select the message in a transaction's trace. An internal message's value is attached Gram; its body can contain contract-specific data such as an opcode and a jetton amount.

1. Check Message route for sender and recipient.
2. Under Message data, inspect the opcode and expand Parsed body with Show, if available.
3. Interpret fields using the receiving contract's interface. A decoded opcode identifies a requested operation; it does not establish that the contract completed it. Check the receiving transaction's execution result.

If the body is not decoded, select Copy raw body and paste it into Actonscan's cell inspector. Inspect the bits and references.

If the contract publishes a TL-B schema, use Parsing options to parse the body with that schema. An unknown opcode may be valid for a contract the explorer does not recognize.

Replay a transaction

Replay a transaction when its exit code and messages do not explain a contract failure. Select the receiving transaction that ran the relevant code.

1. Select Debug beside Message route. It allows replaying historical transactions.
2. In Disassembled, step through the instructions and inspect the stack and gas usage before the failure. Use Sources if source-level mapping is available.
3. Compare the replay with the recorded Compute phase result on the transaction page.

There, Edit & emulate changes inputs to simulate another outcome — that result did not occur on-chain. Neither Debug nor Edit & emulate actions submit a message.