Le moment où l’actif réglementé fait le plus de mal aux utilisateurs 😅 : ce n’est pas le refus de la transaction en soi, c’est le fait qu’après un refus, personne ne précise clairement où est exactement l’erreur.
J’ai vu sur la page « Assets & Regulations » de @Dusk que la vérification de cession est listée comme une exigence à part : en cas d’échec, il faut fournir une raison explicite, et il est préférable de simuler ou de vérifier avant de soumettre.
Ce détail transforme la « conformité à l’accès » d’un simple laissez-passer à usage unique en une règle qui s’applique en continu à chaque cession. Les critères indiqués ne sont pas abstraits : qui peut détenir, qui peut recevoir, et quelles cessions doivent échouer varient selon la catégorie d’actifs, le lieu ou la juridiction. Pour l’émetteur, ces règles réduisent le risque de mauvaise correspondance ; pour l’investisseur, ce qui compte vraiment, c’est de savoir avant de cliquer pour confirmer s’il sera bloqué, et surtout la raison précise pour laquelle il l’est.
Les situations de pression surviennent souvent après que l’utilisateur pense avoir terminé toutes les étapes : le compte a passé les vérifications de qualification en amont, mais lorsqu’il tente une cession vers une autre adresse, il reçoit un message de refus vague. L’actif n’est pas forcément perdu, la chaîne n’est pas forcément anormale, mais l’utilisateur attribue d’abord le problème à la plateforme. Le service client doit alors expliquer manuellement une limitation qui aurait dû être affichée à l’avance. L’avantage de $DUSK ne consiste pas à faire passer toutes les cessions, mais à rendre les refus nécessaires prédictibles et explicables avant la signature. @Dusk La question à vérifier ensuite n’est pas seulement « si » l’application applique les règles, mais si elle peut afficher, avant la signature, les règles, les résultats de simulation et les raisons de l’échec, plutôt que d’attendre après la soumission de la transaction. #dusk