TON has several distinctions that a familiar wallet interface can hide: its native coin Gram (GRAM), formerly Toncoin (TON), versus Jettons, account identity versus address encoding, and a successful chain transaction versus a service's account attribution.
Understanding those distinctions helps explain why an EQ address may look different from a UQ address, why a comment can be essential, and why a token transfer can involve several linked messages.
TON at a glance
- Native asset: Gram (GRAM), formerly Toncoin (TON)
- The native coin of The Open Network (TON), used for network costs. Its market price can change.
- Tokens on the same chain: Jettons
- Jettons have their own contracts and identity. A familiar token symbol alone does not identify its issuer or prove authenticity.
- Address identity: Workchain plus account identifier
- Raw and user-friendly representations can encode the same account. User-friendly formats add checksum and handling flags.
- Familiar prefixes: EQ… and UQ… on mainnet basechain
- These commonly represent bounceable and non-bounceable variants. They do not prove that an account is initialized or that a service recognizes the asset.
- Memo or comment: Follow the receiver's current instructions
- If the receiving screen supplies a required value, preserve it exactly. Do not assume the field is optional or invent a placeholder.
- Costs and status: Read the actual operation and its trace
- Fees depend on message processing and network configuration. A chain event is separate from a service's internal account processing.
Native Gram versus USDT and other Jettons
Gram (GRAM) is the native coin of The Open Network (TON). Network costs are accounted for in this asset. A Jetton is a fungible token implemented through smart contracts on TON; it can represent a stablecoin or a different project entirely.
The TON website uses Gram/GRAM. Wallet's explanation dates the Toncoin/TON rename to 15 June 2026; the blockchain remains TON. The name change itself requires no swap, migration, activation or transfer. These naming sources were checked on 24 September 2026.
Native Gram (GRAM)
The account's native balance is separate from its token holdings. Gram's market price can move, and a displayed dollar estimate does not change the asset's denomination.
USDT on TON
An issuer-backed Jetton with a dollar price target. Verify its identity against Tether's official protocol information. A stable price target does not guarantee market value, availability or redemption for every holder.
The Jetton standard separates a master contract from individual holders' Jetton wallet contracts. These token contracts are distinct from the user's ordinary wallet account. A block explorer may therefore show more than one address involved in the same apparent token movement.
Names and symbols are display metadata. An unrelated token can imitate them, so verify the master contract through an authoritative issuer source. Do not paste an arbitrary token-contract address into a destination field intended for a user's account.
A native transfer and a Jetton transfer do different work. Their fees need not be equal, and holding a token does not by itself establish that the wallet can cover the operation's network costs. Wallet features that sponsor fees have their own scope and should not be assumed.
Sources: TON's Jetton overview, TEP 74 and Tether's protocol directory.
A wallet interface does not establish custody
A TON wallet can appear as an app, browser extension or interface inside a messaging app. Its location does not tell you who can sign transactions. Read the specific account mode: a custodial provider manages signing keys, while a self-custody wallet gives the user responsibility for them.
For self-custody, understand the documented backup and recovery process before relying on a balance. For a custodial account, understand the provider's access controls and processing rules. Avoid assuming that two products with similar names or the same app container share a custody model.
On TON, ordinary wallets themselves use smart contracts. Calling a wallet a regular wallet does not mean it is a non-contract account. Wallet versions and identifiers can affect the derived address, so account restoration should follow the wallet's own documented configuration rather than an assumption that one key always displays one address.
EQ, UQ and the account underneath
A TON account is identified by a workchain and an account identifier. The user-friendly form wraps that information with a checksum and flags. Common basechain mainnet examples start with EQ or UQ; other workchains and test contexts can produce different prefixes.
- Raw account form —
workchain:account_id - The workchain and 256-bit account identifier specify the account. This form has no user-friendly checksum or bounce/test flags, so it is mainly useful for technical inspection.
- Bounceable mainnet basechain form —
EQ… - A user-friendly encoding indicating bounceable handling. An equivalent UQ form can refer to the same account, but the message-handling flag differs.
- Non-bounceable mainnet basechain form —
UQ… - A user-friendly encoding permitting non-bounceable handling, including cases where a wallet account has not yet been initialized. It does not prove that the destination belongs to the intended person.
- Testnet-flagged basechain forms —
kQ… / 0Q… - These mark a testnet context. They must not be treated as mainnet alternatives just because the underlying account identifier looks familiar.
Two correctly derived EQ/UQ variants can identify the same account while requesting different handling. That is why matching the underlying account does not justify saying the outcomes will always be identical. Preserve the complete address supplied by the intended receiver and let compatible wallet software interpret it.
Do not change the prefix manually: the flags and checksum are encoded together. A checksum helps catch input errors, but it cannot tell you whether a valid destination belongs to the intended recipient.
Sources: TON address formats and TEP 2 address representation.
Account initialization and bounce behavior
An address can exist as a derived identifier before wallet code is deployed there. TON distinguishes states including nonexist, uninit and active. An uninitialized account can hold value without executable wallet code; an active account has deployed code and data.
Receiving value and initializing a wallet are therefore separate events. A non-bounceable message can fund an uninitialized account, but becoming active requires valid initialization data and successful execution. A UQ prefix alone does not certify that deployment has occurred.
Bounceability affects what can happen when a message cannot be processed. A bounce may return remaining value after applicable fees, depending on the message, processing outcome and available value. It is not a universal full-refund guarantee or a promise about timing.
If a transfer bounces, inspect the cause before repeating it. Blindly retrying or changing the address encoding can repeat the problem or change the handling in an unintended way.
Sources: TON account states and message sending modes.
Memo or comment: the receiver's requirements come first
TON messages can carry a comment. A receiving service may use that field as an account reference, especially when an address is shared. The field being optional in a wallet interface does not make it optional for every receiver.
Read the complete receiving instructions
If the receiver's current screen provides a required memo or comment, copy that exact value alongside the address. If it explicitly says no comment is needed, follow that instruction. If the screen is unclear or the sending app demands a value not supplied by the receiver, resolve the discrepancy before proceeding.
Do not invent a dash, a name or other placeholder. Do not replace a required reference with a personal message. An incorrect or missing reference can prevent automatic account attribution even when an on-chain transfer succeeds.
A public transaction record does not tell you a receiver's current field requirements. Nor can a general TON guide certify a specific service's processing behavior. The receiving screen and verified service documentation are the relevant sources for that operational rule.
Ordinary plaintext comments can be visible in transaction records. Keep private information and wallet secrets out of them. Different payload types have different meanings; a wallet should display and handle the requested operation clearly.
Protocol background: TON message comments. A service's account-reference requirement is separate from that protocol capability.
Follow the trace, not just one success label
TON contracts communicate through messages. A user action can cause a sequence of transactions across accounts; a trace links that sequence together. Jetton operations are a useful example because the user's wallet and token contracts can all participate.
When inspecting a public record, check the network, initiating account, destination, asset identity and the resulting messages. A successful initiating transaction does not by itself explain the outcome of every later contract action. Look for failed actions, bounced messages and the final token or native-balance changes.
An explorer is a view of blockchain data. It cannot prove a service has attributed the transfer to an internal account or finished its own processing. Preserve the transaction reference and the relevant public details if you need the receiver to investigate through its verified channel.
Source: TON transaction traces.
Fees and timing need an operation-specific estimate
TON's costs include storage, computation and message-related components. A simple native transfer, a Jetton transfer and a more complex contract call need not consume the same resources. The price of Gram (GRAM) also changes the dollar equivalent.
Use the wallet's current review of the actual operation, including any service charges it discloses. A network's performance figure should not be turned into a fixed end-to-end account-update promise; broadcast, chain processing and service processing remain different stages.
Source: TON transaction fee components.
Common TON questions when the result looks wrong
The required comment was missing or different
Do not assume successful chain execution means successful attribution. Compare the actual message with the receiver's requirements and use its verified support route with the public transaction reference. Whether the receiver can resolve it depends on its systems and policy; there is no general recovery promise.
The wallet shows a different address prefix
Check whether the strings are valid encodings of the same workchain and account identifier using trusted wallet or explorer tools. A prefix comparison alone is insufficient. If the intended network or handling remains unclear, resolve it instead of editing the text.
A message bounced
Inspect the trace and account state, including what value returned and which fees were charged. A bounce can reflect an execution or initialization issue. Repeating the same operation without understanding it is not a diagnosis.
A familiar token name appeared unexpectedly
Verify the Jetton master against the issuer's documentation. A symbol and image can be copied. An unsolicited token or message with an external link does not establish an obligation to connect a wallet or approve anything.
Someone offers to fix the wallet through a private message
Public transaction inspection needs no seed phrase or private key. Open the wallet's official support documentation independently. Do not trust a claimed identity because it appears beside a familiar avatar or because the sender knows a public transaction hash.
TON Connect and signing awareness
TON Connect is a protocol through which applications communicate with compatible wallets. Connecting an account and approving a transaction are different actions. Read the application origin and each wallet request; a familiar connection interface does not establish that the requested transaction is appropriate.
A normal public explorer lookup does not require signing access. If an application asks for signatures while claiming only to display public data, investigate the request before approving it. Disconnecting a session also should not be mistaken for undoing an already executed transaction.
Source: TON Connect documentation.
Frequently Asked Questions
Is Gram (formerly Toncoin) the same asset as USDT on TON?
No. Gram (GRAM), formerly Toncoin (TON), is the TON network's native coin. USDT on TON is an issuer-backed Jetton with a separate contract identity and dollar price target. Sharing a network does not make their balance, fee behavior or risks identical.
Can EQ and UQ strings represent the same account?
Yes, equivalent encodings can represent the same workchain and account identifier. They carry different bounce flags, so that does not mean every operation has identical behavior. Preserve the address supplied by the intended receiver instead of editing its prefix.
Do I need a memo or comment?
The receiver's current screen and documented requirements determine that. Copy a required value exactly. If the sender requires a comment that the receiver has not supplied, resolve the conflict before proceeding; do not enter arbitrary text or assume a missing comment cannot affect account attribution.
Does sending to a UQ address automatically initialize a wallet?
Not necessarily. An account can hold a balance in an uninitialized state without executable wallet code. Deployment requires valid initialization data and successful processing; receiving value and becoming an active wallet are different events.
Does a bounced message return the full amount immediately?
Do not assume that. Bounce behavior depends on message flags, account state, processing outcomes and available value for fees. Inspect the transaction trace and resulting balances instead of relying on a fixed refund amount or deadline.
Does a successful transaction prove a service credited an account?
No. A chain record can show execution and messages. The receiving service separately interprets the asset, reference and account relationship according to its own rules.
Is a wallet inside a messaging app always custodial?
No. The interface location does not establish custody. Check the specific product and account mode: who controls signing keys, how recovery works, and what permissions you approve.
Do I need to connect my wallet to inspect a transaction?
No. A public explorer can show an address or transaction without signing access. A request for a seed phrase, private key or unexplained signature is not necessary for public-chain inspection.