Uma transação Dusk de fim de tarde pode ser bem-sucedida na blockchain e ainda assim falhar em entregar DUSK ao endereço BSC pretendido? Sim, porque este fluxo de ponte tem dois destinos ocultos dentro de uma única ação do usuário.

No fluxo atual da rede principal de Dusk para BSC, a Web Wallet envia DUSK nativo para a conta oficial da ponte. O destinatário BSC não é o campo de destinatário dessa transação; ele é transportado no memo. A ponte lê esse endereço formatado em EVM e o usa para fazer o roteamento do pagamento BEP20.

Isso muda o que significa “bem-sucedido”. Uma transação Dusk confirmada prova que a transferência do lado de origem chegou à conta da ponte. Por si só, ela não prova que o pagamento do lado de destino foi roteado para o endereço que o usuário pretendia. A documentação da Dusk avisa que um memo ausente ou inválido não pode ser processado automaticamente e pode tornar a transferência irrecuperável.

Assim, o memo está fazendo mais do que descrever a transação. Neste fluxo, ele faz parte da instrução de entrega.

Acho que isso cria uma fronteira útil para carteiras e UX da ponte: uma vez que a infraestrutura consome metadados para decidir para onde o valor vai em seguida, esses metadados devem ser tratados como uma entrada crítica da transação. A conta da ponte e o endereço do memo merecem a mesma verificação pré-envio.

Um hash de transação pode comprovar o acerto. Ele não pode corrigir uma instrução de roteamento que estava errada antes do acerto.

@Dusk $DUSK #dusk $TRUMP $ZEC