Les standards de tokens expliqués : ERC-20, ERC-721, ERC-1155 et plus

Un standard de jeton est une spécification publiée qui indique à un contrat de jeton quelles fonctions exposer et quels événements émettre. Les portefeuilles, les échanges et les applications peuvent alors gérer n’importe quel jeton conforme sans code personnalisé pour chacun. Ce guide couvre les standards que vous rencontrerez le plus souvent (ERC-20, ERC-721, ERC-1155, et leurs équivalents sur Tron et Solana). Il aborde également le fonctionnement des décimales ERC-20 et ce qu’il faut vérifier avant d’intégrer un jeton dans un flux de paiement.

TL;DR

• Un standard de jeton définit une interface (fonctions et événements) ainsi que des règles de comportement, afin que les logiciels puissent interagir avec n’importe quel jeton conforme de la même manière.
• L’ERC-20 est pour les jetons fongibles, l’ERC-721 pour les NFT uniques, et l’ERC-1155 pour plusieurs types de jetons dans un seul contrat.
• Le TRC-20 reflète l’ERC-20 sur Tron, et Solana utilise son propre programme de jeton SPL, donc « même standard » ne signifie jamais « même chaîne ».
• Les montants sur la chaîne sont des entiers. La valeur optionnelle decimals indique où placer la virgule pour l’affichage.
• La conformité n’est pas garantie. Testez le comportement réel de chaque jeton avant de vous y fier.

Table des matières

• Ce qu’un standard de jeton définit réellement
• ERC-20 : le standard des jetons fongibles
• Décimales ERC-20 : gérer les montants correctement
• ERC-721 : jetons non fongibles
• ERC-1155 : plusieurs types de jetons dans un seul contrat
• Comparaison des trois standards Ethereum
• Standards de jetons sur d’autres chaînes
• Ce qu’il faut vérifier avant d’intégrer un jeton
• Perspective : pourquoi les standards ne sont que la moitié du travail
• Mettre les standards au travail avec Chaingateway
• FAQ
• Sources

Ce qu’un standard de jeton définit réellement

Un jeton n’est pas une pièce native. C’est un enregistrement conservé à l’intérieur d’un contrat intelligent : qui détient combien, et quelles règles régissent son déplacement. Sans spécification partagée, chaque jeton exposerait ses propres noms de fonctions et chaque portefeuille aurait besoin de code sur mesure pour lire les soldes ou envoyer des transferts.

Un standard résout ce problème. Selon la page des standards de jetons d’ethereum.org, les standards définissent comment les jetons se comportent et interagissent, ce qui maintient les contrats intelligents composables et permet aux nouveaux jetons de fonctionner avec les échanges et applications décentralisés existants. L’aperçu de la conception de jetons du NIST décrit les ERC comme fournissant des déclarations de fonctions et d’événements, des contraintes et exigences, et parfois des implémentations de référence.

En pratique, un standard vous donne quatre choses :

1. Des fonctions appelables, telles que la lecture d’un solde ou le déplacement de jetons.
2. Des événements, que le contrat émet pour que les logiciels externes puissent suivre l’activité.
3. Des types de données et contraintes, tels que la représentation des montants.
4. Des exigences comportementales, telles que les appels qui doivent déclencher quel événement.

Sur Ethereum, ces spécifications sont proposées sous forme d’ERC, la catégorie au niveau application des Ethereum Improvement Proposals. D’autres chaînes ont leurs propres processus et noms, mais l’idée reste la même.

ERC-20 : la norme de jeton fongible

L’ERC-20 a été créé en 2015 et définit une API standard pour les jetons au sein de contrats intelligents, afin que les portefeuilles et les échanges décentralisés puissent les réutiliser. « Fongible » signifie que chaque unité est interchangeable avec toute autre unité, comme les dollars ou les kilogrammes d’or. Les stablecoins, les jetons de gouvernance et la plupart des jetons de paiement la suivent.

L’interface, telle que répertoriée dans la documentation ERC-20, comprend :

Fonction ou événement	Ce qu’elle fait
totalSupply	Renvoie le nombre total de jetons en existence
balanceOf	Renvoie le solde d’une adresse
transfer	Déplace des jetons de l’appelant vers une autre adresse
approve	Permet à une autre adresse (un dépensier) de déplacer jusqu’à un montant défini de vos jetons
allowance	Renvoie combien un dépensier peut encore déplacer au nom d’un propriétaire
transferFrom	Déplace des jetons au nom d’un propriétaire, en utilisant une autorisation
name, symbol, decimals	Métadonnées descriptives, couramment présentes
événements Transfer, Approval	Émis lors des transferts et des approbations

La spécification indique que les transferts doivent déclencher l’événement Transfer et que les appels réussis à approve doivent déclencher Approval. Cette règle est ce qui rend la détection de paiement possible : vous pouvez surveiller les événements au lieu d’interroger chaque adresse. Nous approfondissons ce sujet dans notre guide sur l’événement ERC-20 Transfer, et notre aperçu de la norme ERC-20 parcourt l’interface complète.

Le motif approve et transferFrom

