Bounce Message
Automatic refund of a message and its attached TON to the sender when the receiver fails to process it. Triggered by the bounce flag.
Aliases: bounce, bounced message, refund message
Bounce Message is the automatic return that TON sends back to the sender when a receiving contract fails to process an internal message. It’s the network’s safety net: TON sent “to the wrong place” isn’t silently lost.
When it fires
A bounce happens when both conditions are met:
- The original internal message has
bounce=true. Wallets send transfers with bounce on by default, except when sending to an undeployed address. - The receiver’s compute phase fails with any non-zero exit code, or the destination doesn’t exist / is frozen.
In that case the network constructs a return message carrying the remaining attached TON (minus fees) and a small body with error info. The sender receives it as a new transaction.
Bounce body
The bounce body begins with the opcode 0xFFFFFFFF (signal that this is a bounce) and contains the first 256 bits of the original message’s body. That’s usually enough to identify the failed request: opcode and query_id.
When to send without bounce
Wallets disable bounce in two common scenarios:
- Transfers to a fresh address. The receiver’s wallet contract hasn’t been deployed yet, so a bounce would just burn gas. Addresses for non-existent contracts are commonly shown in the
UQ...(non-bounceable) form. - Plain TON transfers between users. If the receiver is a wallet rather than an application contract, bounce isn’t needed.
For DeFi operations bounce is almost always on: better to pay for the refund than lose funds when a contract fails.
A caveat
Bounce does not refund 100% of attached TON. The receiver’s compute fee is subtracted (even when it failed), as is the forward fee for the bounce itself, plus storage fee. For very small amounts a bounce can leave nothing to return.