Transaction Ethereum réussie, mais jetons manquants : que vérifier ?

Une transaction Ethereum réussie ne prouve pas, à elle seule, que les jetons ERC-20 prévus sont arrivés sur le compte prévu. Success indique si la transaction entière s’est terminée sans annulation de l’exécution. Confirmez l’action exécutée, le contrat exact du jeton, le destinataire et les preuves du transfert avant de considérer le paiement comme effectué.

Commencez par le hash de la transaction initiale sur Ethereum Mainnet. N’envoyez pas un autre paiement uniquement pour tester un affichage de portefeuille périmé. Ce guide décrit l’inspection en lecture seule d’une transaction incluse dans un bloc, pas un service de récupération ni des instructions pour signer une autre transaction.

Lire Success au bon niveau

EIP-658 définit le statut du reçu comme le résultat de l’appel au niveau supérieur. Le statut 1 signifie réussite et 0 échec ; JSON-RPC les représente par 0x1 et 0x0. C’est une indication sur l’exécution, pas une liste de tous les résultats attendus de l’application.

Un contrat peut gérer une opération interne infructueuse sans annuler toute la transaction. La norme ERC-20 impose aussi explicitement aux appelants de gérer un false renvoyé. Ne supposez pas que toutes les implémentations de jetons signalent les transferts infructueux par une annulation de l’exécution.

Le statut du reçu n’est pas le true ou false renvoyé par une méthode du jeton. La référence des reçus expose le statut, le bloc et les journaux de la transaction ; elle ne transforme pas le champ de statut en valeur de retour d’un appel interne. Des détails d’exécution décodés peuvent aider, mais une erreur dans une trace ou un simple nom de méthode s’interprètent dans le contexte de l’action complète.

Si le reçu global indique Failed, consultez le guide des transactions échouées et du gas. Si la transaction n’a pas encore été incluse, utilisez le guide des transactions en attente. Les vérifications ici concernent une transaction incluse portant le statut Success.

Déterminer si l’action était un transfert

Une application peut demander une autorisation avant un transfert, un échange ou un dépôt ultérieur. Dans ERC-20, approve définit un plafond de dépense ; cet appel n’envoie pas lui-même le montant autorisé au bénéficiaire de l’autorisation. Sa transaction réussie peut donc laisser le solde du jeton inchangé.

Examinez l’action et les données d’entrée décodées lorsqu’elles sont disponibles. Notez le contrat destinataire de la transaction et l’opération voulue. Le champ To de la transaction peut désigner un routeur ou un autre contrat plutôt que le destinataire final du jeton. Ne confondez pas ce champ avec le destinataire enregistré dans un transfert de jetons.

Observation	Ce qu’elle établit	Ce qu’il reste à vérifier
Statut du reçu Success	Exécution au niveau supérieur réussie	Résultat de l’action voulue
Autorisation réussie	Une action d’autorisation a été exécutée	Transfert ou action du protocole distincts
Journal Transfer correspondant	Ce contrat a émis un enregistrement de transfert	Identité, montant et état résultant
Solde actuel du jeton	Quantité du compte lors de la lecture	Autres activités et instant d’observation

Conservez les hashes des étapes distinctes. Une autorisation réussie suivie d’un transfert représente deux enregistrements ; une seule étiquette Success ne remplace pas les deux. Le message de fin d’une application n’établit pas non plus qu’une plateforme d’échange a crédité un dépôt ou qu’un pont a terminé sur une autre chaîne. Ces services ont leurs propres enregistrements et règles.

Relier l’enregistrement au jeton et au destinataire exacts

L’événement Transfer de la norme enregistre l’expéditeur, le destinataire et le montant. Dans les journaux du reçu, vérifiez l’adresse du contrat émetteur, puis comparez ses champs décodés au paiement voulu. Un symbole familier ne suffit pas : un autre contrat peut utiliser le même nom ou émettre un événement d’apparence semblable.

Vérifiez le réseau et l’adresse complète du contrat du jeton auprès d’une source déjà fiable pour vous. Comparez l’adresse complète du destinataire, pas seulement le début et la fin abrégés. Notre guide sur l’adresse de portefeuille et le contrat du jeton explique quelle adresse identifie l’actif et laquelle identifie le compte.

Vérifiez le montant en plus de la présence de l’événement. ERC-20 prévoit les transferts de valeur nulle : un événement Transfer ne prouve donc pas un paiement positif. Si le journal présente un entier brut, utilisez l’échelle décimale vérifiée du jeton pour l’interpréter. N’appliquez pas deux fois le formatage et n’inventez pas d’échelle si les métadonnées sont indisponibles.

Supposons par exemple un paiement voulu de 25 jetons. Une autorisation réussie pour 25 jetons n’est pas ce paiement. Un enregistrement de transfert de zéro jeton non plus. Un enregistrement de 25 jetons provenant d’un autre contrat ne prouve toujours pas la réception de l’actif voulu. Ce sont des comparaisons hypothétiques, pas des observations d’un portefeuille réel.

Comparer l’état sans attribuer chaque changement à ce hash

Lisez le solde du destinataire pour le même contrat de jeton sur le même réseau. La méthode standard balanceOf(account) indique le solde de jetons du compte, sans expliquer ce qu’une transaction a changé. Une galerie de portefeuille ou un total de portefeuille en monnaie fiduciaire peut avoir du retard ou décrire autre chose.

Notez le bloc ou l’heure de la lecture. Le dernier solde peut inclure des transferts postérieurs à la transaction examinée. Même une comparaison entre le bloc précédent et celui qui la contient peut inclure d’autres transactions de ce bloc. N’affirmez pas qu’une différence isole ce hash sans examiner les autres activités.

Si les preuves divergent, laissez cette divergence visible. Une mécanique de jeton particulière, un lecteur incompatible ou la comptabilité interne d’un protocole peuvent nécessiter la documentation et l’assistance du contrat exact. Un journal de contrat n’est pas un certificat d’authenticité ou de sécurité. Une lecture de solde échouée signifie inconnu, pas solde nul.

Conserver un relevé avant de décider d’un autre paiement

Utilisez un explorateur ou un lecteur de contrat connu, accessible par un chemin fiable. Ces vérifications publiques ne nécessitent ni connexion de portefeuille, ni signature, ni autorisation, ni phrase de récupération. La procédure repose sur la documentation primaire vérifiée le 26 octobre 2026 ; elle n’a pas été testée sur une transaction réelle pour cet article.

1. Identifier la transaction initiale. Conservez Ethereum Mainnet, le hash complet, l’expéditeur, le bloc et le statut global du reçu.
2. Identifier l’action réelle. Distinguez autorisation, transfert, échange et dépôt. Conservez les hashes distincts du parcours.
3. Comparer les preuves du jeton. Notez le contrat émetteur, l’expéditeur du transfert, le destinataire et le montant avec ses unités. Comparez-les à l’actif et au compte prévus.
4. Vérifier l’état résultant. Lisez le solde du jeton exact ou l’enregistrement pertinent du protocole, en notant le bloc ou l’heure et les autres activités pouvant l’affecter.
5. Laisser les points non résolus ouverts. Conservez les journaux manquants, lectures échouées et écarts inexpliqués. Consultez l’assistance officielle du portefeuille ou du protocole avec les données publiques de la transaction avant de décider si une autre transaction convient.

L’inspection est terminée lorsque vous pouvez expliquer ce qui a réussi et les preuves qui étayent la réception voulue. Si la transaction a réussi mais que le paiement reste non vérifié, indiquez-le ainsi. Le badge Success est une preuve utile ; il ne permet pas d’ignorer l’actif, le destinataire ou le montant.