How to verify a TON jetton before sending or swapping

A similar name does not identify an asset

Jetton is TON’s fungible-token standard. Different issuers can use the same symbols, similar names and copied images. A familiar logo, a wallet balance or polished description therefore does not prove receipt of the intended asset.

The GRAM coin is the native network asset, not any jetton carrying the GRAM symbol. USDT and other tokens need their own identity checks. Check before swapping, sending or connecting to a page advertised in an unknown token’s description. Receiving spam does not itself require a response.

Find the master-contract address

A jetton has a master contract identifying its issuance. Each holder also has a separate jetton-wallet contract. Those addresses serve different roles. To compare token identity, you need the master rather than a user’s ordinary address or a random address in history.

Open token details in a verified wallet or explorer and look for the master, minter or issuing-contract field. Labels differ between interfaces. If the address’s role is unclear, do not compare it with the first code you find; establish what the screen actually represents.

Get the reference from a primary source

Obtain the reference contract from the issuer or official project documentation, opened independently of the suspicious token. Tether’s official supported-protocol list has a separate TON entry for USDT. Do not compare an Ethereum USDT contract with a TON address: these are different network implementations.

Check the domain and route to the page. A website promoted in token metadata can impersonate a project and publish its own address. Confirm through an already known official channel where possible. If a project provides no unambiguous contract, the correct finding is insufficient evidence, not a popularity-based guess.

Compare the complete address

Compare the complete master address rather than just its beginning and end. Explorers can display different valid representations of the same TON address. If formats differ, use the canonical identity in a reliable explorer or verified decoding tool; do not declare a match or counterfeit solely from appearance.

Also verify mainnet and the particular jetton wallet’s relationship to the expected master. A counterfeit contract can imitate metadata and balances. A sensible user-level baseline is a verifiable master reference, a matching identity and intelligible token details in a trusted interface.

Example: two USDT tokens

Suppose ordinary USDT receipt is followed by another token using the same symbol. The first links to the master listed by Tether; the second uses another contract and advertises a “claim bonus” page. A matching name does not make the second token Tether’s dollar asset.

Do not try swapping the suspicious token through its advertised page or pay for “activation.” Hiding spam with the wallet’s available controls is sufficient. A counterfeit’s presence does not automatically make the first token dangerous; check each issuance separately rather than generalizing from a shared symbol.

Authenticity is not purchase safety

A matching master answers a narrow question: is this the issuance identified by the source? It does not establish fair pricing, sufficient liquidity, absence of vulnerabilities or future saleability. A genuine project can still involve administrator powers and economic risks.

For a prospective purchase, separately examine purpose, administrator rights, issuance conditions and market access. Do not treat an explorer badge as an audit or recommendation. If your task is only to verify a payment, avoid unnecessary protocol interactions; identity verification itself requires no trade.

Viewing is not authorization

Reading token details usually requires only its address in an explorer. If you are instead asked to sign a transaction, the task has changed. Stop and establish what the signature authorizes: a transfer, contract call or another action. Authenticity checks should not silently become asset transfers. Likewise, adding a token to a display list does not establish its value. It only lets the interface show an existing network object and does not replace comparison with the issuer’s official master contract.

Record the conclusion before acting

Record the network, project name, master contract and official reference used for comparison. For a payment, include amount and final recipient. Stop and ask through an independent official channel if any material element disagrees.

Never send a recovery phrase “to verify the token” or sign a request supposedly proving authenticity. Ordinary verification uses public information. If the interface obscures addresses or the reference is doubtful, declining the operation is a complete and useful verification outcome, not a technical failure.