Explicación del reenvío STON.fi V2: receptor, carga útil personalizada y fwd_gas
STON.fi V2 reenvía un swap a otro Router apuntando receiver_address al Router siguiente, colocando el swap de ese Router dentro de custom_payload y financiando fwd_gas con un valor superior a cero. Desde la billetera parece una sola acción. En cadena, es una secuencia de mensajes internos.
🔥 Qué cambia frente a un swap simple
- Un swap de un salto puede enviar el resultado al usuario.
- Un salto con múltiples routers envía el resultado hacia el siguiente Router.
- La carga útil interna indica a ese Router qué swap ejecutar después.
🚀 Flujo de mensajes entre routers
1. La billetera emite una transferencia Jetton con Swap A.
2. Router A procesa Pool A/B y obtiene TOKEN B.
3. TOKEN B se mueve con Swap B adjunto y TON desde fwd_gas.
4. Router B inicia Pool B/C y, si es válido, entrega TOKEN C.
🧠 Por qué esto es un problema de gas
fwd_gas es el presupuesto de carga útil del DEX para reenviar transfer_notification cuando existe custom_payload. No es lo mismo que el valor de la transacción inicial ni el TON genérico de reenvío de Jetton. Si se queda corto el segundo salto, la ruta puede detenerse incluso si TOKEN B ya existe. Además, las cargas útiles anidadas aumentan el tamaño del mensaje, por lo que copiar valores de gas de un solo salto es un modelo débil.
⚡ Beneficios y limitaciones clave
- cross_swap se mantiene en un solo Router e ignora fwd_gas.
- El reenvío multi-router cruza un límite de billetera Jetton.
- Cada swap anidado conserva su propio min_out, deadline y refund_address.
- Un fallo posterior puede dejar un token intermedio, no el activo original.
- La confirmación de la billetera no prueba que el Router B haya finalizado la ruta.
¿Vas a depurar primero el límite de reenvío o el segundo min_out? 👇
Comparte el campo STON.fi V2 que todavía te resulta más fácil configurar mal.
No es asesoramiento de inversión: ¡investiga por tu cuenta! 🚀
$GRAM @STONfi DEX
STON.fi V2 reenvía un swap a otro Router apuntando receiver_address al Router siguiente, colocando el swap de ese Router dentro de custom_payload y financiando fwd_gas con un valor superior a cero. Desde la billetera parece una sola acción. En cadena, es una secuencia de mensajes internos.
🔥 Qué cambia frente a un swap simple
- Un swap de un salto puede enviar el resultado al usuario.
- Un salto con múltiples routers envía el resultado hacia el siguiente Router.
- La carga útil interna indica a ese Router qué swap ejecutar después.
🚀 Flujo de mensajes entre routers
1. La billetera emite una transferencia Jetton con Swap A.
2. Router A procesa Pool A/B y obtiene TOKEN B.
3. TOKEN B se mueve con Swap B adjunto y TON desde fwd_gas.
4. Router B inicia Pool B/C y, si es válido, entrega TOKEN C.
🧠 Por qué esto es un problema de gas
fwd_gas es el presupuesto de carga útil del DEX para reenviar transfer_notification cuando existe custom_payload. No es lo mismo que el valor de la transacción inicial ni el TON genérico de reenvío de Jetton. Si se queda corto el segundo salto, la ruta puede detenerse incluso si TOKEN B ya existe. Además, las cargas útiles anidadas aumentan el tamaño del mensaje, por lo que copiar valores de gas de un solo salto es un modelo débil.
⚡ Beneficios y limitaciones clave
- cross_swap se mantiene en un solo Router e ignora fwd_gas.
- El reenvío multi-router cruza un límite de billetera Jetton.
- Cada swap anidado conserva su propio min_out, deadline y refund_address.
- Un fallo posterior puede dejar un token intermedio, no el activo original.
- La confirmación de la billetera no prueba que el Router B haya finalizado la ruta.
¿Vas a depurar primero el límite de reenvío o el segundo min_out? 👇
Comparte el campo STON.fi V2 que todavía te resulta más fácil configurar mal.
No es asesoramiento de inversión: ¡investiga por tu cuenta! 🚀
$GRAM @STONfi DEX
