J’ai relu le guide de migration du mainnet de @Dusk , et il y a un détail très facile à ignorer : dans un portefeuille, cliquer sur « Approve » ne signifie pas que $DUSK est déjà migré vers le mainnet Dusk. Le vrai déclencheur de la migration, c’est la transaction « Execute » qui suit. Entre les deux étapes, toute interruption peut amener l’utilisateur à croire à tort que ses actifs « sont bloqués ».
Le processus officiel consiste à verrouiller des tokens ERC-20 sur Ethereum ou des tokens BEP-20 sur BNB Chain dans le contrat de migration, puis à distribuer les montants correspondants de la crypto native vers le compte du mainnet Dusk désigné. L’utilisateur doit préparer un portefeuille EVM en self-custody, un compte Dusk, ainsi que payer les frais de la chaîne source en ETH ou BNB ; après la confirmation de la transaction, il faut généralement encore attendre le traitement. Les comptes d’exchange ne peuvent en général pas réaliser directement l’ensemble de cette opération via WalletConnect : il faut d’abord utiliser un portefeuille que l’on contrôle soi-même.
Le mécanisme en lui-même n’est pas compliqué, mais toutes les embûches se trouvent dans les limites d’exécution. Premièrement, l’autorisation ne fait que donner une capacité au contrat : elle ne transfère pas automatiquement de fonds. Deuxièmement, le token sur la chaîne source a 18 décimales, tandis que le DUSK sur le mainnet en a 9 : le montant migré est arrondi vers le bas en unités minimales LUX ; toute fraction inférieure à 1 LUX reste dans le portefeuille d’origine. Troisièmement, si le solde n’arrive pas, il faut d’abord vérifier si la transaction Execute a bien réussi, au lieu de refaire une autorisation.
Cette conception de verrouillage à sens unique puis de distribution est plus claire que de laisser les utilisateurs chercher un pool cross-chain, mais elle met tout de même deux chaînes, deux portefeuilles et deux confirmations dans un même flux. Pour les anciens utilisateurs, cela demande juste un coup d’œil de plus ; pour les nouveaux, cela peut au contraire leur faire comprendre « autorisation réussie » comme « migration terminée ». Si les mécanismes de sécurité ne sont pas expliqués clairement par l’interface, ils finissent de toute façon par devenir des erreurs humaines.
Donc, quand je regarde la migration du mainnet de #dusk , je ne regarde pas seulement si le contrat a été audité : je vérifie aussi si le portefeuille affiche en même temps l’étape en cours, le hash de la chaîne source, l’état de traitement attendu et l’adresse de réception. La documentation officielle donne clairement le parcours de vérification : c’est un gros point positif. La prochaine étape devrait être d’intégrer ces rappels dans chaque bouton clé, au lieu d’attendre que l’utilisateur échoue avant de consulter le centre d’aide.
Lors de la migration de vos actifs, quelle étape vous inquiète le plus : l’autorisation, le choix d’un mauvais réseau, ou l’opacité de l’état de réception ? Dites-nous quelle embûche opérationnelle vous avez déjà rencontrée.
$ACE $BTC
Le processus officiel consiste à verrouiller des tokens ERC-20 sur Ethereum ou des tokens BEP-20 sur BNB Chain dans le contrat de migration, puis à distribuer les montants correspondants de la crypto native vers le compte du mainnet Dusk désigné. L’utilisateur doit préparer un portefeuille EVM en self-custody, un compte Dusk, ainsi que payer les frais de la chaîne source en ETH ou BNB ; après la confirmation de la transaction, il faut généralement encore attendre le traitement. Les comptes d’exchange ne peuvent en général pas réaliser directement l’ensemble de cette opération via WalletConnect : il faut d’abord utiliser un portefeuille que l’on contrôle soi-même.
Le mécanisme en lui-même n’est pas compliqué, mais toutes les embûches se trouvent dans les limites d’exécution. Premièrement, l’autorisation ne fait que donner une capacité au contrat : elle ne transfère pas automatiquement de fonds. Deuxièmement, le token sur la chaîne source a 18 décimales, tandis que le DUSK sur le mainnet en a 9 : le montant migré est arrondi vers le bas en unités minimales LUX ; toute fraction inférieure à 1 LUX reste dans le portefeuille d’origine. Troisièmement, si le solde n’arrive pas, il faut d’abord vérifier si la transaction Execute a bien réussi, au lieu de refaire une autorisation.
Cette conception de verrouillage à sens unique puis de distribution est plus claire que de laisser les utilisateurs chercher un pool cross-chain, mais elle met tout de même deux chaînes, deux portefeuilles et deux confirmations dans un même flux. Pour les anciens utilisateurs, cela demande juste un coup d’œil de plus ; pour les nouveaux, cela peut au contraire leur faire comprendre « autorisation réussie » comme « migration terminée ». Si les mécanismes de sécurité ne sont pas expliqués clairement par l’interface, ils finissent de toute façon par devenir des erreurs humaines.
Donc, quand je regarde la migration du mainnet de #dusk , je ne regarde pas seulement si le contrat a été audité : je vérifie aussi si le portefeuille affiche en même temps l’étape en cours, le hash de la chaîne source, l’état de traitement attendu et l’adresse de réception. La documentation officielle donne clairement le parcours de vérification : c’est un gros point positif. La prochaine étape devrait être d’intégrer ces rappels dans chaque bouton clé, au lieu d’attendre que l’utilisateur échoue avant de consulter le centre d’aide.
Lors de la migration de vos actifs, quelle étape vous inquiète le plus : l’autorisation, le choix d’un mauvais réseau, ou l’opacité de l’état de réception ? Dites-nous quelle embûche opérationnelle vous avez déjà rencontrée.
$ACE $BTC
