USDT on TON is a Jetton, distinct from the native coin Gram (GRAM), formerly Toncoin (TON). A familiar wallet screen can hide several contract and message layers behind one token entry.
This guide explains those layers and the comment field. When a receiver requires a comment, that current requirement matters even if the sender's wallet presents the field as optional.
The master identifies the Jetton
Tether's protocol directory lists the TON USDT master as EQCxE6mUtQJKFnGfaROTKOt1lZbDiiX1kCixRv7Nw2Id_sDs. The master identifies the token. It is not a personal receiving address or an instruction to interact with the contract.
The Jetton model separates the master from owner-specific Jetton-wallet contracts. A user's ordinary TON wallet and the Jetton wallet holding that user's token balance have different roles. An explorer can show several associated addresses during one operation.
A copied token name or image does not establish the master identity. Verify the complete master using issuer information. A wallet's trust badge can be a useful interface feature, but it does not replace the source identity.
Sources: Tether's protocol directory and TON's Jetton standard. Native Gram has a separate balance and role in ordinary execution costs.
TON remains the network name; GRAM is the coin's current ticker. Naming sources, checked 24 September 2026: TON and Wallet's naming explanation.
Wallet contracts and address encoding
TON wallets are smart contracts. The user-facing address format includes a checksum and flags alongside the account identity. Bounceable and non-bounceable encodings can refer to the same underlying account with different message-handling flags.
Common mainnet user-friendly forms begin with EQ or UQ, corresponding to bounceable and non-bounceable encoding. These prefixes are not two token standards and do not identify two separate balances. Raw account addresses use another representation.
Bounce behavior interacts with account state and the message being processed. An uninitialized account is a different state from an active contract. The correct handling depends on the wallet's operation and current documentation, not a universal rule that one prefix is always safer.
Do not edit an address's prefix or invent an encoding to make an interface accept it. See TON address formats and account states for the protocol distinctions.
The receiver decides whether a comment is required
A comment can carry information that a receiver uses to associate an operation with an internal account. Some receivers use separate addresses; others use shared-address arrangements or require additional identifying text. A general TON article cannot infer the current policy.
If the receiver's current authenticated screen requires a particular comment, that requirement takes precedence over a sender's generic optional label. Omitting or changing it can affect account attribution even when the chain operation succeeds.
A field marked optional in one wallet describes that interface, not every receiver's accounting. Arbitrary text is not an acceptable substitute for a required reference. If instructions conflict or a sender cannot represent the required information, resolve the conflict through the verified receiver documentation.
A missing reference does not justify a universal recovery promise. An explorer can preserve the actual message evidence, but it cannot decide a receiver's attribution policy or guarantee correction.
Jetton operations can involve several messages
TON execution is message-based. A Jetton operation can involve a user's wallet, a Jetton-wallet contract, the corresponding receiving Jetton wallet and additional messages defined by the operation.
A top-level wallet transaction is therefore only one part of the trace. Subsequent execution results and token movement need their own interpretation. A wallet's compact success view may summarize activity that an explorer presents as multiple transactions.
Notifications and excess-value handling belong to the Jetton message design. They should not be shortened into a promise that every failure automatically returns the original value or every application immediately updates its display.
The Jetton specification and TON trace documentation explain the relationships. A complete investigation follows the relevant messages and results, not only the first transaction badge.
Fees need an operation-specific estimate
Ordinary execution on TON involves costs in Gram (GRAM). Computation, message forwarding, storage and other components can matter. A Jetton operation has different work from a simple native-asset movement.
The initial amount attached to a message, the amount consumed by execution and any later excess handling are different quantities. A quoted reserve is not automatically the final fee. Product-sponsored costs are another arrangement that must be documented for the product.
Do not promise that 0.1 GRAM covers a fixed number of USDT operations. Account state, the operation and current parameters affect costs. A reserve estimate should be read in the context of the current wallet operation.
For unit illustration only, 0.02 GRAM at a hypothetical price of $5 per GRAM equals $0.10. That example is neither a current price nor a fee quote. Calling the same quantity a fraction of a cent under those assumptions would be incorrect. See TON's fee components.
Custody inside a messaging-app interface
A wallet visible inside a messaging application can still use different custody models. One product may manage an account for the user, while another exposes a self-custody wallet. The interface's location alone does not establish who controls the keys.
Token support, comment handling and fee sponsorship are product features. They should be verified for the exact product and version. A TON feature does not prove that every messaging-app wallet exposes it identically.
A connection request and a signing request are also different. Read what authority a request asks for. Public balance inspection requires no recovery phrase, and an unsolicited contact's familiarity with a transaction does not prove a legitimate support role.
A token display can lag or omit an entry without changing the on-chain record. Check the master, owner relationship and trace before drawing conclusions. Keep wallet secrets out of screenshots or investigation notes.
How TON fits into the wider USDT picture
USDT on TON has a Jetton identity and message model. USDT on TRON uses TRC-20 contract execution, while Ethereum uses an ERC-20 context. The similar price target does not make address formats, fee assets or account-reference requirements interchangeable.
Changing a wallet's selected network cannot relocate an existing token balance. A cross-chain mechanism has its own costs and dependencies, and its resulting token must be identified separately.
Read the TON network and Gram guide for account/bounce concepts, the USDT overview for issuer versus representation, and the network comparison for cost units and settlement stages.
Frequently Asked Questions
Is USDT on TON the same asset as Gram (formerly Toncoin)?
No. USDT is a Jetton with a master and owner-specific token-wallet contracts. Gram (GRAM), formerly Toncoin (TON), is the TON network's separate native coin.
Is the Jetton master a personal receiving address?
No. It identifies the token contract. A user's wallet and owner-specific Jetton wallet serve different roles.
Do EQ and UQ necessarily identify different accounts?
No. Bounceable and non-bounceable user-friendly encodings can refer to the same underlying account with different flags.
Can I leave a required comment empty because my wallet says optional?
No. The receiver's current requirement determines the account reference it needs. Missing or altered text can affect attribution despite chain success.
Does 0.1 GRAM guarantee dozens of USDT operations?
No. Costs depend on operation and account state, current parameters and product behavior. There is no fixed operation count guaranteed by that balance.
Does the first successful transaction prove every Jetton message succeeded?
No. A Jetton operation can span multiple messages and transactions. Inspect the relevant trace and token results.