Un transaction de Dusk peut-elle réussir sur la chaîne tout en échouant à livrer des DUSK à l’adresse BSC visée ? Oui, car ce flux de pont comporte deux destinations dissimulées dans une seule action utilisateur.

Dans le flux actuel de mainnet Dusk vers BSC, le Web Wallet envoie des DUSK natifs au compte officiel du pont. Le destinataire BSC n’est pas le champ « recipient » de cette transaction ; il est transporté dans le mémo. Le pont lit cette adresse au format EVM et l’utilise pour router le paiement BEP20.

Cela change la signification de « réussi ». Une transaction Dusk confirmée prouve que le transfert côté source a bien atteint le compte du pont. Elle ne prouve pas, à elle seule, que le paiement côté destination a été acheminé vers l’adresse que l’utilisateur avait l’intention. La documentation de Dusk prévient qu’un mémo manquant ou invalide ne peut pas être traité automatiquement et peut rendre le transfert irrécupérable.

Ainsi, le mémo fait plus que décrire la transaction. Dans ce flux, il fait partie des instructions de livraison.

Je pense que cela crée une limite utile pour les wallets et l’UX du pont : une fois que l’infrastructure consomme des métadonnées pour décider où la valeur doit aller ensuite, ces métadonnées doivent être traitées comme une entrée critique pour la transaction. Le compte du pont et l’adresse du mémo méritent la même vérification préalable avant l’envoi.

Un hachage de transaction peut prouver le règlement. Il ne peut pas corriger une instruction d’acheminement qui était erronée avant le règlement.

@Dusk $DUSK #dusk $TRUMP $ZEC