Qu’est-ce qu’ERC-20 ? Comprendre la norme des jetons Ethereum

ERC-20 est une interface commune pour les jetons gérés par des contrats intelligents sur Ethereum. Elle définit une manière partagée de demander des informations, comme le solde d’une adresse, et d’interagir avec les transferts de jetons. Il s’agit d’une norme que différents contrats peuvent mettre en œuvre, plutôt que du nom d’un jeton particulier.

Pour comprendre ce qu’est ERC-20, la distinction essentielle porte sur l’interface et les données renvoyées par chaque contrat. Deux contrats peuvent proposer les mêmes méthodes tout en indiquant des quantités totales et des soldes différents. Reconnaître cette interface ne suffit donc pas à établir la valeur d’un jeton ou la fiabilité de son implémentation.

Ce que l’interface ERC-20 standardise

Une interface de programmation, ou API, définit comment des logiciels peuvent interagir. ERC-20 fournit aux applications des noms de méthodes communs, associés à des significations précises. Ainsi, une application peut demander le solde d’une adresse avec balanceOf, plutôt que devoir utiliser une méthode différente pour chaque jeton.

La spécification EIP-20 présente cette interface et son objectif : permettre la réutilisation des jetons par d’autres applications, notamment les portefeuilles et les plateformes d’échange décentralisées. La documentation ERC-20 d’Ethereum décrit les méthodes et les événements qui soutiennent cette interopérabilité.

L’intérêt pratique est un vocabulaire commun pour les logiciels. Cet objectif ne garantit toutefois pas la compatibilité avec toutes les applications, notamment lorsqu’une implémentation ne respecte pas la norme. La présence de noms de méthodes familiers ne constitue pas non plus une validation du produit : évaluer un contrat particulier demande d’autres éléments que la description de son interface.

Quantité totale et solde d’une adresse : deux questions distinctes

totalSupply() renvoie la quantité totale de jetons du contrat interrogé. balanceOf(owner) renvoie le solde de jetons associé à l’adresse de compte fournie. La première méthode concerne l’ensemble de la quantité émise ; la seconde porte sur une adresse dans ce même contrat.

Pour interpréter un nombre, conservez donc deux repères : le contrat concerné et la question posée. Une indication comme « 25 jetons » reste incomplète si elle ne précise pas s’il s’agit du total ou du solde d’une adresse. Elle laisse également ouverte la question du contrat dont provient cette donnée.

La définition de totalSupply ne suffit pas à établir une valorisation de marché ni une mesure distincte de l’offre en circulation. De même, le solde d’une adresse exprime une quantité dans le contrat interrogé ; ce résultat ne suffit pas à déterminer sa valeur économique.

Exemple hypothétique : mêmes méthodes, soldes différents

Imaginons deux contrats de jetons entièrement fictifs, A et B, ainsi qu’une adresse de détenteur fictive. Les deux contrats proposent les mêmes noms de méthodes ERC-20. Pour cet exemple pédagogique, nous leur attribuons les quantités brutes inventées suivantes :

• Contrat A : totalSupply() renvoie 1000 et balanceOf(holder) renvoie 10.
• Contrat B : totalSupply() renvoie 5000 et balanceOf(holder) renvoie 25.

L’adresse interrogée est identique et la méthode de consultation porte le même nom. Pourtant, selon les hypothèses posées, son solde est de 10 dans A et de 25 dans B. Les quantités totales sont elles aussi propres à chaque contrat.

Cette distinction découle de deux prémisses : l’API est commune, tandis que le solde demandé concerne une adresse dans un contrat donné. On peut en déduire qu’une manière identique de poser la question n’exige pas une réponse identique de contrats différents. Elle ne réunit pas non plus leurs réponses en un solde unique.

Ces chiffres servent uniquement à expliquer l’interface. Ils ne décrivent aucun jeton déployé, aucun prix observé et aucune propriété de sécurité.

Ce que décrivent transfer et l’événement Transfer

Le rôle spécifié de transfer est de transférer la quantité de jetons fournie vers l’adresse de destination indiquée. La norme exige également l’émission d’un événement Transfer lorsque des jetons sont transférés. Ses champs déclarés indiquent une adresse d’origine, une adresse de destination et une valeur.

Ces éléments répondent à des besoins de lecture liés : la méthode décrit l’opération demandée, tandis que l’événement fournit un enregistrement structuré du transfert. Constater qu’un appel a été soumis ne suffit pas à établir que le transfert prévu a eu lieu.

Un événement, pris isolément, ne suffit pas davantage à établir la fidélité de l’implémentation à la norme, l’acquittement d’une obligation de paiement ou le comportement d’annulation d’exécution de l’EVM. Il faut préserver ces limites plutôt que tirer une conclusion générale de la seule présence d’un enregistrement.

Les transferts de valeur nulle sont explicitement prévus : ils doivent eux aussi émettre l’événement. On en déduit que la présence d’un événement Transfer ne suffit pas à établir que la quantité transférée est positive. Le champ de valeur reste indispensable à son interprétation.

Nom, symbole et décimales : des métadonnées facultatives

ERC-20 décrit trois méthodes utiles pour présenter les informations d’un jeton. Lorsqu’elles sont présentes, name() renvoie son nom, symbol() son symbole et decimals() le nombre de décimales utilisé pour représenter les montants à destination de l’utilisateur.

Ces trois méthodes sont facultatives. La spécification précise que les interfaces et les autres contrats ne doivent pas présumer la présence de ces valeurs. Une application doit donc tenir compte de leur éventuelle absence, plutôt que supposer silencieusement un nom, un symbole ou une précision décimale.

À partir de leurs définitions, on peut aussi déduire que les métadonnées et les soldes sont des informations distinctes. Le nom et le symbole décrivent le jeton ; les décimales concernent la représentation des montants. Aucune de ces réponses n’est elle-même la quantité associée à une adresse que renvoie balanceOf.

Pour approfondir la conversion entre quantités brutes et montants affichés, consultez notre guide des décimales ERC-20 et des unités brutes. Ici, le point essentiel reste la séparation entre les informations de présentation et la question du solde.

Une liste de vérification pour lire une description ERC-20

1. Identifier le contrat. Rattacher chaque quantité au contrat de jeton étudié.
2. Identifier la question. Distinguer la quantité totale du solde de l’adresse fournie.
3. Séparer métadonnées et quantités. Un nom, un symbole ou un nombre de décimales ne répond pas à la question du solde.
4. Prévoir des métadonnées absentes. Ne pas présumer que les trois méthodes facultatives sont disponibles.
5. Lire les champs du transfert. Examiner ensemble l’origine, la destination et la valeur, y compris lorsqu’elle est nulle.
6. Conserver les limites de l’analyse. Une API commune favorise l’interopérabilité ; sa présence seule ne suffit pas à établir une compatibilité universelle, une valeur économique, la fidélité de l’implémentation ou l’acquittement d’un paiement.

Cette liste aide à interpréter une documentation ou un exemple pédagogique. Son utilisation ne nécessite aucun envoi de jetons ni aucune signature dans un portefeuille. Les sources citées étayent l’explication de la norme ; leur attribution ne constitue pas une validation de sécurité d’un contrat particulier.

Contenu pédagogique préparé avec l’aide de l’IA à partir des documents primaires cités. L’exemple fictif explique l’interface et ne recommande aucune transaction réelle.