“Removido” esta palavra no monitoramento de transações pode ser facilmente lida como “falha”. Mas quando vejo o evento RUES de @Dusk , eu pauso antes de tirar conclusões, porque o fato de uma transação sair do mempool local não significa que ela foi rejeitada pela blockchain. Não é jogo de palavras: a documentação oficial da Dusk sobre transactions/removed indica apenas que ela saiu do mempool local de algum nó. As causas podem ser inclusão em bloco, substituição por uma transação conflitante com gasPrice mais alto, expiração, descarte por capacidade ou simplesmente o fato de uma transação conflitante ter saído. Olhando apenas este evento, o sistema não te diz qual foi o resultado final.

Isso me fez reavaliar a experiência do desenvolvedor do $DUSK . Quando o monitor transforma removed em falha, o backend alerta cedo demais; mas se tratar removed como sucesso, pode deixar passar transações que foram de fato descartadas. Um campo de status na prática separa “o que acontece diante dos olhos do nó” de “o que o livro-razão registra por fim”, em duas camadas. Em cenários de pressão, isso é bastante comum: o usuário faz uma transferência, o wallet recebe removed e mostra “tente novamente”. Ele envia outra transação e só então descobre que a primeira já entrou em bloco, resultando em pagamento de gas a mais. O suporte ao cliente ainda precisa explicar qual foi a transação efetiva. Se a mensagem de erro não considerar o livro-razão e se basear só em eventos, a visão local se torna ampliada como se fosse fato.

Por isso, eu não considero removed do RUES como um sinal de falha. A documentação do @Dusk mostra um caminho mais seguro: verificar a transação e o estado do bloco antes de decidir se deve reenviar. Em seguida, vou ver se o wallet separa a exibição ao usuário de “removido localmente” e o “resultado final”—é esse o tipo de detalhe que a Dusk usa para ajudar o usuário a evitar armadilhas.#dusk