Los desarrolladores que han logrado que un intercambio de tokens de STON.fi funcione en un sandbox están siendo advertidos ahora de que el salto a la mainnet puede agotar los fondos de los usuarios si se dejan algunos atajos aparentemente inofensivos en el código. Una lista de verificación redactada por la comunidad y publicada en un blog para desarrolladores describe los puntos exactos en los que fallan la mayoría de las integraciones y ofrece una receta concreta para un lanzamiento listo para producción.

Por qué la transición es importante

STON.fi proporciona un router que agrega liquidez a través de múltiples DEX en la blockchain TON. Los proyectos que quieran ofrecer a los usuarios un intercambio con un solo clic suelen llamar al router desde un front-end o un wrapper de contrato inteligente. En un entorno de prueba, la dirección del router es estática, el esquema de comisiones es conocido y el sandbox tolera transacciones mal dirigidas. En la mainnet, sin embargo, el router puede actualizarse, los parámetros de las comisiones pueden cambiar y una sola dirección mal colocada envía tokens reales a un contrato muerto. Por lo tanto, lo que está en juego es la diferencia entre una experiencia de usuario fluida y una pérdida que puede dañar la reputación de un proyecto de la noche a la mañana.

El error más común: el uso de valores fijos (hard-coding)

Un patrón recurrente en los lanzamientos fallidos es el hard-coding de la dirección del router o de las constantes de las comisiones que eran válidas durante las pruebas. Cuando STON.fi actualiza su router —un evento rutinario para mejorar el rendimiento o corregir errores—, la dirección fija ya no apunta a un contrato funcional. La integración lanza un error que los usuarios nunca ven o, lo que es peor, redirige silenciosamente los fondos a una dirección que no puede procesarlos. La guía de la comunidad enfatiza una única regla: deje que la REST API de STON.fi decida qué router utilizar.

Una lista de verificación de seguridad paso a paso

La lista de verificación divide el proceso de migración en cuatro capas lógicas: entorno, interacción con el contrato, cálculo de comisiones y manejo de casos límite.

  • Valide las variables de entorno de forma temprana. Dirija el endpoint de WebSocket y la URL base de la REST API al sandbox mientras realiza las pruebas; cámbielos a los nodos de la mainnet antes del lanzamiento. Un error tipográfico aquí puede redirigir un intercambio real al router de prueba, bloqueando los tokens para siempre.

  • Nunca incruste direcciones de contratos. Realice una solicitud de simulación contra la API de STON.fi, obtenga la dirección actual del router de la respuesta e incorpórela a su dexFactory (o el factory de contrato equivalente) en tiempo de ejecución. Esto se adapta automáticamente a cualquier futura actualización del router.

  • Calcule las comisiones sobre la marcha. Obtenga los parámetros de las comisiones del payload de configuración de la API y utilícelos en su rutina de cálculo de comisiones. Los porcentajes fijos quedan obsoletos en el momento en que la plataforma ajusta su economía.

  • Prefiera el SDK oficial y TonConnect. El SDK construye estructuras BOC (Bag of Cells) por usted e incluye comprobaciones de límites de gas, codificación de datos y validación de firmas. La compilación manual de BOC debe reservarse para casos de uso altamente especializados que el SDK no pueda cubrir.

  • Realice pruebas de modo de fallo. Simule escenarios de falta de gas (out-of-gas), permisos insuficientes (insufficient allowance) y respuestas malformadas en el sandbox. Verifique que su contrato reembolse al usuario o emita un evento de error claro. Confiar en que los usuarios descubran estos errores en producción invita a la pérdida de usuarios (churn).

  • Confirme las rutas de retiro de referidos. En la segunda versión del DEX, las comisiones de referidos llegan a un contrato Vault dedicado en lugar de a una billetera. Su integración debe llamar al método de retiro del Vault y gestionar los tokens recibidos antes de acreditar la cuenta del referente.

Lo que los desarrolladores están debatiendo

Algunos desarrolladores argumentan que el SDK añade una sobrecarga innecesaria y que un payload BOC elaborado manualmente puede ser más pequeño y más barato en términos de gas. La guía reconoce este punto de vista, pero señala que el SDK también incluye actualizaciones de la dirección del router y del esquema de comisiones, lo que significa que un payload construido manualmente debe revisarse tras cada actualización de STON.fi. Por lo tanto, el compromiso es entre un ahorro marginal de gas y el riesgo de una ruptura silenciosa.

Qué vigilar a continuación

  • Anuncios de actualización del router. STON.fi publica los próximos cambios del router en su canal para desarrolladores. Suscribirse a esos feeds le permite probar preventivamente la nueva dirección en un sandbox antes del cambio a la mainnet.
  • Revisiones de los parámetros de comisiones. Debido a que los porcentajes de las comisiones pueden ajustarse para responder a las condiciones del mercado, incorpore una extracción periódica del endpoint de configuración en cualquier servicio de monitoreo.
  • Lanzamientos de versiones del SDK. Los nuevos lanzamientos del SDK suelen incluir correcciones de errores para casos límite descubiertos tras un lanzamiento en la mainnet. Mantener el SDK actualizado es tan importante como actualizar la dirección del router.

La conclusión es clara: un swap que “funciona en las pruebas” no se traduce automáticamente en una experiencia segura en la mainnet. Al obtener cada valor crítico —desde la dirección del router hasta el esquema de comisiones— directamente de la API en vivo de STON.fi, y al probar rigurosamente las rutas de error antes de que los usuarios vean la interfaz, los desarrolladores pueden proteger los fondos de los usuarios y preservar la confianza al recorrer la última milla hacia la producción.

Fuente: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0