Bounceable Address
TON address with the bounce flag set (EQ...). If the contract at that address fails to handle the message, the network automatically refunds the sender.
Aliases: bounceable, bounce address, EQ address
Bounceable Address is the friendly form of a TON address with the bounce flag enabled. In base64 it starts with EQ (mainnet) or kQ (testnet). When you send a message to a bounceable address and the receiver fails to process it, TON is returned to you automatically.
When to use it
Bounceable is the “safe” mode and the default for most cases:
- Transfer to a DeFi contract. If the transaction fails (out of gas, contract rejection), the TON comes back rather than being lost.
- Jetton transfer via the jetton-wallet. Standard jetton operations are bounce-aware — that’s part of TEP-74.
- Any call that might fail. DEX swaps, NFT mints, governance — bounce is on by default.
When not to use it
Bounceable is wrong in one case: sending to a contract that doesn’t exist yet. If the destination is a wallet contract that has never been deployed (a brand-new wallet that never received TON), bounce fails and the gas is burned. For that case use the non-bounceable form (UQ…).
Modern wallets do this automatically: they check the destination’s status and display EQ for existing contracts, UQ for fresh ones.
How to switch forms
In most UIs the same raw address (0:abc…) can be displayed as either EQ or UQ — they’re just two encodings of the same hash. SDKs expose a bounceable: boolean flag in address.toString(). The semantics are the same; only the network behaviour on failure differs.
A pitfall
If someone sends TON to your address with bounce=true and your wallet hasn’t been deployed yet, the TON bounces back to them and you receive nothing. So when receiving for the first time, ask the sender to use the UQ form, or deploy your wallet first (any outgoing transaction deploys it).