Le motif en deux étapes déconcerte les nouveaux venus. Avec transfer, le détenteur du jeton envoie les jetons directement. Avec approve plus transferFrom, le détenteur autorise d’abord un dépensier, et le dépensier retire ensuite les jetons. C’est ainsi qu’un échange décentralisé ou un contrat d’abonnement encaisse un paiement sans détenir vos clés. Si vous avez seulement besoin d’envoyer des jetons depuis un portefeuille que vous contrôlez, transfer suffit. Notre tutoriel sur comment envoyer des jetons ERC-20 compare les méthodes portefeuille, code et API.

ERC-20 decimals : gérer les montants correctement

Les contrats intelligents ne stockent pas de fractions. Chaque solde est un entier, et decimals vous indique combien des chiffres les plus à droite représentent la partie fractionnaire. La spécification ERC-20 rend la méthode optionnelle et donne un exemple : avec 8 décimales, vous divisez le montant du jeton par 100000000 pour obtenir sa représentation utilisateur.

Cela a trois conséquences pratiques.

Lisez toujours decimals depuis le contrat. Ne codez pas en dur une valeur pour tous les jetons. Deux jetons qui s’affichent tous deux comme « 1,00 » peuvent être stockés sous forme d’entiers très différents.

Faites les calculs avec des entiers ou des types grand-nombre. Les montants bruts peuvent dépasser ce qu’un nombre à virgule flottante standard peut contenir exactement. Utilisez BigInt, BigNumber, ou le type décimal de votre langage, et ne formatez pour l’affichage qu’à la dernière étape.

Traitez l’absence de la méthode decimals comme un cas à gérer. Comme cette méthode est optionnelle, un token conforme pourrait ne pas l’exposer. Prévoyez une solution de repli, comme rejeter le token ou exiger une configuration manuelle, plutôt que de supposer silencieusement une valeur par défaut.

Un exemple concret : un token avec 6 décimales affiche un solde brut de 2500000. En divisant par 10^6, on obtient 2,5 tokens. Pour envoyer 0,75 token, vous soumettez 750000, et non 0,75. Soumettre la valeur d’affichage par erreur enverrait une quantité infime, et la transaction réussirait tout de même.

ERC-721 : tokens non fongibles

Là où l’ERC-20 traite chaque unité de la même manière, l’ERC-721 est une interface pour les tokens non fongibles, tels que des œuvres d’art ou des chansons uniques. Chaque token possède un identifiant distinct au sein de son contrat, de sorte que la propriété est suivie par token plutôt que par solde. Les cas d’usage typiques sont les objets de collection, les billets, les objets de jeu et les preuves de propriété.

Le compromis réside dans le coût et la complexité. Déplacer dix NFT sans lien entre eux implique dix transferts distincts. Pour les détails de l’interface, consultez notre guide du standard ERC-721.

ERC-1155 : plusieurs types de tokens dans un seul contrat

L’ERC-1155 est une interface multi-tokens. Un seul contrat déployé peut représenter un nombre quelconque de types de tokens fongibles, non fongibles ou semi-fongibles, chacun identifié par un ID de token pouvant avoir ses propres métadonnées et son offre. La spécification prend également en charge le transfert de plusieurs types de tokens en une seule opération.

Cela en fait un choix naturel pour les jeux, où un seul contrat peut contenir une monnaie, un ensemble de consommables et quelques objets uniques. Vous déployez une fois, et vous pouvez regrouper les mouvements au lieu d’envoyer une transaction par type d’actif.

Comparaison des trois standards Ethereum

	ERC-20	ERC-721	ERC-1155
Type de token	Fongible	Non fongible	Fongible, non fongible ou semi-fongible
Suit	Un solde par adresse	Un propriétaire par ID de token	Des soldes par adresse par ID de token
Contrats nécessaires	Un par token	Une par collection	Un pour plusieurs types de tokens
Transferts par lots	Pas dans le standard	Pas dans le standard	Intégré
Usage typique	Stablecoins, tokens de paiement et de gouvernance	Objets de collection, billets, actifs uniques	Jeux, catalogues d’actifs mixtes

Standards de tokens sur d’autres chaînes

Les noms changent d’une chaîne à l’autre, mais l’idée reste la même.

Tron : TRC-20 et TRC-10. Le TRC-20 est le standard de token fongible sur TRON et est compatible avec l’ERC-20 au niveau de l’interface, donc la plupart des contrats de tokens Ethereum nécessitent peu de modifications pour y fonctionner. Tron possède également l’ancien standard au niveau protocole TRC-10. Nous expliquons les différences pratiques dans TRC-10 vs TRC-20.

BNB Chain : BEP-20. Le BEP-20 suit le modèle ERC-20 sur une chaîne compatible EVM, donc les noms de fonctions et les formes d’événements vous seront familiers.

Solana : jetons SPL. Solana ne déploie pas un nouveau contrat par jeton. Les jetons sont créés via le programme SPL Token partagé, et un NFT y est simplement un jeton créé avec zéro décimale. Le modèle mental diffère d’Ethereum, même si l’objectif d’interopérabilité est le même.

