Un projet passe à un nouveau contrat de jeton, annonce une fenêtre d’échange, puis la fenêtre se referme. Des mois plus tard, vous ouvrez un ancien portefeuille et le solde de l’ancien jeton est toujours là. Savoir s’il peut encore être converti n’est pas une question à réponse unique. Dans une migration, trois choses différentes expirent, chacune est appliquée à un endroit différent, et une seule d’entre elles est appliquée par du code.
Ce qu’une migration de jeton déplace vraiment
Une migration ne déplace vos jetons nulle part. L’ancien contrat continue de tourner à sa propre adresse, et votre solde reste dans son registre aussi longtemps que la chaîne tourne. Ce qu’une migration propose, c’est un échange : vous remettez des anciennes unités à un contrat d’échange ou à une plateforme, et celle-ci vous crédite la créance équivalente dans un nouveau registre.
Cet échange passe par la plomberie ordinaire des jetons. Dans la norme ERC-20, `approve` autorise un dépensier à retirer de votre compte jusqu’à un montant fixé, et `transferFrom` déplace des jetons d’une adresse à une autre ; la norme présente ce couple comme un flux de retrait qui permet aux contrats de déplacer des jetons en votre nom. Un contrat d’échange est l’un de ces dépensiers, et la chaîne ne lui accorde aucun statut particulier.
Deux conséquences en découlent. Votre ancien solde ne se dégrade ni ne s’éteint tout seul, et l’échéance n’est jamais une propriété des jetons que vous détenez. L’échéance appartient à celui qui se tient de l’autre côté de l’échange, prêt à payer. La question n’est donc pas de savoir si vos jetons ont expiré. Elle est de savoir ce qui est arrivé à la contrepartie.
Trois choses peuvent expirer, et ce ne sont pas les mêmes
Dans une annonce de migration ordinaire, le mot échéance fait beaucoup trop de travail. Décomposez-le et vous verrez plusieurs horloges distinctes, chacune appliquée ailleurs.
La première est la date annoncée elle-même, une ligne dans un billet ou une bannière dans une application. Rien sur la chaîne ne la lit. La deuxième est une vérification écrite dans le contrat d’échange, qui refuse de s’exécuter dès que l’horodatage du bloc courant dépasse une valeur fixée dans le code. La troisième est la réserve de nouveaux jetons sur laquelle le contrat paie, et celui qui l’a alimentée peut la retirer une fois que le projet considère la migration terminée.
| Ce qui a expiré | Où cela est appliqué | Ce qu’une réouverture demanderait |
|---|---|---|
| La date annoncée | Nulle part sur la chaîne | Rien, le contrat ne l’a jamais vérifiée |
| Une vérification d’horodatage dans le contrat d’échange | Le code du contrat | Une voie de mise à jour, si elle a été prévue |
| La réserve de nouveaux jetons | Un solde sur la chaîne | Que quelqu’un réalimente le contrat |
| Un guichet de migration chez une plateforme | La politique interne de cette plateforme | Une décision de cette plateforme |
Tout ce qui suit sert à déterminer dans quelle ligne vous êtes.
Lisez le contrat avant de le déclarer fermé
Les deux premières lignes, vous pouvez les trancher vous-même et gratuitement. Ouvrez le contrat d’échange dans un explorateur de blocs et lisez son code source vérifié. Si la fonction d’échange ne contient aucune comparaison avec un horodatage de bloc, il n’y a pas d’échéance dans le code, et la date annoncée n’a jamais été qu’une communication. Dans ce cas, un échange envoyé un an plus tard s’exécute exactement comme un échange envoyé le premier jour.
S’il y a une vérification d’horodatage, c’est un constat différent, et ferme. Le code d’un contrat fait ce qu’on y a écrit, et une condition qui annule la transaction après un moment fixé continuera de l’annuler. Aucun ticket d’assistance n’y change rien, car il n’y a personne à convaincre : le refus est une ligne de code qui s’exécute comme prévu.
La seule nuance est la possibilité de mise à jour. Si l’échange se trouve derrière un proxy dont la logique peut être remplacée, l’échéance peut en principe être levée par celui qui détient ce pouvoir. C’est une décision du projet et non un droit que vous détenez, mais c’est la différence entre une porte fermée et une porte soudée, et lire le contrat est la façon de les distinguer.
Quand le contrat est ouvert mais la réserve vide
Un contrat sans échéance ne peut toujours pas payer depuis un compte vide. Les nouveaux jetons doivent venir d’une réserve détenue à l’adresse d’échange, et si le projet a écrit une fonction qui balaie le reliquat à la fermeture de la fenêtre, il peut vider cette réserve. Après ce balayage, la fonction d’échange peut encore accepter vos anciens jetons et échouer quand même, parce qu’il n’y a plus rien derrière la jambe de paiement.
Prenons un exemple. Un projet consolide à raison d’une unité nouvelle pour dix anciennes, et un portefeuille détient 25 000 anciennes unités, la créance est donc de 2 500 nouvelles. Supposons que 96% de l’offre ancienne soit passée pendant la fenêtre ; les 4% restants sont précisément la part que réclament les retardataires, et savoir si le contrat peut encore honorer ces créances revient simplement au solde de nouveaux jetons détenu à l’adresse d’échange. Ce solde est public. Vérifiez-le avant d’envoyer quoi que ce soit.
C’est le cas qui punit l’optimisme. Envoyer d’anciens jetons dans un contrat incapable de vous payer ne vous laisse pas là où vous étiez : les anciennes unités sont parties vers une adresse qui n’a jamais été écrite pour les restituer, et vous ne détenez rien de nouveau. Lisez d’abord la réserve, et si elle est vide, n’envoyez pas.
Les migrations qu’une plateforme a faites pour vous
Certaines migrations n’ont jamais touché votre portefeuille. Si vous déteniez l’ancien jeton sur une plateforme centralisée au moment de l’échange, la plateforme a converti son propre solde global et réécrit l’écriture de votre compte, si bien que la migration est apparue chez vous comme un changement de symbole et rien d’autre.
Cette voie a sa propre horloge, et c’est une politique, pas une règle de la chaîne. Une plateforme annonce une fenêtre de conversion, crédite les soldes qui arrivent dedans, et cesse à un moment donné. La forme est familière depuis le délistage d’un jeton : un avis, une fenêtre, puis un accès fermé, la suite dépendant de savoir si cette maison maintient encore un traitement manuel pour les retardataires.
Il y a donc ici deux questions et non une, et leurs réponses diffèrent. Savoir si la plateforme créditera un dépôt tardif d’anciens jetons est une question d’assistance. Savoir si le contrat d’échange sur la chaîne paiera encore est une question de code. Répondez-y séparément, car un non de l’une ne dit rien de l’autre.
Ce qui reste quand la voie sur la chaîne est fermée pour de bon
Supposons le code fermé, la réserve balayée, et aucun guichet pour traiter une demande tardive. L’ancien jeton n’a pas cessé d’exister. C’est un solde dans un contrat qui tourne toujours, il peut encore être transféré, donc encore vendu à qui veut l’acheter, au prix que donne le marché d’un registre abandonné.
Ne cherchez pas de contournement en envoyant les anciennes unités quelque part qui semble prometteur. Les envoyer au nouveau contrat du jeton, ou à l’ancien contrat lui-même, relève de la même classe d’erreur que d’envoyer des cryptos à la mauvaise adresse : un contrat n’a pas de clé privée, et si personne n’a écrit de fonction pour ressortir les jetons égarés, personne ne le peut. La norme ERC-223 a été écrite précisément autour de cette défaillance, en notant que des jetons envoyés à un contrat par un transfert simple arrivent comme un solde dont le contrat n’a jamais connaissance.
Le résumé honnête de ce cas est que la taille de la perte est déjà fixée, et que chaque transaction supplémentaire ne peut que l’augmenter. Garder la position ne coûte rien. Deviner un sauvetage peut coûter le reste.
L’échéance de migration est un appât pour les usurpateurs
Une fenêtre qui expire crée de l’urgence, un afflux de détenteurs désorientés et une raison légitime pour un projet de demander aux gens de connecter un portefeuille. Les attaquants n’ont rien à inventer de tout cela. Il leur suffit d’un site sosie. C’est la forme de l’usurpation d’identité, et c’est pourquoi un résultat de recherche est la mauvaise façon d’atteindre un portail de migration.
Le mécanisme que vise un faux portail est celui qu’utilise un échange réel. Une migration authentique demande une autorisation pour que le contrat puisse tirer vos anciens jetons, et les approbations de jetons accordées à un attaquant font exactement ce qu’elles disent : elles laissent cette adresse prendre le solde que vous avez approuvé. Accordez une autorisation limitée plutôt qu’illimitée, recoupez l’adresse du contrat avec l’annonce publiée par le projet lui-même, et atteignez le site par votre propre signet.
Une règle traverse toute cette catégorie. Chaque fait dont vous avez besoin dans une migration tardive se lit gratuitement dans un explorateur public : le code source du contrat, la vérification d’horodatage, le solde de la réserve. Quiconque facture la réouverture d’une migration fermée, ou réclame une phrase de récupération pour le faire, vous vend la seconde perte et non la réparation de la première.
En résumé
Les anciens jetons n’expirent pas. Les contreparties, si. Une date annoncée n’engage personne sur la chaîne ; une vérification d’horodatage dans le contrat d’échange engage tout le monde, projet compris ; et une réserve balayée ferme la porte tout aussi fermement en laissant la poignée en place. Ces trois cas se ressemblent à l’écran d’un portefeuille et sont totalement différents en dessous.
L’ordre de travail est fixe. Lisez le contrat d’échange dans un explorateur, cherchez la vérification d’horodatage, puis lisez le solde de la réserve à cette adresse, et interrogez la plateforme séparément si une plateforme était impliquée. Si tout cela revient fermé, l’ancien solde reste le vôtre et reste transférable, et aucune urgence ne devrait vous pousser à l’envoyer là où rien ne peut revenir. Pour continuer à apprendre les fondamentaux, retrouvez d’autres articles de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Comment révoquer une délégation de gouvernance
- Pourquoi une migration de jeton demande une approbation
- Migration de tokens terminée mais nouveaux tokens absents
- Comment calculer l’autonomie de la trésorerie d’un token
- Futures à marge en crypto ou à marge en USDT : quel contrat trader ?
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, les méthodes approve et transferFrom (statut : Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, section Motivation (statut : Final) eips.ethereum.org
