STON.fi V2 Cross-Swap Explained: Nested Payloads for Same-Router Routes
A STON.fi V2 cross-swap payload turns one signed swap into a multi-hop route on the same Router. The intermediate output never has to land in your wallet before the next pool starts.
🔥 What Changes With Cross-Swap
- The custom_payload field can hold another structured DEX operation.
- The dedicated opcode is cross_swap: 0x69cf1a5b.
- The next hop can itself contain another optional custom payload.
🚀 How an A to B to C Route Runs
1. Token A is transferred to the Router Token A wallet.
2. The A/B pool executes and sends Token B back through the Router.
3. Instead of delivering B, the Router launches the encoded B/C swap.
4. Token C is sent to the receiver after the second pool finishes.
🧠 Why Users and Builders Should Care
STON.fi can describe B to C before A to B even starts. That is useful when no direct A/C pool exists, but A/B and B/C do. The wallet signs once, while jetton wallets, the Router and several pools keep the route moving through TON messages.
⚡ What Still Needs Caution
- Minimum output is checked hop by hop, not only at the final token.
- If B to C fails after A to B succeeds, the refund may be B.
- Same-Router chaining ignores fwd_gas inside cross_swap; another Router needs a normal swap payload, the other Router as receiver and enough forward gas.
💬 My Take
The smart part of STON.fi V2 routing is encoding the next operation inside the current one. Start from API simulation, pass Router metadata into dexFactory(), and use createCrossSwapBody only with current pool and wallet addresses.
Would you rather chain pools on one STON.fi Router or forward to another Router? 👇
Share the hop count you would actually encode in a live route.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
A STON.fi V2 cross-swap payload turns one signed swap into a multi-hop route on the same Router. The intermediate output never has to land in your wallet before the next pool starts.
🔥 What Changes With Cross-Swap
- The custom_payload field can hold another structured DEX operation.
- The dedicated opcode is cross_swap: 0x69cf1a5b.
- The next hop can itself contain another optional custom payload.
🚀 How an A to B to C Route Runs
1. Token A is transferred to the Router Token A wallet.
2. The A/B pool executes and sends Token B back through the Router.
3. Instead of delivering B, the Router launches the encoded B/C swap.
4. Token C is sent to the receiver after the second pool finishes.
🧠 Why Users and Builders Should Care
STON.fi can describe B to C before A to B even starts. That is useful when no direct A/C pool exists, but A/B and B/C do. The wallet signs once, while jetton wallets, the Router and several pools keep the route moving through TON messages.
⚡ What Still Needs Caution
- Minimum output is checked hop by hop, not only at the final token.
- If B to C fails after A to B succeeds, the refund may be B.
- Same-Router chaining ignores fwd_gas inside cross_swap; another Router needs a normal swap payload, the other Router as receiver and enough forward gas.
💬 My Take
The smart part of STON.fi V2 routing is encoding the next operation inside the current one. Start from API simulation, pass Router metadata into dexFactory(), and use createCrossSwapBody only with current pool and wallet addresses.
Would you rather chain pools on one STON.fi Router or forward to another Router? 👇
Share the hop count you would actually encode in a live route.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
