Explicación de la Dirección de Reembolso de STON.fi V2: ¿A dónde van los intercambios fallidos?
STON.fi V2 puede codificar un refund_address personalizado para que los activos devueltos no tengan que volver a la billetera de inicio. Esto es un manejo de fallos programable, no un valor predeterminado oculto.
🔥 ¿Qué cambia en un swap V2?
- receiver_address recibe los tokens cuando el intercambio se realiza con éxito.
- refund_address recibe los fondos cuando el swap solicitado no puede completarse.
- excesses_address recibe el TON sobrante después del procesamiento.
Estos roles no son intercambiables. Enviar la salida a una billetera no envía automáticamente allí los reembolsos.
🚀 Por qué existe la ruta de fallo
Un swap en STON.fi puede parecer de un solo clic, pero la ejecución en TON es una cadena de mensajes asíncronos. V2 puede reembolsar por baja liquidez, salida cero, salida por debajo de min_out, un pool bloqueado, una transacción expirada o gas inválido.
min_out y el plazo (deadline) deciden si el resultado sigue siendo aceptable. La dirección de reembolso solo indica dónde debería aterrizar el valor después de un fallo protegido.
🧠 Un flujo simple de fallo
1. La transacción nombra receiver, refund address, min_out y deadline.
2. El Router envía la solicitud al Pool.
3. El Pool prueba si se pueden cumplir las condiciones.
4. El éxito sigue la ruta del receiver. Un fallo reembolsable sigue el destino de reembolso codificado.
Omniston mantiene refund_address como opcional. Déjalo fuera y los fondos volverán al remitente.
⚡ Cargas útiles (Payloads) y límites estrictos
STON.fi V2 puede adjuntar refund_fwd_gas y un refund_payload para que un contrato reciba contexto con los fondos devueltos. Esto ayuda a bots y dApps solo si el destino puede manejar el activo.
No puede convertir una ruta de varios pasos en un “undo” atómico. Si el Token A ya se convirtió en Token B, un fallo posterior puede devolver el token intermedio.
Si una app no puede explicar por qué un reembolso va a otro lugar, mantén el default del remitente y usa el SDK oficial.
¿Enviarías los swaps fallidos de STON.fi V2 a una billetera de recuperación o de vuelta al usuario? 👇
Deja el caso de fallo que probarías primero en una integración.
No es asesoramiento de inversión: ¡investiga por tu cuenta! 🚀
$GRAM @STONfi DEX
STON.fi V2 puede codificar un refund_address personalizado para que los activos devueltos no tengan que volver a la billetera de inicio. Esto es un manejo de fallos programable, no un valor predeterminado oculto.
🔥 ¿Qué cambia en un swap V2?
- receiver_address recibe los tokens cuando el intercambio se realiza con éxito.
- refund_address recibe los fondos cuando el swap solicitado no puede completarse.
- excesses_address recibe el TON sobrante después del procesamiento.
Estos roles no son intercambiables. Enviar la salida a una billetera no envía automáticamente allí los reembolsos.
🚀 Por qué existe la ruta de fallo
Un swap en STON.fi puede parecer de un solo clic, pero la ejecución en TON es una cadena de mensajes asíncronos. V2 puede reembolsar por baja liquidez, salida cero, salida por debajo de min_out, un pool bloqueado, una transacción expirada o gas inválido.
min_out y el plazo (deadline) deciden si el resultado sigue siendo aceptable. La dirección de reembolso solo indica dónde debería aterrizar el valor después de un fallo protegido.
🧠 Un flujo simple de fallo
1. La transacción nombra receiver, refund address, min_out y deadline.
2. El Router envía la solicitud al Pool.
3. El Pool prueba si se pueden cumplir las condiciones.
4. El éxito sigue la ruta del receiver. Un fallo reembolsable sigue el destino de reembolso codificado.
Omniston mantiene refund_address como opcional. Déjalo fuera y los fondos volverán al remitente.
⚡ Cargas útiles (Payloads) y límites estrictos
STON.fi V2 puede adjuntar refund_fwd_gas y un refund_payload para que un contrato reciba contexto con los fondos devueltos. Esto ayuda a bots y dApps solo si el destino puede manejar el activo.
No puede convertir una ruta de varios pasos en un “undo” atómico. Si el Token A ya se convirtió en Token B, un fallo posterior puede devolver el token intermedio.
Si una app no puede explicar por qué un reembolso va a otro lugar, mantén el default del remitente y usa el SDK oficial.
¿Enviarías los swaps fallidos de STON.fi V2 a una billetera de recuperación o de vuelta al usuario? 👇
Deja el caso de fallo que probarías primero en una integración.
No es asesoramiento de inversión: ¡investiga por tu cuenta! 🚀
$GRAM @STONfi DEX
