Offre totale ERC-20 et solde du portefeuille : quel chiffre est le vôtre ?

Pour un jeton ERC-20, balanceOf(account) indique le solde enregistré pour un compte. totalSupply() indique l’offre totale du contrat du jeton. Une offre élevée sur la page d’un jeton ne signifie pas que votre compte détient beaucoup de jetons.

Si vous avez ouvert un explorateur pour vérifier vos avoirs, choisissez le solde du compte. Pour savoir combien d’unités le contrat déclare au total, choisissez l’offre. Aucun de ces chiffres ne donne à lui seul une valeur en dollars, ne prouve le contrôle d’une adresse ou n’établit qu’un jeton est sûr.

Un contrat, deux questions différentes

La spécification ERC-20 les définit comme des méthodes distinctes en lecture seule. totalSupply() ne reçoit aucun compte en entrée. balanceOf nécessite l’adresse dont vous souhaitez examiner le solde. Le contrat du jeton appelé détermine l’actif sur lequel porte votre question.

Lecture	Entrée en plus du contrat du jeton	Question résolue
totalSupply()	Aucune	Quelle offre ce contrat déclare-t-il ?
balanceOf(account)	Adresse publique du compte	Quel solde enregistre-t-il pour ce compte ?

Imaginez par exemple un jeton dont l’offre est de 1000 unités et dont le compte A détient 25 unités. Les résultats corrects sont 1000 pour l’offre et 25 pour le compte A. Leur différence est normale. Il n’existe pas de réserve perdue de 975 unités à récupérer.

Ces quantités sont inventées pour l’explication, elles ne proviennent pas d’un jeton réel. Si vous ne savez pas quelle adresse désigne le compte et laquelle désigne l’actif, consultez le guide sur l’adresse du portefeuille et le contrat du jeton avant de lire l’un ou l’autre champ.

Qu’est-ce qui modifie un solde ou l’offre ?

Prenons un jeton hypothétique simple utilisant des transferts ordinaires, sans frais ni comptabilité personnalisée. Au départ, le compte A contient 25 jetons et le compte B en contient 975 :

Événement	Compte A	Compte B	Offre totale
État initial	25	975	1000
A transfère 5 à B	20	980	1000
100 nouveaux jetons sont créés pour B	20	1080	1100
B détruit 10 via une fonction de destruction	20	1070	1090

Le transfert change le détenteur des unités. La création produit des unités et la destruction par le mécanisme illustré les retire. La référence ERC20 d’OpenZeppelin décrit la comptabilité de création et de destruction, y compris la réduction de l’offre lors d’une destruction.

Ce tableau décrit ce modèle simple. Un jeton peut personnaliser les transferts ou appliquer d’autres règles comptables. Ne considérez pas l’envoi de jetons à une adresse qualifiée de « morte » comme la preuve que totalSupply() a diminué : vérifiez si le contrat réduit effectivement l’offre. Une étiquette sur une adresse n’exécute aucune fonction de destruction.

De même, votre solde peut rester identique tandis que l’offre change ailleurs. Le guide d’OpenZeppelin sur l’offre explique qu’ERC-20 laisse le mécanisme d’offre aux implémentations. Une lecture actuelle de l’offre ne prouve pas que toute création future est impossible.

Lire les deux chiffres sans déplacer de jetons

Lisez les deux chiffres sur le même contrat du jeton et le même réseau. La procédure suivante propose une vérification, elle ne rend pas compte d’un test de portefeuille effectué pour cet article. La documentation primaire a été consultée le 23 octobre 2026.

1. Notez le réseau et l’adresse complète du contrat du jeton. Vérifiez l’adresse du contrat dans les informations officielles de déploiement de l’émetteur. Des symboles identiques sur des réseaux différents ne suffisent pas pour comparer le même actif.
2. Notez le compte public à examiner. Relevez son adresse dans les détails de ce compte. Conservez-la séparément du contrat du jeton. Le suivi public fonctionne aussi pour des comptes que vous ne contrôlez pas : une consultation réussie ne prouve donc pas la propriété.
3. Ouvrez un explorateur ou un lecteur de contrats fiable pour ce réseau. Sélectionnez son interface de lecture seule pour le contrat vérifié du jeton. Lisez totalSupply(), puis balanceOf avec l’adresse du compte en entrée. Les libellés varient selon les interfaces ; utilisez les noms des fonctions pour identifier les questions.
4. Conservez l’état consulté avec les résultats. Notez le numéro de bloc lorsqu’il est disponible. Préférez les deux appels sur le même bloc. Deux lectures « latest » distinctes peuvent observer des états différents si un transfert, une création ou une destruction intervient entre elles.
5. Notez les unités avant de comparer. Conservez les réponses brutes et indiquez si l’interface les a déjà formatées. Un appel qui échoue signifie que les données sont indisponibles, pas que le solde est nul.

La documentation Ethereum sur ERC-20 présente des appels distincts pour l’offre et le solde d’un compte. Vous n’avez pas besoin de reproduire son environnement de développement pour comprendre le résultat nécessaire. Un explorateur proposant les méthodes publiques de lecture peut fournir les mêmes catégories d’informations.

La lecture de l’état public ne demande aucun transfert ni aucune autorisation de jetons. Si une page exige une phrase de récupération ou une signature pour révéler ces valeurs, cessez d’utiliser cette procédure. Ni l’une ni l’autre n’est une entrée de cette comparaison.

Appliquer les mêmes unités aux deux nombres

L’offre et les soldes des comptes utilisent la même échelle comptable du jeton. L’explication des décimales d’OpenZeppelin traite explicitement du formatage des deux. Pour un jeton hypothétique ayant 6 décimales vérifiées, l’offre brute 1000000000 représente 1000 jetons et le solde brut 25000000 représente 25 jetons.

Ne comparez pas une offre brute à un solde formaté. Ne divisez pas une valeur déjà convertie par une interface. Le guide des décimales ERC-20 explique comment établir cette échelle, l’absence de métadonnées et les arrondis. Ici, la mise à l’échelle est seulement une condition préalable à la comparaison de deux mesures différentes ; elle ne les rend pas égales.

Ce qu’un chiffre d’offre ne permet pas de trancher

totalSupply() d’ERC-20 n’est pas un calcul normalisé de l’offre en circulation. Un fournisseur peut appliquer des exclusions pour estimer la circulation. Sa méthode doit expliquer ces exclusions ; renommer une réponse du contrat ne permet pas de les obtenir. L’offre maximale constitue encore une autre question. OpenZeppelin décrit une extension plafonnant l’offre, mais ERC-20 n’impose pas cette fonction à chaque jeton.

Le résultat correspond aussi au déploiement précis et à l’état que vous avez lus. Il ne regroupe pas automatiquement les jetons de plusieurs chaînes, enveloppes ou contrats liés. Additionner des déploiements aux noms similaires peut produire un chiffre sans signification claire, sauf si leurs relations et leur comptabilité sont établies séparément.

Pour vérifier un portefeuille, conservez une courte fiche finale : réseau, contrat du jeton, compte, bloc, solde et unités. Ajoutez l’offre uniquement si elle répond à une question distincte. Si le solde du compte est de 25 jetons et l’offre du contrat de 1000, gardez les deux libellés avec leurs chiffres. La différence ne signifie pas que des jetons manquent sur le compte.