Écosystème Cosmos : CW20. La spécification CW20 gère les soldes et les transferts en utilisant des entiers Uint128 et laisse la gestion des décimales à l’interface utilisateur, ce qui correspond à la même séparation entier/affichage que l’ERC-20.

Un standard portant le même nom sur une chaîne différente n’est jamais interchangeable avec l’original. Un USDT TRC-20 et un USDT ERC-20 sont des actifs différents sur des réseaux différents, et l’envoi vers le mauvais réseau peut entraîner une perte de fonds. Associez toujours une adresse à son réseau dans votre modèle de données.

Ce qu’il faut vérifier avant d’intégrer un jeton

Un standard décrit ce qu’un jeton doit faire, pas ce que fait chaque contrat déployé. Une étude de 2022 dans IET Software a rapporté que l’ambiguïté dans l’interface ERC-20 peut conduire à des interprétations divergentes et des vulnérabilités de conformité parmi les contrats de jetons réels.

La liste de contrôle d’intégration de jeton sur ethereum.org est une bonne base. Elle demande aux développeurs de vérifier :

• la conformité et les valeurs de retour des fonctions standard,
• les fonctions optionnelles et les décimales,
• l’atténuation des conditions de concurrence sur les approbations,
• les appels externes à l’intérieur du jeton,
• les frais ou intérêts prélevés au transfert,
• la mise à niveau, le minting, la mise en pause et les pouvoirs de liste noire,
• les risques liés au propriétaire et à l’équipe, et la concentration de l’offre.

Pour un produit de paiement, ceux qui posent le plus souvent problème sont le comportement avec frais au transfert (le montant reçu est inférieur au montant envoyé), la liste noire (un transfert peut être bloqué après coup) et les valeurs de retour non standard. Testez chaque jeton que vous prévoyez de prendre en charge sur un testnet avec de vrais transferts, et créditez les dépôts en fonction du montant réellement reçu, pas du montant demandé.

Perspective : pourquoi les standards ne sont que la moitié du travail

Les standards résolvent le problème de la façon dont un jeton communique avec une chaîne. Ils ne résolvent pas le problème de l’exécution d’un produit sur plusieurs chaînes. Si vous acceptez des paiements sur Ethereum, Tron et Solana, vous devez toujours faire face à différents formats d’adresse, différents modèles de frais, différentes structures d’événements et différentes infrastructures de nœuds.

Nous avons construit Chaingateway autour de cet écart. Notre vision est que les développeurs n’aient pas besoin de maintenir des points de terminaison spécifiques à chaque chaîne ou d’exécuter leurs propres nœuds juste pour savoir qu’un client a payé. C’est pourquoi nous retournons des données pré-décodées, afin qu’un transfert arrive sous forme de champs lisibles au lieu de sujets de logs bruts, et pourquoi nous estimons le gaz automatiquement. Nous signons les requêtes webhook avec HMAC pour que votre backend puisse vérifier qu’une notification de paiement est authentique.

Notre conseil pour les équipes qui débutent : choisissez le standard qui correspond à votre actif (fongible, unique ou mixte), lisez les décimales depuis le contrat à chaque fois, et construisez votre détection de paiement sur les événements plutôt que sur le polling. Tout le reste est de la plomberie, et la plomberie est ce qu’une API doit absorber.

— Bitblade

Mettre les standards au travail avec Chaingateway

Si vous développez des paiements ou des portefeuilles basés sur ces standards, notre API Blockchain vous offre une interface REST unique pour créer des portefeuilles, envoyer des transferts de tokens et de NFT, récupérer des données de transactions décodées et estimer les frais sur Ethereum, Bitcoin, Tron, Solana, Polygon, BNB Chain et Arbitrum. Elle prend en charge les principaux standards de tokens, notamment ERC-20, BEP-20, TRC-20 et ERC-721. Les Webhooks Chaingateway envoient des notifications en temps réel lorsqu’un paiement arrive, vous évitant ainsi d’avoir à interroger le réseau.

Les plans commencent à 49 € par mois pour Plus, avec Pro à 99 €, Premium à 249 € et Enterprise à 499 € par mois. La facturation annuelle est respectivement de 490 €, 990 €, 2 490 € et 4 990 €. Consultez la page de tarification pour connaître le contenu de chaque plan. Pour Ethereum spécifiquement, notre API Ethereum montre comment envoyer des tokens ERC-20 via REST sans web3.js.

Sources

• Standards de tokens, ethereum.org
• Standards de développement Ethereum, ethereum.org
• Standard de token ERC-20, ethereum.org
• ERC-20 : Standard de token, EIP-20
• ERC-1155 : Standard multi-token, EIP-1155
• Checklist d’intégration de token, ethereum.org
• Réseaux blockchain : Aperçu de la conception et de la gestion des tokens, NIST
• Évaluation de conformité des 100 principaux contrats intelligents de tokens Ethereum, IET Software
• Standard de token fongible TRC-20, documentation développeur TRON
• Token, documentation Solana SPL
• Spécification CW20, CosmWasm

Recommandé

• Le standard de token ERC20
• Le standard de token ERC721