On this page
The essentials
- Read explorers without connecting or sharing a recovery phrase.
- One successful step need not mean overall success.
- Verify asset, final address and amount together.
What an explorer shows
An explorer displays blockchain account state and history. It helps verify a transfer independently of a sender’s screenshot. Ordinary viewing requires no wallet connection, signature or recovery phrase. If a site asks for them merely to search a hash, stop and check the site address.
An explorer does not control funds or establish an address owner’s identity. Nor does it expose an exchange’s full internal accounting. Successful receipt at a service address and credit to a customer account are related but different facts. Decide which fact you are checking.
Start with a hash or address
Opening the record from your wallet history is usually simplest. Alternatively, paste the hash into a verified TON explorer. A hash identifies a record, while an address shows an account’s history; address searches require locating the operation by amount and time.
Check mainnet versus testnet and the displayed timezone. If a hash search returns nothing, establish that it is a blockchain identifier rather than a provider request number. One interface’s empty result proves neither cancellation nor loss.
Separate user actions from transactions
A TON user action can launch messages between contracts. Each affected account processes an incoming message through its own transaction. An explorer may group these into a convenient operation summary or expose the detailed trace.
Read “success” in context: does it apply to a single step or the full operation? A straightforward GRAM coin transfer is usually easier to interpret than a swap or jetton send. For complex actions, follow the messages through to the expected recipient or output asset.
Check the asset and recipient
Compare the final destination with the original details rather than only abbreviated first and last characters. For tokens, verify the master contract and amount units. A USDT label alone does not rule out a namesake counterfeit. Payment verification needs the intended asset.
In a jetton transfer, technical token-contract addresses differ from the owner’s ordinary address. Do not assume every intermediate address belongs to an unexpected recipient. Establish the jetton wallet’s relationship to the owner and expected master through token details; if unclear, preserve the trace for informed review.
Example: what happened to 15 USDT
Imagine a 15 USDT transfer. Details show a small GRAM amount, a message to a jetton contract and a subsequent change in the recipient’s token balance. Looking only at the first GRAM movement is insufficient: it may fund execution rather than express the payment value.
The conclusion requires all the relevant facts: genuine USDT, amount 15, the intended destination owner and a completed trace. For an exchange payment, verify its deposit separately. This inspection does not establish withdrawal availability or legal fulfilment of every contractual obligation.
Read errors together with fees
For an error, identify its stage and any return messages. An outgoing message does not necessarily establish a completed payment. Conversely, an error does not guarantee zero costs: some computation may already have happened. The specific history determines the outcome.
Separate principal, related transaction costs and possible unused-fund returns. Do not add different currencies or treat a current fiat equivalent as the original coin amount. When wallet and explorer figures differ, compare scope first: one step or the whole trace.
An address is not a person’s name
An explorer may label services, but a public address does not reliably identify an individual. Do not infer personal connections or make accusations solely from nearby transfers. A shared service address can serve many customers, and a technical contract can process many operations. Your payment check needs its route and outcome. For a disputed order, retain messages and payment conditions too: an on-chain record establishes a technical event, not the entire agreement between the parties.
Save a verifiable conclusion
A useful check ends with a short record: network, asset, amount, address, hash, outcome and required comment if applicable. This is more useful than a contextless screenshot. Add the timestamp with timezone and any provider request reference for support.
Avoid publishing addresses and histories unnecessarily because they can link your activities. Hash inspection never requires revealing a recovery phrase. If explorers disagree or the trace is still processing, record that uncertainty and check again later rather than asserting an outcome from an incomplete page.
