Vous avez approuvé le contrat d’échange, envoyé le solde de l’ancien token, et l’explorateur a marqué la transaction en vert. L’ancien symbole a disparu et rien n’a pris sa place. Soit les nouvelles unités n’existent pas, soit elles existent et rien ne les affiche. Ces deux cas se ressemblent parfaitement sur un écran de portefeuille et appellent des réponses totalement différentes.
Ce que certifie vraiment un échange terminé
Une transaction d’échange confirmée vous dit que votre appel a atteint un bloc et que la partie la plus externe de l’exécution n’a pas été annulée. C’est tout. Un statut de reçu en succès est une affirmation sur l’appel, pas un inventaire de ce que cet appel a crédité.
Un échange de migration a deux jambes, et c’est pourquoi cet écart pèse ici plus qu’ailleurs. Une jambe retire vos anciennes unités. L’autre verse les nouvelles. Le reçu couvre la transaction dans son ensemble, et un contrat peut être écrit pour que la seconde jambe fasse moins que prévu, voire rien, sans que la première se défasse.
La question à trancher n’est donc pas de savoir si l’échange a fonctionné. Elle est de savoir si un nouveau solde est désormais inscrit à votre adresse et, si oui, pourquoi rien ne l’affiche. Ce sont deux enquêtes distinctes, et cet ordre vous évite de discuter avec un service client d’un solde que vous détenez déjà.
Où le nouveau solde est réellement inscrit
Le nouveau token est un contrat ordinaire doté de son propre registre, et le standard de tokens ERC-20 y consigne votre position deux fois : une fois comme événement au moment du crédit, une fois comme valeur que le contrat renvoie sur demande.
L’événement est Transfer, qui selon la norme DOIT se déclencher lors d’un transfert de tokens, y compris les transferts de valeur nulle. Elle ajoute qu’un contrat de token qui crée de nouveaux tokens DEVRAIT déclencher un événement Transfer avec l’adresse d’expéditeur fixée à 0x0. Une migration qui émet vers votre adresse laisse donc un transfert depuis l’adresse zéro vers vous, et une migration payée depuis une réserve préfinancée laisse un transfert depuis cette réserve. Dans les deux cas, il y a une ligne à chercher.
La valeur est balanceOf, que la norme décrit comme renvoyant le solde du compte d’un autre compte à une adresse de propriétaire donnée. C’est une lecture, elle ne coûte rien et répond pour le présent, pas pour l’instant de l’échange. Ouvrez le nouveau contrat dans un explorateur de blocs et appelez balanceOf avec votre propre adresse. Le chiffre renvoyé est la réponse qui fait foi.
| Ce que vous pouvez lire | Ce que cela tranche |
|---|---|
| Le statut de reçu de l’échange | Seulement que l’appel externe n’a pas été annulé |
| Un événement de transfert vers votre adresse | Que de nouvelles unités vous ont alors été créditées |
| La lecture de balanceOf sur le nouveau contrat | Ce que vous détenez dans ce registre à présent |
| La liste d’actifs de votre portefeuille | Rien sur la propriété |
Pourquoi le solde peut être à vous sans que le portefeuille montre quoi que ce soit
La dernière ligne tranche la version de cette situation qui se corrige gratuitement. Un portefeuille ne parcourt pas chaque contrat de la chaîne à la recherche de votre adresse. Il affiche une liste d’actifs qu’on lui a demandé de suivre, et un contrat déployé la semaine dernière n’y figure pas tant que rien ne l’y inscrit.
C’est une lacune connue, pas un défaut. L’EIP-747, la norme derrière la méthode wallet_watchAsset, la décrit comme un moyen de permettre à un client de suggérer au portefeuille de l’utilisateur un token à suivre, et précise que sans elle chaque portefeuille doit précharger une liste d’actifs approuvés ou les utilisateurs doivent ajouter les actifs manuellement. Une migration produit exactement ce cas.
La correction consiste à ajouter le contrat à la main, avec l’adresse tirée de l’annonce du projet lui-même et non d’un résultat de recherche ou d’un message de discussion. Dès que le portefeuille le suit, le solde apparaît aussitôt s’il était là depuis le début, car rien de votre position n’a changé. S’il affiche toujours zéro, l’affichage est écarté et tout le reste se joue sur la chaîne.
Quand l’échange a crédité une adresse qui n’est pas la vôtre
Un contrat d’échange doit décider à qui payer, et cette adresse n’est pas toujours celle que vous aviez en tête. Si le contrat crédite l’appelant, le compte qui a signé est le compte qui a reçu, et ce n’est pas le bon quand deux comptes sont ouverts dans le même profil de navigateur.
La version la plus délicate fait intervenir un intermédiaire. Les anciennes unités détenues sur une plateforme centralisée se trouvent à l’adresse de celle-ci, et un échange envoyé depuis une adresse de dépôt paie celui à qui elle appartient. Il en va de même pour un portefeuille à contrat intelligent ou un multisignature. Lisez l’événement de transfert et notez le champ destinataire : il nomme l’adresse créditée, et si ce n’est pas l’une des vôtres, les tokens n’allaient jamais apparaître là où vous regardez.
Un cas purement administratif mérite d’être écarté en premier. Certaines migrations émettent le nouveau token sur une autre chaîne que l’ancien, si bien que le crédit atterrit sur un réseau vers lequel votre portefeuille n’est pas pointé. Changer de réseau règle cela en quelques secondes.
Quand les anciennes unités sont parties et que rien n’est revenu
Si l’événement de transfert est absent et que balanceOf renvoie zéro alors que l’ancien solde a bel et bien disparu, la jambe du paiement n’a pas tourné, et les raisons sont peu nombreuses.
La première est une réserve vide. Un échange qui paie avec des tokens préfinancés plutôt que de les émettre peut accepter votre dépôt sans payer, parce que le compte d’où il paie a été vidé. C’est cette défaillance que l’échéance de la fenêtre d’échange sert à prévenir, et c’est pourquoi lire la réserve avant d’envoyer compte davantage que lire l’annonce.
La deuxième est un montant plus petit que prévu, et non absent. Vérifiez le ratio de conversion et les décimales des deux contrats avant de conclure que rien n’est arrivé. Un portefeuille détenant 40 000 anciennes unités, dans un regroupement d’une unité nouvelle pour quatre anciennes, a droit à 10 000 nouvelles unités, soit 25 % du chiffre auquel il était habitué. Sur un contrat dont la valeur decimals diffère, un crédit correct peut aussi s’afficher avec la virgule à une place inhabituelle.
La troisième est que les anciennes unités sont parties là où aucune jambe de paiement n’est attachée. Envoyer des tokens directement à une adresse de contrat au lieu de passer par l’interface qui l’appelle ne déclenche pas l’échange. La norme rend cela possible parce qu’approve autorise un dépensier à prélever sur votre compte jusqu’à un montant fixé, et que transferFrom sert à un flux de prélèvement permettant aux contrats de transférer des tokens en votre nom. Un contrat d’échange s’attend à prélever chez vous, pas à recevoir une chose dont on ne lui a jamais parlé.
Les migrations qu’une plateforme a exécutées pour votre compte
Un autre chemin produit la même plainte pour des raisons tout autres. Si vous déteniez l’ancien token sur une plateforme centralisée pendant la migration, celle-ci a converti son propre solde mutualisé et réécrit la ligne de votre compte, et l’événement s’est manifesté comme un changement de symbole sans aucune transaction de votre part.
Sur ce chemin il n’y a aucune transaction d’échange à examiner, donc aucune des vérifications sur la chaîne ne s’applique. Ce qui s’applique, c’est le calendrier de la plateforme : une suspension des dépôts et retraits de l’ancien token, une conversion appliquée aux soldes des comptes, puis une reprise sous le nouveau symbole. Un solde non encore converti pendant cette suspension est en pause, pas perdu.
Les deux chemins s’escaladent aussi différemment. Une plateforme qui ne vous a pas crédité est une question de support avec une contrepartie nommée. Un échange sur la chaîne qui n’a pas payé n’a aucune contrepartie dans la boucle, car le contrat a exécuté ce qui y a été écrit.
Ce qu’il faut vérifier, dans l’ordre
| Ordre | Ce qu’il faut vérifier | Ce qu’une réponse négative écarte |
|---|---|---|
| 1 | Votre portefeuille est-il sur le réseau d’émission du nouveau token | Un problème d’affichage dû à la mauvaise chaîne |
| 2 | Avez-vous ajouté à la main la nouvelle adresse de contrat | Un portefeuille qui ne suit pas un contrat neuf |
| 3 | balanceOf répond-il pour votre adresse | Toute explication restante par l’affichage |
| 4 | L’échange porte-t-il un événement de transfert vers vous | Un crédit qui a eu lieu puis a été déplacé |
| 5 | Quelle adresse cet événement nomme-t-il | Un paiement versé à une adresse de dépôt |
| 6 | Le ratio et les décimales collent-ils au montant reçu | Un crédit correct lu comme une erreur |
| 7 | Une plateforme a-t-elle mené la migration pour vous | Une enquête sur la chaîne qui ne s’appliquait pas |
Descendez cette liste plutôt que de la parcourir en travers. Chaque ligne écarte une classe d’explications, et les lignes du bas n’ont de sens qu’une fois celles du haut réglées. Les trois premières ne coûtent rien.
Un avertissement accompagne tout l’exercice. Un portefeuille qui semble avoir perdu un solde est exactement l’état que guettent les usurpateurs, et chaque vérification ci-dessus est une lecture publique que vous faites gratuitement. Personne n’a besoin de votre phrase de récupération pour lire un solde, et une offre de récupérer des tokens migrés disparus en échange de celle-ci est une seconde perte déguisée en réparation de la première.
En résumé
Une transaction d’échange en vert certifie qu’un appel s’est exécuté, et rien de plus. Le nouveau solde est inscrit sur le nouveau contrat, comme événement de transfert au moment du crédit et comme lecture de balanceOf ensuite, et les deux se lisent sans rien demander à personne. Tant que vous ne les avez pas lus, vous ignorez s’il s’agit d’un problème d’affichage ou de paiement.
Quand c’est un problème d’affichage, la séquence est courte : basculer sur le bon réseau, ajouter l’adresse du contrat à la main, et le solde est déjà là. Sinon, l’événement de transfert nomme l’adresse réellement créditée, et ce champ sépare un paiement envoyé au mauvais compte d’un paiement qui n’a jamais eu lieu. Tranchez lequel des deux vous avez devant vous avant d’envoyer quoi que ce soit ailleurs. Pour continuer à apprendre les fondamentaux, retrouvez d’autres articles de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Comment calculer l’autonomie de la trésorerie d’un token
- La mécanique de l'offre d'un jeton
- Qu'est-ce qu'un jeton crypto ? Jetons ou pièces, la différence
- Murs d'achat, murs de vente et profondeur du carnet d'ordres
- La stratégie de trading sur cassure
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d’information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en septembre 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] Ethereum Improvement Proposals, ERC-20: Token Standard (EIP-20, statut Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-747: wallet_watchAsset RPC Method (statut Final) eips.ethereum.org
