For a TON exchange deposit, use the address format supplied by the receiving platform. A bounceable address and its non-bounceable equivalent can identify the same underlying account, but that does not make the platform's deposit instructions interchangeable. Compare the decoded account, check the intended network and preserve any required deposit comment before sending.
Two representations can point to one account
TON's raw account identifier contains a workchain and an account ID. The user-friendly representation wraps that identifier with flags and a checksum. In familiar basechain addresses, an EQ prefix commonly marks a bounceable representation and UQ a non-bounceable one. Changing the representation does not create a new account or give anyone different signing keys. The TON address specification separates those display properties from the account identifier.
This explains a confusing experience: you copy an address from one application, paste it into another and see a different-looking string. It may be a legitimate conversion, or it may be an entirely different recipient. Comparing the opening characters cannot tell you which. A correct comparison decodes both strings and checks the workchain and full account ID. Do not treat a matching ending, an identical logo or an address-book label as equivalent evidence.
Check four questions before changing the format
| Question | Evidence to inspect | What it establishes | What it does not establish |
|---|---|---|---|
| Do both strings identify the same account? | Decoded workchain and full account ID | Whether the underlying destination matches | That an exchange will credit the deposit |
| Is this the intended network? | The deposit network and the wallet's selected network | Whether sender and receiver use the same ledger | That a similarly named token is accepted |
| Is the receiving account deployed? | Current account status in a TON explorer | Whether code is present and the account is active | Who controls the account or whether it belongs to your order |
| Does the platform require a comment? | Current deposit or order instructions | The reference needed for internal allocation | That a different address format includes that reference |
| Will the sending wallet accept the supplied format? | The actual review screen before signing | What the wallet is about to submit | That an unsupported form should be edited manually |
The last column is the part most quick answers miss. Address validity, account activity and exchange crediting are separate tests. A valid address can belong to the wrong person; an active account can still require a comment; a supported network does not prove that a platform accepts every asset on it. Keep these checks separate rather than reducing the decision to EQ versus UQ.
An inactive destination is a different issue from a deposit rule
A fresh TON account may not yet contain deployed wallet code. The official account-status documentation distinguishes nonexist, uninit, active and frozen states. Delivery depends on the message and any required initialization, not merely the visible prefix. A bounceable message to an undeployed account without suitable initialization can return instead of funding the destination as intended.
That does not justify a universal instruction to convert every exchange address to UQ. An exchange operates its own receiving infrastructure and decides how it recognizes deposits. Its displayed address may have operational meaning beyond what your personal wallet interface shows. If an exchange tells you to use a particular format, follow that instruction. If the sender refuses it, ask the recipient how that sender should proceed instead of experimenting with the full balance.
A deposit workflow that preserves the evidence
- Open the deposit page through the platform's verified website or app. Select the asset and TON network afresh rather than relying on an old screenshot.
- Copy the complete address and record any separate comment or memo. Keep the original instruction available while reviewing the sending wallet.
- If the wallet changes the displayed address, compare decoded account identifiers using trusted wallet or explorer functions. The change must be explainable without altering the recipient.
- Read the final signing screen. Check the asset, destination, amount and comment; do not assume the earlier paste survived every subsequent edit.
- After submission, retain the transaction reference and inspect its trace. Confirm the actual destination and outcome before treating a missing exchange credit as a reason to send again.
A small test can reduce the amount exposed to an unresolved recipient issue, but it is not automatically compatible with a deposit minimum or a time-limited order. Check those conditions first. Sending below a platform's minimum can create an additional manual-reconciliation problem rather than a useful test. Never assume that a successful transfer proves the next order has identical instructions.
Why an exchange may show a converted address
There is a concrete historical example of conversion in platform instructions: DigiFinex's May 2024 address notice says its withdrawals converted bounceable addresses to non-bounceable form. The same notice warns that old deposit addresses would not be credited automatically. These are platform-specific statements, not a current instruction for every exchange. They illustrate why a format conversion and an expired deposit address must not be treated as the same problem.
If a platform says an address expired, proving that its EQ and UQ forms match does not renew the deposit arrangement. If it asks for a comment, changing the format does not insert that comment. For jettons, the transfer also involves token contracts, so a rule about funding a new native-coin wallet is not a complete explanation of a token deposit. The existing USDT on TON guide covers that separate asset-and-comment workflow.
Resolve a mismatch before creating another transfer
If the decoded destination differs, stop and recopy the address from a verified source. If the destination matches but the sender rejects the representation, ask the receiving platform which format that sender should use. If the transfer already reached the intended account but your balance was not credited, provide the order reference, transaction hash and deposit comment to the platform. Do not send a second payment merely to make the first one visible.
Use the address validator as a format check and the memo and tag checker as a prompt to inspect the receiving instructions. When preparing a no-account swap, take the actual address and other deposit details from the current order. None of these checks promises automatic crediting or removes the service's AML review conditions.
FAQ
What is a bounceable TON address?
It is a user-friendly account representation carrying a bounceable-message flag. It can refer to the same underlying account as a non-bounceable representation, so the prefix alone does not identify a different owner.
How can I check a TON wallet address?
Check its full decoded account identifier and intended network, then verify the recipient through the receiving platform. Passing a checksum test only establishes format validity; it does not establish ownership or deposit support.
Why does a TON wallet address look different in another app?
Applications can present the same account using different flags or supported encodings. Compare the decoded workchain and account ID rather than the first few characters, and stop if those identifiers differ.