#dusk $DUSK @Dusk Antes de eu fazer pagamentos on-chain, eu tinha o hábito de colocar o número do pedido no campo memo de forma “natural”. Mas depois que li a documentação de Transaction Lifecycle @Dusk , percebi que esse hábito não pode ser simplesmente transferido, porque nos dados de transação do Dusk há uma relação de escolha única entre memo, chamada de contrato, deploy do contrato e blob. Ou seja, o memo não pode, por padrão, ser levado junto com outros payloads. Essa diferença muda diretamente a forma de acoplar o sistema de pagamentos: se o comerciante quiser tanto receber o pagamento quanto executar uma ação via contrato, então não dá para presumir que dá para continuar colocando o número do pedido no memo da mesma transação. O cliente precisa primeiro decidir qual é a tarefa principal daquela transação e, então, projetar outro registro confiável para associar o pedido. O cenário de pressão é bem específico: quando o usuário envia um pagamento que inclui uma ação de contrato, a interface mostra que foi enviado, mas o backend faz a correspondência do pedido usando o memo. Como resultado, o valor entra, mas o número do pedido não aparece como esperado; o atendimento só consegue verificar manualmente a transação. Isso talvez não seja “perda de dados” do Dusk; é mais provável que a parte integradora tenha forçado um hábito de transações de outra blockchain. Por isso, quando eu analiso a integração de pagamentos do DUSK, não fico apenas perguntando se a transferência consegue ser bem-sucedida. Eu primeiro confirmo se a transação carrega memo ou uma chamada de contrato, e depois verifico se a associação do pedido pode ser validada de forma independente e rechecável. O @Dusk já deixou bem claro o limite de payload, mas se os exemplos conseguem permitir que desenvolvedores evitem esse tipo de uso indevido antes, é algo que vale mais a pena validar quando o Dusk entra em cenários reais de pagamento.