Cómo STONfi Maneja Direcciones “Bounceable” y “Non-Bounceable” en TON
Las direcciones de TON pueden verse diferentes aunque identifiquen la misma cuenta en la cadena. EQ... es la forma “bounceable”, mientras que UQ... es la forma “non-bounceable”. Cuando el workchain y el identificador de la cuenta son idénticos, ambas pueden representar la misma cuenta.
Qué Significa “Bounceable”
La “bounceability” describe el comportamiento de los mensajes, no una propiedad permanente de la cuenta. Una dirección amigable para usuarios de TON contiene indicadores que ayudan al software a determinar cómo se maneja un mensaje.
Con entrega “bounceable”, si el procesamiento falla bajo las condiciones aplicables, el valor restante puede devolverse hacia el remitente. Esto hace que los mensajes “bounceable” sean adecuados para interacciones con contratos inteligentes.
La entrega “non-bounceable” es útil cuando se financia una cuenta que aún no ha sido inicializada. En TON, las billeteras son contratos inteligentes, y sus direcciones pueden conocerse antes del despliegue. Un comportamiento de “bounce” inadecuado para un destino no inicializado puede provocar que la transferencia falle en lugar de financiar la cuenta.
Cómo STONfi Usa Direcciones
El swap de STONfi puede involucrar la billetera conectada, masters de Jetton, routers, pools, la dirección del receptor, la de reembolso y la de excedentes.
El objetivo de la transacción inicial es el contrato que recibe el mensaje de la billetera. Otras direcciones pueden viajar dentro del payload como valores de direcciones TON.
Desde el SDK de STONfi v0.5.0, los parámetros generados usan direcciones “bounceable” porque se espera que los contratos del protocolo existan y ejecuten la lógica. Esto sigue la práctica de TON para interacciones con contratos ya establecidos.
Por Qué Los Desarrolladores Deberían Analizar (Parsear) Direcciones
Un error común es comparar EQ... y UQ... como cadenas simples y asumir que son billeteras diferentes. En su lugar, parsea cada una en objetos adecuados de Address de TON y compara el workchain subyacente y el identificador de la cuenta.
Esto importa para integraciones, validación y construcción de transacciones. Los desarrolladores deberían conservar el workchain y apoyarse en herramientas de TON confiables para el encoding de direcciones.
$STON $RAY
#Análisis del Precio del BTC#
Las direcciones de TON pueden verse diferentes aunque identifiquen la misma cuenta en la cadena. EQ... es la forma “bounceable”, mientras que UQ... es la forma “non-bounceable”. Cuando el workchain y el identificador de la cuenta son idénticos, ambas pueden representar la misma cuenta.
Qué Significa “Bounceable”
La “bounceability” describe el comportamiento de los mensajes, no una propiedad permanente de la cuenta. Una dirección amigable para usuarios de TON contiene indicadores que ayudan al software a determinar cómo se maneja un mensaje.
Con entrega “bounceable”, si el procesamiento falla bajo las condiciones aplicables, el valor restante puede devolverse hacia el remitente. Esto hace que los mensajes “bounceable” sean adecuados para interacciones con contratos inteligentes.
La entrega “non-bounceable” es útil cuando se financia una cuenta que aún no ha sido inicializada. En TON, las billeteras son contratos inteligentes, y sus direcciones pueden conocerse antes del despliegue. Un comportamiento de “bounce” inadecuado para un destino no inicializado puede provocar que la transferencia falle en lugar de financiar la cuenta.
Cómo STONfi Usa Direcciones
El swap de STONfi puede involucrar la billetera conectada, masters de Jetton, routers, pools, la dirección del receptor, la de reembolso y la de excedentes.
El objetivo de la transacción inicial es el contrato que recibe el mensaje de la billetera. Otras direcciones pueden viajar dentro del payload como valores de direcciones TON.
Desde el SDK de STONfi v0.5.0, los parámetros generados usan direcciones “bounceable” porque se espera que los contratos del protocolo existan y ejecuten la lógica. Esto sigue la práctica de TON para interacciones con contratos ya establecidos.
Por Qué Los Desarrolladores Deberían Analizar (Parsear) Direcciones
Un error común es comparar EQ... y UQ... como cadenas simples y asumir que son billeteras diferentes. En su lugar, parsea cada una en objetos adecuados de Address de TON y compara el workchain subyacente y el identificador de la cuenta.
Esto importa para integraciones, validación y construcción de transacciones. Los desarrolladores deberían conservar el workchain y apoyarse en herramientas de TON confiables para el encoding de direcciones.
$STON $RAY
#Análisis del Precio del BTC#