STON.fi V2 Forwarding Explained: Receiver, Custom Payload and fwd_gas
STON.fi V2 forwards a swap to another Router by pointing receiver_address at the next Router, putting that Router's swap inside custom_payload, and funding fwd_gas above zero. From the wallet it looks like one action. On-chain it is a sequence of internal messages.
🔥 What Changes Versus a Simple Swap
- A one-hop swap can send output to the user.
- A multi-router hop sends output toward the next Router.
- The inner payload tells that Router what swap to run next.
🚀 Message Flow Across Routers
1. Wallet emits a Jetton transfer with Swap A.
2. Router A processes Pool A/B and gets TOKEN B.
3. TOKEN B moves with Swap B attached and TON from fwd_gas.
4. Router B starts Pool B/C and, if valid, delivers TOKEN C.
🧠 Why This Is a Gas Problem
fwd_gas is the DEX payload budget for forwarding transfer_notification when custom_payload exists. It is not the same as the initial transaction value or generic Jetton forward TON. Underfund the second hop and the route can stall even if TOKEN B already exists. Nested payloads also increase message size, so copied single-hop gas values are a weak model.
⚡ Key Benefits and Limitations
- cross_swap stays on one Router and ignores fwd_gas.
- Multi-router forwarding crosses a Jetton wallet boundary.
- Each nested swap keeps its own min_out, deadline and refund_address.
- A later failure may leave an intermediate token, not the original asset.
- Wallet confirmation does not prove Router B finished the route.
Would you debug the forwarding boundary or the second min_out first? 👇
Share the STON.fi V2 field that still feels easiest to mis-set.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
STON.fi V2 forwards a swap to another Router by pointing receiver_address at the next Router, putting that Router's swap inside custom_payload, and funding fwd_gas above zero. From the wallet it looks like one action. On-chain it is a sequence of internal messages.
🔥 What Changes Versus a Simple Swap
- A one-hop swap can send output to the user.
- A multi-router hop sends output toward the next Router.
- The inner payload tells that Router what swap to run next.
🚀 Message Flow Across Routers
1. Wallet emits a Jetton transfer with Swap A.
2. Router A processes Pool A/B and gets TOKEN B.
3. TOKEN B moves with Swap B attached and TON from fwd_gas.
4. Router B starts Pool B/C and, if valid, delivers TOKEN C.
🧠 Why This Is a Gas Problem
fwd_gas is the DEX payload budget for forwarding transfer_notification when custom_payload exists. It is not the same as the initial transaction value or generic Jetton forward TON. Underfund the second hop and the route can stall even if TOKEN B already exists. Nested payloads also increase message size, so copied single-hop gas values are a weak model.
⚡ Key Benefits and Limitations
- cross_swap stays on one Router and ignores fwd_gas.
- Multi-router forwarding crosses a Jetton wallet boundary.
- Each nested swap keeps its own min_out, deadline and refund_address.
- A later failure may leave an intermediate token, not the original asset.
- Wallet confirmation does not prove Router B finished the route.
Would you debug the forwarding boundary or the second min_out first? 👇
Share the STON.fi V2 field that still feels easiest to mis-set.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
