No fluxo de retirada da Dusk para a exchange, há um status que é particularmente fácil de interpretar errado: quando o nó retorna 202 Accepted, isso conta ou não como retirada bem-sucedida? De acordo com o procedimento oficial, isso apenas indica que a transação foi recebida e encaminhada para roteamento; ainda não pode ser equiparado a “entrar em um bloco” nem diretamente a “os fundos terem concluído o acerto final”. Para que a retirada seja realmente concluída, é necessário continuar confirmando o resultado da execução da transação e se o bloco em que ela ocorreu entrou no estado finalized. Para uma exchange, se esses estados não forem separados, quando o suporte vê “API com sucesso”, ele libera o saldo; só que isso faz com que o estado técnico seja confundido com um estado contábil.
Há também um detalhe que costuma causar incidentes: quando ocorrer timeout de rede, não se deve gerar imediatamente uma segunda retirada. A documentação recomenda que, em primeiro lugar, se faça replay da mesma mensagem assinada. Se realmente for necessário substituir usando o mesmo nonce, o novo transação precisa ter um gas price estritamente maior, e isso também gerará um novo ID de transação. Um exemplo mínimo: se o preço original era 100, substituir mantendo 100 não funciona; aumentar apenas o gas limit também não basta — precisa ser maior que 100. Além disso, o backend deve checar simultaneamente os IDs novo e antigo, para evitar que uma mesma retirada seja registrada como duas deduções.
Usuários de BTC entendem bem que “ser propagado” não é o mesmo que “concluir”; a intuição comum é continuar aguardando confirmações. Mas, na camada de integração da Dusk, isso é ainda mais explícito: o ponto final é acompanhar o finalized. Pessoas familiarizadas com ETH também têm a intuição de “substituição por preço com mesmo nonce”, mas aqui não basta olhar apenas para o “acelerar” — o sistema também precisa tratar o novo ID da transação após a substituição. Em outras palavras, a retirada que o usuário vê pode, na prática, passar por vários estágios: roteamento, substituição, execução e confirmação final.
Por isso, o que vale mais a pena observar são as carteiras e exchanges no ecossistema @Dusk : elas conseguem transformar a retirada $DUSK em três estados legíveis — “já roteada”, “já executada” e “já confirmada finalmente”? O mal-entendido mais comum de mercado não é a velocidade, e sim tratar sucesso de comunicação como sucesso de liquidação dos fundos. O próximo passo a observar é se integrações populares exibem de forma clara a confirmação final e se o replay em caso de timeout consegue evitar deduzir valores duas vezes.
#dusk
Há também um detalhe que costuma causar incidentes: quando ocorrer timeout de rede, não se deve gerar imediatamente uma segunda retirada. A documentação recomenda que, em primeiro lugar, se faça replay da mesma mensagem assinada. Se realmente for necessário substituir usando o mesmo nonce, o novo transação precisa ter um gas price estritamente maior, e isso também gerará um novo ID de transação. Um exemplo mínimo: se o preço original era 100, substituir mantendo 100 não funciona; aumentar apenas o gas limit também não basta — precisa ser maior que 100. Além disso, o backend deve checar simultaneamente os IDs novo e antigo, para evitar que uma mesma retirada seja registrada como duas deduções.
Usuários de BTC entendem bem que “ser propagado” não é o mesmo que “concluir”; a intuição comum é continuar aguardando confirmações. Mas, na camada de integração da Dusk, isso é ainda mais explícito: o ponto final é acompanhar o finalized. Pessoas familiarizadas com ETH também têm a intuição de “substituição por preço com mesmo nonce”, mas aqui não basta olhar apenas para o “acelerar” — o sistema também precisa tratar o novo ID da transação após a substituição. Em outras palavras, a retirada que o usuário vê pode, na prática, passar por vários estágios: roteamento, substituição, execução e confirmação final.
Por isso, o que vale mais a pena observar são as carteiras e exchanges no ecossistema @Dusk : elas conseguem transformar a retirada $DUSK em três estados legíveis — “já roteada”, “já executada” e “já confirmada finalmente”? O mal-entendido mais comum de mercado não é a velocidade, e sim tratar sucesso de comunicação como sucesso de liquidação dos fundos. O próximo passo a observar é se integrações populares exibem de forma clara a confirmação final e se o replay em caso de timeout consegue evitar deduzir valores duas vezes.
#dusk