🚀 Testes para Transações Falhadas: um Checklist de um Construtor para STONfi
A maioria dos tutoriais de swap para no caminho “feliz”. Se você publicar apenas isso, terá testado talvez 60% do que a produção realmente joga em você — a execução assíncrona e baseada em mensagens do TON produz formatos de falha que as intuições de quem aprendeu com EVM simplesmente não estão preparadas para.
🧭 As Falhas que Realmente Acontecem
Reembolsos por slippage são a proteção funcionando como deveria, não um bug — teste valores apertados, folgados e de limites, não apenas um “valor razoável” padrão. Cross-swaps roteados por um token intermediário não conseguem reembolsar completamente se falharem no meio do caminho, pois transações multi-contrato no TON não são atômicas — o usuário acaba ficando com o token intermediário, e não com seu ativo original de volta. Um caso real e documentado no GitHub mostra um swap sendo transmitido limpo e, em seguida, falhando on-chain com exit_code 11 — prova de que “a chamada da SDK não lançou erro” nunca é a mesma coisa que “foi realmente bem-sucedido”. Uma parcela significativa das falhas nem sequer chega a tocar um bloco: TonConnect rejeita endereços malformados, janelas de validade expiradas e cancelamentos do usuário — os quais nunca deveriam cair silenciosamente nos seus logs de erro disfarçados de bug.
✅ Construa a Matriz de Testes em Torno Disso
Aposte no resultado do token intermediário para falhas parciais de cross-swap, verifique os exit codes on-chain após a submissão em vez de confiar apenas na chamada da SDK, separe o rastreamento de rejeição da carteira de falhas genuínas on-chain e reconstrua cada transação com base na cotação mais recente, não em uma em cache e desatualizada.
🏁 Teste como o STONfi realmente falha, e não como swaps falham em geral — e a distância entre o staging e seu primeiro ticket real de suporte diminui rápido.
$XRP
A maioria dos tutoriais de swap para no caminho “feliz”. Se você publicar apenas isso, terá testado talvez 60% do que a produção realmente joga em você — a execução assíncrona e baseada em mensagens do TON produz formatos de falha que as intuições de quem aprendeu com EVM simplesmente não estão preparadas para.
🧭 As Falhas que Realmente Acontecem
Reembolsos por slippage são a proteção funcionando como deveria, não um bug — teste valores apertados, folgados e de limites, não apenas um “valor razoável” padrão. Cross-swaps roteados por um token intermediário não conseguem reembolsar completamente se falharem no meio do caminho, pois transações multi-contrato no TON não são atômicas — o usuário acaba ficando com o token intermediário, e não com seu ativo original de volta. Um caso real e documentado no GitHub mostra um swap sendo transmitido limpo e, em seguida, falhando on-chain com exit_code 11 — prova de que “a chamada da SDK não lançou erro” nunca é a mesma coisa que “foi realmente bem-sucedido”. Uma parcela significativa das falhas nem sequer chega a tocar um bloco: TonConnect rejeita endereços malformados, janelas de validade expiradas e cancelamentos do usuário — os quais nunca deveriam cair silenciosamente nos seus logs de erro disfarçados de bug.
✅ Construa a Matriz de Testes em Torno Disso
Aposte no resultado do token intermediário para falhas parciais de cross-swap, verifique os exit codes on-chain após a submissão em vez de confiar apenas na chamada da SDK, separe o rastreamento de rejeição da carteira de falhas genuínas on-chain e reconstrua cada transação com base na cotação mais recente, não em uma em cache e desatualizada.
🏁 Teste como o STONfi realmente falha, e não como swaps falham em geral — e a distância entre o staging e seu primeiro ticket real de suporte diminui rápido.
$XRP