La page de frappe a annoncé un succès. L’explorateur affiche une coche verte à côté des frais que vous avez payés. La galerie du portefeuille est vide. Trois systèmes répondent ici à trois questions différentes, et un seul d’entre eux est la chaîne. Avant de conclure que quelque chose a mal tourné, séparez la question de savoir si un jeton existe de celle de savoir si une application accepte de le dessiner.
Ce qu’atteste une transaction de frappe réussie
Une transaction confirmée vous dit que votre appel est entré dans un bloc et que la partie la plus externe de l’exécution n’est pas revenue en arrière. C’est tout. Un statut du reçu en succès est une affirmation sur l’appel, pas un inventaire de ce que l’appel a produit.
Une frappe est une fonction de contrat comme une autre. Elle peut aller jusqu’au bout sans retour en arrière et n’avoir pourtant rien créé pour vous : une boucle par lots qui a sauté votre entrée, un appel interne que le contrat a délibérément absorbé, une fonction payable qui a pris les frais et a inscrit le jeton à une autre adresse. Le reçu ne distingue pas ces cas d’une frappe ordinaire, parce qu’on ne le lui a jamais demandé.
La question n’est donc pas de savoir si la transaction a fonctionné. Elle est de savoir s’il existe désormais un jeton avec votre adresse inscrite en face. Ce fait est consigné ailleurs, et il l’est deux fois : une fois comme événement au moment de la création, une fois comme valeur que le contrat renverra si on la lui demande.
L’événement qui dit qu’un jeton a été créé
Dans le standard de jetons ERC-721, une frappe n’est pas une opération distincte. C’est un transfert sans expéditeur. Le standard définit un unique événement Transfer, émis lorsque la propriété d’un NFT change par quelque mécanisme que ce soit, et précise que cet événement est émis quand des jetons sont créés et quand ils sont détruits : dans le premier cas le champ expéditeur est mis à zéro, dans le second c’est le champ destinataire.
Cela vous donne une chose précise à chercher. Un événement de transfert sur la transaction de frappe, depuis l’adresse zéro, vers votre adresse, portant un identifiant de jeton, c’est la chaîne qui dit qu’un jeton a été créé et vous a été attribué. Son absence est tout aussi instructive.
ERC-1155 suit la même convention dans ses propres événements : lors de la frappe de jetons, l’argument expéditeur doit être mis à l’adresse zéro. La forme de la preuve ne change donc pas d’un standard à l’autre, même si la prise en charge par les portefeuilles, elle, peut changer.
La lecture qui tranche à qui il appartient
L’événement est l’enregistrement d’un instant. La propriété maintenant est une lecture distincte, et ERC-721 y répond directement. Appelez ownerOf avec un identifiant de jeton et le contrat renvoie l’adresse qu’il consigne comme détentrice. Le standard ajoute que les jetons attribués à l’adresse zéro sont considérés comme invalides et que les requêtes à leur sujet lèvent une erreur : un appel qui échoue au lieu de renvoyer une adresse est donc lui-même une réponse, à savoir qu’aucun jeton portant cet identifiant n’est attribué à qui que ce soit en ce moment.
À côté, balanceOf compte les jetons qu’une adresse détient dans ce seul contrat. Dans une collection de 10 000 identifiants, ownerOf répond pour exactement l’identifiant que vous nommez, et balanceOf répond combien de jetons de ce contrat se trouvent à votre adresse sans que vous ayez à deviner des identifiants. Aucune de ces deux lectures ne dépend de la disponibilité d’une place de marché, d’une galerie ou d’une image.
| La question que vous posez | Où la réponse est consignée |
|---|---|
| La transaction est-elle entrée dans un bloc | Le numéro de bloc sur le reçu |
| L’appel le plus externe a-t-il évité le retour en arrière | Le statut du reçu |
| Un jeton a-t-il été créé pour moi | Un événement de transfert dont le champ expéditeur est l’adresse zéro |
| À qui appartient cet identifiant maintenant | L’adresse que ownerOf renvoie pour lui |
| Combien de jetons de la collection je détiens | Le nombre que balanceOf renvoie pour mon adresse |
| Mon portefeuille va-t-il le dessiner | Rien sur la chaîne ne consigne cela |
La dernière ligne est celle qui dénoue toute la situation. Il n’existe pas de champ sur la chaîne pour dire si une application affiche votre jeton, et c’est pourquoi une galerie vide n’est jamais à elle seule une preuve en matière de propriété.
Pourquoi le jeton peut être à vous sans que le portefeuille montre quoi que ce soit
Une galerie de portefeuille n’est pas une lecture en direct de la chaîne. Rien dans l’un ou l’autre standard ne permet de demander à une chaîne tous les jetons qu’une adresse détient à travers tous les contrats ; les portefeuilles et les places de marché font donc tourner des indexeurs qui surveillent les événements de transfert, notent ce qu’ils voient et vous servent ce relevé. Ce que vous faites défiler, c’est leur table, pas le contrat.
Quatre choses concernant cette table peuvent la laisser vide alors que le contrat dit autre chose. L’indexeur n’a peut-être pas encore traité votre bloc, auquel cas la galerie se remplit d’elle-même. La collection peut être filtrée comme indésirable ou non vérifiée, ce qui est une règle d’affichage que le portefeuille applique et qu’on peut désactiver. Le portefeuille peut indexer un standard et pas l’autre, si bien qu’un jeton frappé sous ERC-1155 n’affiche rien dans une vue bâtie pour le seul ERC-721. Et un portefeuille qui exige d’ajouter une collection à la main n’affiche rien pour elle tant que ce n’est pas fait.
Rien de tout cela ne se répare en renvoyant quoi que ce soit sur la chaîne. Envoyer une seconde transaction parce qu’une galerie paraît vide, c’est risquer de frapper à nouveau et de payer à nouveau un jeton que vous détenez déjà.
Quand le jeton est parti ailleurs
L’autre famille de causes, c’est que la frappe a fonctionné exactement comme elle est écrite et que le jeton ne se trouve pas à l’adresse que vous regardez.
Le destinataire d’une frappe est décidé par le contrat, pas par l’interface. Une fonction qui frappe au profit de l’appelant inscrit le jeton à l’adresse qui a signé la transaction, c’est-à-dire au compte connecté à ce moment-là et non à celui sélectionné maintenant dans le portefeuille. Un portefeuille dérivé d’une phrase de récupération détient plus d’une adresse, et celle que vous consultez n’est pas forcément celle qui a frappé.
Les comptes en contrat intelligent ajoutent une seconde version du même décalage. ERC-721 exige qu’un transfert sécurisé vérifie si le destinataire est un contrat intelligent et, si c’est le cas, appelle le hook de réception sur lui et lève une erreur quand la valeur de retour attendue ne revient pas. Un compte en contrat qui implémente ce hook reçoit le jeton normalement, et le jeton habite dès lors à l’adresse du contrat. Toute vue pointée sur la clé de signature plutôt que sur le compte n’affichera rien pendant que le jeton repose sans encombre là où il a été envoyé.
Vient ensuite le réseau. La même adresse existe sur chaque chaîne qui utilise le même format d’adresse, si bien qu’un portefeuille réglé sur un réseau dessine une galerie vide pour un jeton frappé sur un autre. Le jeton n’a pas disparu. C’est la vue qui est filtrée sur une chaîne où le jeton n’a jamais été.
Quand le jeton est là et qu’il ne manque que l’image
Un symptôme distinct est une tuile présente mais vide, grise, ou étiquetée d’un nom d’attente. Ici la propriété n’est pas du tout en cause : le portefeuille a dessiné le jeton, ce qui veut dire qu’il a indexé l’événement de transfert et l’identifiant.
Derrière la tuile se trouve le document de métadonnées et non le jeton, et l’instrument approprié est un rafraîchissement des métadonnées, qui demande à la plateforme de relire le pointeur et le document. Un rafraîchissement ne déplace rien sur la chaîne et ne crée aucune propriété : c’est donc le bon outil pour une image périmée et le mauvais pour un jeton qui n’apparaît jamais. Démêler ces deux cas avant d’agir épargne les heures qui partent à rafraîchir un jeton que le portefeuille n’allait de toute façon pas dessiner.
| Ce que vous voyez | Ce qui est vrai en dessous | Ce qui le change |
|---|---|---|
| Galerie vide, un événement de transfert vers votre adresse existe | L’indexeur est en retard ou filtre la collection | Attendre, un réglage du portefeuille, ou ajouter le contrat à la main |
| Galerie vide, aucun événement de transfert sur la transaction | Rien n’a été créé pour votre adresse | Lire le contrat avant toute action sur la chaîne |
| Jeton visible avec une image d’attente ou sans visuel | La copie des métadonnées enregistrée est en retard sur l’actuelle | Un rafraîchissement des métadonnées |
| Jeton visible sur un explorateur, absent du portefeuille | Le portefeuille n’indexe pas ce standard ou cette collection | Un réglage du portefeuille, ou une autre visionneuse |
| ownerOf renvoie une adresse qui n’est pas la vôtre | Le jeton a été frappé ou envoyé vers un autre compte | Regarder cette adresse à la place |
Quoi vérifier, dans l’ordre
Ouvrez la transaction sur un explorateur de blocs et lisez ses journaux plutôt que son en-tête. Un événement de transfert depuis l’adresse zéro, avec un identifiant de jeton, vous dit qu’un jeton a été créé. L’adresse dans le champ destinataire vous dit à qui il est. Si cette section est vide, tout le reste de la recherche porte sur le contrat et non sur votre portefeuille.
Appelez ensuite ownerOf sur le contrat avec cet identifiant de jeton. Les explorateurs exposent les lectures de contrat sans signature ni frais : cela ne coûte donc rien et renvoie la réponse propre à la chaîne plutôt que la copie qu’en a un indexeur. Si l’adresse qui revient est l’une des vôtres, le jeton est à vous et tout ce qui reste est une question d’affichage.
Vérifiez ensuite ce que vous regardez : l’adresse sélectionnée dans le portefeuille, le réseau sur lequel il est réglé, et si la collection est masquée. Ces trois réglages rendent compte de l’écart entre un contrat qui vous désigne comme détenteur et une galerie qui n’affiche rien.
En résumé
Une frappe qui se confirme prouve qu’un appel n’est pas revenu en arrière. Elle ne prouve pas qu’un jeton existe, et elle ne nomme aucun détenteur. Ces deux faits vivent dans l’événement de transfert de la transaction et dans ce que ownerOf renvoie ensuite, et tous deux se lisent sans qu’une application y consente.
Une galerie vide est une affirmation sur un indexeur. Lisez l’événement, lisez ownerOf, puis vérifiez l’adresse, le réseau et le filtre de collections. Si le contrat vous désigne comme détenteur, rien n’a besoin d’être renvoyé, signé ni payé une seconde fois. Pour continuer à apprendre les fondamentaux, retrouvez d’autres articles de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Propriété fractionnée d’un jeton non fongible et où se situe le risque
- Le processus de révélation d’un NFT : ce qui change et quand
- Les redevances optionnelles des NFT expliquées
- The DATA Foundation, anciennement Story Protocol : la migration du jeton IP vers DATA
- Portefeuilles omnibus et ségrégués, et risque de réhypothécation
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, EIP-721: Non-Fungible Token Standard, section spécification eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-1155: Multi Token Standard, section spécification eips.ethereum.org
