--- title: "ERC-1155" description: "ERC-1155 est le standard multi-jetons d’Ethereum : un contrat peut suivre de nombreux types de jetons fongibles, non fongibles ou mixtes par ID et transférer plusieurs ID en un seul lot." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # ERC-1155 > À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes. ## Réponse directe ERC-1155 est le standard multi-jetons d’Ethereum. Un même contrat peut gérer de nombreux types de jetons, et chaque `token ID` peut représenter un solde fongible, un objet non fongible ou une autre structure d’offre choisie par l’implémentation. La clé de l’actif est donc `contract address + token ID`, et non le seul ID du jeton. Le standard définit des consultations de solde unitaires et par lots, des transferts sécurisés unitaires et par lots, une approbation globale des opérateurs, des fonctions de rappel du destinataire, des événements de transfert et un comportement facultatif pour l’URI des métadonnées. Il ne définit pas qui peut émettre des jetons, si l’offre est plafonnée, si les métadonnées sont permanentes, quels droits juridiques un jeton confère ni sa valeur. Ces propriétés doivent être vérifiées dans le contrat précis, ses rôles et ses dépendances externes. ## Fonctionnement 1. **Identifier le solde.** `balanceOf(account, id)` renvoie la quantité d’un ID détenue par un compte. `balanceOfBatch(accounts, ids)` interroge des paires compte-ID. Deux contrats peuvent tous deux utiliser l’ID `1` pour des actifs sans rapport entre eux ; l’identité complète reste donc la blockchain, l’adresse du contrat et l’ID. 2. **Autoriser l’appelant.** Un détenteur peut transférer son propre solde ou appeler `setApprovalForAll(operator, true)`. Cette approbation couvre tous les ID ERC-1155 que le détenteur possède dans ce contrat ; `isApprovedForAll(owner, operator)` en indique l’état. ERC-1155 ne prévoit pas d’approbation native limitée à un seul ID ou à une seule quantité. 3. **Effectuer un transfert unitaire ou par lots.** `safeTransferFrom` déplace un ID et une quantité. `safeBatchTransferFrom` déplace les tableaux parallèles `ids` et `values`, dont les longueurs et l’ordre doivent correspondre. Le regroupement peut réduire les coûts de transaction répétés, sans être nécessairement moins cher pour chaque implémentation ou charge de travail. 4. **Vérifier un contrat destinataire.** Après avoir mis à jour les soldes et émis l’événement approprié, un transfert conforme vers un contrat appelle `onERC1155Received` ou `onERC1155BatchReceived`. Une fonction de rappel non prise en charge, une valeur de retour incorrecte ou un refus annule normalement le transfert. Cette vérification réduit les blocages accidentels ; elle ne prouve pas que le contrat destinataire est fiable ni qu’il offre un moyen de retrait. 5. **Reconstruire l’état à partir des événements.** Toute émission, tout transfert et toute destruction doivent être consignés par `TransferSingle` ou `TransferBatch`. L’émission utilise l’adresse zéro comme `from` ; la destruction l’utilise comme `to`. Les indexeurs peuvent déduire de ces journaux les soldes et l’offre nette émise par ID, mais doivent traiter correctement l’historique complet, les réorganisations de la blockchain et les migrations de contrats. 6. **Résoudre les métadonnées.** L’extension URI facultative peut renvoyer un modèle partagé contenant `{id}`. Un client le remplace par l’ID de jeton hexadécimal en minuscules, complété par des zéros jusqu’à 64 caractères et sans préfixe `0x`. Les métadonnées peuvent malgré tout être modifiables, indisponibles ou trompeuses, sauf indication contraire de l’implémentation et des garanties de stockage. ## Exemple détaillé Un contrat de jeu attribue l’ID `1` aux pièces d’or, l’ID `7` aux laissez-passer et l’ID `42` à une épée unique. Alice détient `balanceOf(Alice, 1) = 500`, `balanceOf(Alice, 7) = 3` et `balanceOf(Alice, 42) = 1`. - Alice appelle `safeBatchTransferFrom` avec `ids = [1, 7, 42]` et `values = [120, 1, 1]`. Si la validation réussit, ses nouveaux soldes sont `500 - 120 = 380`, `3 - 1 = 2` et `1 - 1 = 0` ; le destinataire reçoit les quantités correspondantes. - Le contrat émet `TransferBatch`. Si le destinataire est un contrat, il doit accepter le lot au moyen de `onERC1155BatchReceived` ; sinon, toute la transaction est annulée et aucune des trois modifications de solde ne subsiste. - L’ID `42` se comporte comme un jeton non fongible uniquement parce que sa logique d’émission et de transfert maintient l’offre à `1`. ERC-1155 n’impose pas cette règle. Le même contrat peut émettre ultérieurement davantage d’unités de l’ID `1`, sous réserve de son propre contrôle d’accès. ## Risques et contrôles - **Pouvoir étendu de l’opérateur.** Un opérateur malveillant ou compromis approuvé par `setApprovalForAll` peut déplacer tous les ID détenus dans ce contrat. Vérifiez l’adresse et le contrat de l’opérateur, utilisez si nécessaire un portefeuille distinct et révoquez les approbations obsolètes. - **Pouvoirs d’émission, de suspension et de mise à niveau.** Ce sont des caractéristiques de l’implémentation, pas des garanties du standard. Examinez les détenteurs de rôles, les administrateurs de proxy, les délais de sécurité, les extensions d’offre et la capacité d’une mise à niveau à modifier les soldes ou les règles de transfert. - **Décalage entre métadonnées et actif.** Un URI ou un fichier JSON hébergé peut changer alors que l’ID sur la blockchain reste identique. Vérifiez les empreintes du contenu, la pérennité du stockage, les engagements de l’émetteur et les droits représentés hors du contrat de jeton. - **Erreurs d’intégration.** Les portefeuilles et les indexeurs peuvent mal associer les tableaux d’un lot, manquer des événements historiques, mal gérer les réorganisations ou confondre le même ID entre plusieurs contrats et blockchains. Rapprochez les appels du contrat, les journaux et les soldes finaux. - **Risque lié au destinataire et à la réentrance.** Les fonctions de rappel du destinataire exécutent du code externe pendant le transfert. Les implémentations et les protocoles intégrateurs doivent ordonner correctement les changements d’état et se protéger contre la réentrance ; la prise en charge des fonctions de rappel ne constitue pas à elle seule un audit de sécurité. - **Risque de coût et de liquidité.** Les transferts par lots consomment toujours du gas et sont annulés atomiquement si une condition requise échoue. La liquidité du marché, la tarification, les redevances, les ponts, le rachat et l’application hors chaîne ne relèvent pas d’ERC-1155. ## Idées reçues - **« Chaque ID est un NFT. »** Un ID peut exister en n’importe quelle quantité ; la non-fongibilité dépend de l’offre et de la sémantique de l’implémentation. - **« Un contrat correspond à une collection. »** Un contrat peut contenir de nombreux types de jetons sans rapport entre eux, et le même ID numérique dans un autre contrat désigne un actif différent. - **« Un transfert sécurisé signifie que l’actif est sûr. »** La fonction de rappel vérifie la compatibilité du destinataire, pas la qualité du contrat, le prix, les métadonnées ou la possibilité de récupération. - **« Le regroupement économise toujours du gas. »** Il évite souvent des coûts répétés, mais le résultat réel dépend de l’implémentation, du nombre d’ID, des modifications du stockage, des données d’appel et du modèle de frais du réseau. ## Sujets connexes - [ERC-20](/fr/crypto/erc20/) - [ERC-721](/fr/crypto/erc721/) - [NFT](/fr/crypto/nft/) - [Standard de jeton](/fr/crypto/token-standard/) ## Sources - [ERC-1155 : standard multi-jetons](https://eips.ethereum.org/EIPS/eip-1155) - [API ERC1155](https://docs.openzeppelin.com/contracts/5.x/api/token/erc1155) Source: https://wiki.fcontext.com/fr/crypto/erc1155/index.mdx