STON.fi V2: объяснение пересылки — receiver, custom_payload и fwd_gas
STON.fi V2 пересылает своп на другой Router, указывая receiver_address следующего Router, помещая своп этого Router внутрь custom_payload и пополняя fwd_gas выше нуля. Со стороны кошелька это выглядит как одно действие. На блокчейне это последовательность внутренних сообщений.
🔥 Что меняется по сравнению с простым свопом
- Однохоповый своп может отправлять вывод пользователю.
- Мульти-router хоп отправляет вывод в сторону следующего Router.
- Внутренний payload сообщает тому Router, какой своп нужно выполнить дальше.
🚀 Поток сообщений между Router'ами
1. Кошелёк отправляет Jetton transfer со Swap A.
2. Router A обрабатывает Pool A/B и получает TOKEN B.
3. TOKEN B перемещается вместе со Swap B и TON из fwd_gas.
4. Router B запускает Pool B/C и, если всё валидно, доставляет TOKEN C.
🧠 Почему это проблема с газом
fwd_gas — это бюджет payload DEX для пересылки transfer_notification, когда существует custom_payload. Он не равен начальному значению транзакции или любому обобщённому forward TON для Jetton. Если недофинансировать второй хоп, маршрут может зависнуть даже при том, что TOKEN B уже существует. Вложенные payload также увеличивают размер сообщения, поэтому копирование значений газа для однохоповой модели — слабый вариант.
⚡ Ключевые преимущества и ограничения
- cross_swap остаётся в одном Router и игнорирует fwd_gas.
- Мульти-router пересылка пересекает границу Jetton кошелька.
- Каждый вложенный своп сохраняет свои min_out, deadline и refund_address.
- Более поздняя ошибка может оставить промежуточный токен, а не исходный актив.
- Подтверждение кошелька не доказывает, что Router B завершил весь маршрут.
Хотите отлаживать границу пересылки или второй min_out в первую очередь? 👇
Поделитесь STON.fi V2 полем, которое всё ещё проще всего выставить неверно.
Не инвестиционный совет — проведите собственное исследование! 🚀
$GRAM @STONfi DEX
STON.fi V2 пересылает своп на другой Router, указывая receiver_address следующего Router, помещая своп этого Router внутрь custom_payload и пополняя fwd_gas выше нуля. Со стороны кошелька это выглядит как одно действие. На блокчейне это последовательность внутренних сообщений.
🔥 Что меняется по сравнению с простым свопом
- Однохоповый своп может отправлять вывод пользователю.
- Мульти-router хоп отправляет вывод в сторону следующего Router.
- Внутренний payload сообщает тому Router, какой своп нужно выполнить дальше.
🚀 Поток сообщений между Router'ами
1. Кошелёк отправляет Jetton transfer со Swap A.
2. Router A обрабатывает Pool A/B и получает TOKEN B.
3. TOKEN B перемещается вместе со Swap B и TON из fwd_gas.
4. Router B запускает Pool B/C и, если всё валидно, доставляет TOKEN C.
🧠 Почему это проблема с газом
fwd_gas — это бюджет payload DEX для пересылки transfer_notification, когда существует custom_payload. Он не равен начальному значению транзакции или любому обобщённому forward TON для Jetton. Если недофинансировать второй хоп, маршрут может зависнуть даже при том, что TOKEN B уже существует. Вложенные payload также увеличивают размер сообщения, поэтому копирование значений газа для однохоповой модели — слабый вариант.
⚡ Ключевые преимущества и ограничения
- cross_swap остаётся в одном Router и игнорирует fwd_gas.
- Мульти-router пересылка пересекает границу Jetton кошелька.
- Каждый вложенный своп сохраняет свои min_out, deadline и refund_address.
- Более поздняя ошибка может оставить промежуточный токен, а не исходный актив.
- Подтверждение кошелька не доказывает, что Router B завершил весь маршрут.
Хотите отлаживать границу пересылки или второй min_out в первую очередь? 👇
Поделитесь STON.fi V2 полем, которое всё ещё проще всего выставить неверно.
Не инвестиционный совет — проведите собственное исследование! 🚀
$GRAM @STONfi DEX
