Current security guidance advises users sending funds or using addresses in Telegram Mini Apps to confirm the entire destination address from a reliable source—never assuming safety or recoverability based only on the EQ or UQ prefix. The possibility of funds being "bounced" back after a failed transfer depends on the contract’s logic and the current state of the recipient account. Apps and wallets should display and request address information transparently to prevent errors or asset loss.
Difference Between Bounceable and Non-Bounceable Formats
Bounceable and non-bounceable address formats both represent TON accounts. The main technical difference is how the network handles messages if the recipient account is inactive. Sending to a bounceable address (prefix “EQ”) tells the network to try returning funds if delivery fails. Non-bounceable addresses (prefix “UQ”) do not request this safety mechanism, so lost funds are less likely to be returned if the address can't receive them.
These formats are simply different encodings, with a flag indicating bounce behavior. Both can point to the same underlying account, so the prefix does not guarantee a correct or recoverable transfer. Always verify the entire destination address through an official or trusted channel.
Network handling of a transfer is affected by both the bounce flag and the state of the recipient account. Reviewing the full address is essential—prefixes and appearance alone do not confirm accuracy or safety.
Why Address Prefixes Alone Are Not Sufficient
The EQ or UQ prefix on a TON address only shows how the message should be handled if delivery fails; it does not guarantee correct routing or recoverability. Both prefixes can represent the same wallet; using only prefix checks can create risk if the wrong format is copied or a mistake is made. For instance, sending to a non-bounceable address for an account that isn't deployed could result in permanent loss of funds.
Wallets and applications may display addresses in different formats for the same account. Only by confirming the full address and using official channels (such as verified QR codes or service links) can users be confident in their transaction.
For builders, relying on prefix recognition when handling transfers can result in technical support challenges and user error. Implementing clear address validation and highlighting full string checks increases safety and clarity for all participants.
Essential Steps Before Transferring Funds
Before sending TON or interacting with a dApp, always verify every character of the recipient’s address. Bounceable (EQ-) and non-bounceable (UQ-) addresses may point to the same account, but the bounce flag only controls message handling in specific scenarios and does not prove ownership or guarantee recovery.
TON’s security documentation highlights that if a transfer is sent to an inactive or non-existent address, the bounce setting affects whether the funds may be returned, but nothing ensures delivery or error reversal if the address is incorrect. Double-check the full address string using a trusted or official service inside the app or platform—avoid copying from chat messages or using shortened formats.
Review the network and wallet connection before transferring funds or connecting to services that use raw, bounceable, or non-bounceable address forms. Using the wrong address or format is not reversible, and small mistakes can result in lost assets.
Address mishandling is a leading technical risk for newcomers—not the protocol itself, but user confusion between address formats. Always validate the full destination, confirm network settings, and do not rely on just the EQ/UQ prefix.
When interacting with wallets or TON apps, copy the entire destination address from a reputable source, double-check before approving, and follow any requested wallet prompts. Treat shortcuts and visual cues as incomplete—attention to detail is critical with TON address formats.
For further guidance, see TON guides.
For related TON Drop Hub coverage, see TON guides.
Source reference: original source.