Como a STONfi Lida com Endereços Bounceable e Non-Bounceable no TON
Endereços do TON podem ter aparência diferente enquanto identificam a mesma conta on-chain. EQ... é a forma bounceable, enquanto UQ... é a forma non-bounceable. Quando o workchain e o identificador da conta são idênticos, ambos podem representar a mesma conta.
O que Significa Bounceable
Bounceability descreve o comportamento das mensagens, não uma propriedade permanente da conta. Um endereço amigável para o usuário no TON contém sinalizadores (flags) que ajudam o software a determinar como uma mensagem é tratada.
Com entrega bounceable, se o processamento falhar sob as condições aplicáveis, o valor restante pode retornar ao remetente. Isso torna mensagens bounceable adequadas para interações com contratos inteligentes.
A entrega non-bounceable é útil ao financiar uma conta que ainda não foi inicializada. No TON, as carteiras são contratos inteligentes, e seus endereços podem ser conhecidos antes do deployment. Um comportamento de bounce inadequado para um destino não inicializado pode fazer a transferência falhar em vez de financiar a conta.
Como a STONfi Usa Endereços
Um swap da STONfi pode envolver a carteira conectada, masters de Jetton, roteadores (routers), pools, endereço do recebedor (receiver), de reembolso (refund) e de valor excedente (excess).
O alvo da transação inicial é o contrato que recebe a mensagem da carteira. Outros endereços podem viajar dentro do payload como valores de endereço do TON.
Desde o STONfi SDK v0.5.0, parâmetros gerados usam endereços bounceable, porque se espera que contratos de protocolo existam e executem lógica. Isso segue a prática do TON para interações com contratos estabelecidos.
Por que Desenvolvedores Devem Analisar Endereços
Um erro comum é comparar EQ... e UQ... como strings simples e assumir que são carteiras diferentes. Em vez disso, faça o parse deles em objetos próprios de Endereço TON e compare o workchain e o identificador de conta subjacentes.
Isso importa para integrações, validação e construção de transações. Os desenvolvedores devem preservar o workchain e confiar em ferramentas de TON confiáveis para a codificação (encoding) de endereços.
$STON $RAY
#Análise do Preço do BTC#
Endereços do TON podem ter aparência diferente enquanto identificam a mesma conta on-chain. EQ... é a forma bounceable, enquanto UQ... é a forma non-bounceable. Quando o workchain e o identificador da conta são idênticos, ambos podem representar a mesma conta.
O que Significa Bounceable
Bounceability descreve o comportamento das mensagens, não uma propriedade permanente da conta. Um endereço amigável para o usuário no TON contém sinalizadores (flags) que ajudam o software a determinar como uma mensagem é tratada.
Com entrega bounceable, se o processamento falhar sob as condições aplicáveis, o valor restante pode retornar ao remetente. Isso torna mensagens bounceable adequadas para interações com contratos inteligentes.
A entrega non-bounceable é útil ao financiar uma conta que ainda não foi inicializada. No TON, as carteiras são contratos inteligentes, e seus endereços podem ser conhecidos antes do deployment. Um comportamento de bounce inadequado para um destino não inicializado pode fazer a transferência falhar em vez de financiar a conta.
Como a STONfi Usa Endereços
Um swap da STONfi pode envolver a carteira conectada, masters de Jetton, roteadores (routers), pools, endereço do recebedor (receiver), de reembolso (refund) e de valor excedente (excess).
O alvo da transação inicial é o contrato que recebe a mensagem da carteira. Outros endereços podem viajar dentro do payload como valores de endereço do TON.
Desde o STONfi SDK v0.5.0, parâmetros gerados usam endereços bounceable, porque se espera que contratos de protocolo existam e executem lógica. Isso segue a prática do TON para interações com contratos estabelecidos.
Por que Desenvolvedores Devem Analisar Endereços
Um erro comum é comparar EQ... e UQ... como strings simples e assumir que são carteiras diferentes. Em vez disso, faça o parse deles em objetos próprios de Endereço TON e compare o workchain e o identificador de conta subjacentes.
Isso importa para integrações, validação e construção de transações. Os desenvolvedores devem preservar o workchain e confiar em ferramentas de TON confiáveis para a codificação (encoding) de endereços.
$STON $RAY
#Análise do Preço do BTC#