STON.fi V2 Refund Address Explained: Where Failed Swaps Go
STON.fi V2 can encode a custom refund_address so returned assets do not have to go back to the starting wallet. That is programmable failure handling, not a hidden default.
🔥 What Changes in a V2 Swap
- receiver_address gets the tokens when the swap succeeds.
- refund_address gets funds when the requested swap cannot finish.
- excesses_address gets leftover TON after processing.
Those roles are not interchangeable. Sending output to one wallet does not automatically send refunds there too.
🚀 Why the Failure Path Exists
A STON.fi swap can look like one click, but TON execution is a chain of async messages. V2 can refund on low liquidity, zero output, output below min_out, a locked pool, an expired transaction, or invalid gas.
min_out and the deadline decide whether the result is still acceptable. The refund address only answers where value should land after a protected fail.
🧠 A Simple Failure Flow
1. The transaction names receiver, refund address, min_out, and deadline.
2. The Router sends the request to the Pool.
3. The Pool tests whether the conditions can be satisfied.
4. Success follows the receiver path. A refundable fail follows the encoded refund destination.
Omniston keeps refund_address optional. Leave it out and funds return to the sender.
⚡ Payloads and Hard Limits
STON.fi V2 can attach refund_fwd_gas and a refund_payload so a contract receives context with the returned funds. That helps bots and dApps only if the destination can handle the asset.
It cannot turn a multi-step route into one atomic undo. If Token A already became Token B, a later fail may return the intermediate token.
If an app cannot explain why a refund goes elsewhere, keep the sender default and use the official SDK.
Would you route failed STON.fi V2 swaps to a recovery wallet or back to the user? 👇
Drop the failure case you would test first in an integration.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
STON.fi V2 can encode a custom refund_address so returned assets do not have to go back to the starting wallet. That is programmable failure handling, not a hidden default.
🔥 What Changes in a V2 Swap
- receiver_address gets the tokens when the swap succeeds.
- refund_address gets funds when the requested swap cannot finish.
- excesses_address gets leftover TON after processing.
Those roles are not interchangeable. Sending output to one wallet does not automatically send refunds there too.
🚀 Why the Failure Path Exists
A STON.fi swap can look like one click, but TON execution is a chain of async messages. V2 can refund on low liquidity, zero output, output below min_out, a locked pool, an expired transaction, or invalid gas.
min_out and the deadline decide whether the result is still acceptable. The refund address only answers where value should land after a protected fail.
🧠 A Simple Failure Flow
1. The transaction names receiver, refund address, min_out, and deadline.
2. The Router sends the request to the Pool.
3. The Pool tests whether the conditions can be satisfied.
4. Success follows the receiver path. A refundable fail follows the encoded refund destination.
Omniston keeps refund_address optional. Leave it out and funds return to the sender.
⚡ Payloads and Hard Limits
STON.fi V2 can attach refund_fwd_gas and a refund_payload so a contract receives context with the returned funds. That helps bots and dApps only if the destination can handle the asset.
It cannot turn a multi-step route into one atomic undo. If Token A already became Token B, a later fail may return the intermediate token.
If an app cannot explain why a refund goes elsewhere, keep the sender default and use the official SDK.
Would you route failed STON.fi V2 swaps to a recovery wallet or back to the user? 👇
Drop the failure case you would test first in an integration.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
