Aller au contenu
Financial Context Wiki

ERC-721

ERC-721 est l’interface standard d’Ethereum pour les jetons non fongibles (NFT) : chaque jeton est identifié séparément et un contrat intelligent enregistre ses règles de propriété et de transfert.

Mis à jour

À 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-721 est l’interface standard d’Ethereum pour les jetons non fongibles. Plutôt que d’enregistrer un solde interchangeable, un contrat ERC-721 suit chaque jeton avec tokenId, expose son propriétaire et définit les modalités de transfert ou d’autorisation. Le jeton est identifié par le couple adresse du contrat et tokenId ; la norme ne détermine pas à elle seule le prix, l’authenticité, la rareté ou les droits juridiques de l’actif.

ERC-721 diffère d’ERC-20 parce que les unités ERC-20 sont fongibles : une unité est censée être interchangeable avec une autre. Des jetons ERC-721 peuvent appartenir à la même collection tout en ayant des identifiants et des métadonnées différents. Un portefeuille ou une place de marché peut prendre en charge les deux normes, mais les appels de transfert et d’approbation diffèrent.

La question pratique n’est pas de savoir si un projet revendique « ERC-721 », mais ce que font réellement son contrat et les systèmes qui l’entourent. Avant de considérer un NFT comme un actif, vérifiez l’implémentation, les permissions, les métadonnées, l’autorisation de la place de marché, la liquidité et les droits promis aux détenteurs.

Fonctionnement

Identité et propriété

Le contrat enregistre un propriétaire pour chaque tokenId existant. ownerOf renvoie cette adresse et balanceOf compte les jetons détenus par une adresse. Le mint crée généralement un nouvel identifiant et émet un événement Transfer depuis l’adresse zéro ; le burn émet souvent un transfert vers l’adresse zéro. Les événements facilitent l’indexation, mais l’état du contrat fait foi.

Transferts et approbations

Le propriétaire peut appeler directement transferFrom ou autoriser une adresse pour un jeton avec approve. setApprovalForAll autorise un opérateur pour tous les jetons que le propriétaire détient dans cette collection. C’est pratique pour les places de marché, mais la permission est large. Vérifiez l’opérateur par son adresse de contrat et révoquez on-chain les approbations devenues inutiles. Une offre signée est distincte d’une approbation on-chain : annuler l’une ne supprime pas nécessairement l’autre.

safeTransferFrom vérifie aussi qu’un destinataire contractuel implémente IERC721Receiver. Cela aide à éviter l’envoi d’un jeton à un contrat incapable de le recevoir ; transferFrom n’exécute pas ce callback. Aucune des deux fonctions ne garantit qu’une place de marché, un pont ou un portefeuille traitera correctement le jeton.

Métadonnées et redevances

L’extension facultative de métadonnées expose tokenURI, qui peut pointer vers des données stockées on-chain ou ailleurs. Une URI de base modifiable, un contrat upgradeable, un administrateur ou un hébergeur centralisé peut changer l’affichage après le mint. Le stockage permanent ou décentralisé réduit certaines dépendances, mais ne prouve ni l’auteur, ni la provenance, ni la propriété intellectuelle.

ERC-721 n’oblige pas les marchés secondaires à payer des redevances au créateur. Une collection peut implémenter l’interface facultative EIP-2981, mais la place de marché choisit de la respecter et cette interface ne règle ni ne force le paiement. Les plafonds d’offre, le hasard, l’authenticité des œuvres, les licences de marque et les autres promesses doivent être vérifiés séparément dans le code, les règles de distribution et les documents juridiques.

Exemple

Supposons qu’un contrat mint le jeton #42 pour Alice. Le jeton n’est pas identifié mondialement par 42 seul : l’adresse du contrat de la collection fait aussi partie de son identité. Alice peut le proposer en accordant approve pour ce jeton ou setApprovalForAll à l’opérateur de la place de marché. Lors de la vente, la place de marché appelle une fonction de transfert et le contrat vérifie propriété et autorisation. Alice devrait ensuite révoquer l’approbation de toute la collection si elle n’en a plus besoin.

L’image affichée par la place de marché est une question de métadonnées distincte. Alice doit examiner le comportement de tokenURI, les permissions de mise à jour, l’hébergement et la licence, plutôt que de supposer que la possession du jeton transfère les droits d’auteur ou d’usage commercial.

Risques

  • Risque du contrat : un bug, une mise à niveau malveillante, un administrateur privilégié ou un hook de transfert incorrect peut bloquer ou déplacer des jetons.

  • Risque d’autorisation : un setApprovalForAll pour toute la collection ou une place de marché compromise peut déplacer tous les jetons approuvés de cette collection.

  • Risque lié aux métadonnées et au droit : les fichiers hors chaîne peuvent disparaître ou changer, et la propriété du jeton n’accorde pas automatiquement les droits d’auteur, de marque ou autres droits juridiques.

  • Risque de marché : les prix des NFT peuvent être volatils, la liquidité faible, et le prix plancher affiché peut être inexécutable pour un jeton donné.

Les opérations on-chain sont généralement irréversibles. Avant de signer, vérifiez le contrat de la collection, l’adresse destinataire, les approbations, les contrôles de métadonnées et les détails de la transaction ; considérez les affirmations des promoteurs ou communautés comme des déclarations à vérifier, pas comme des garanties.

Idées reçues

Mythe 1 : ERC-721 garantit la rareté

La norme distingue seulement les jetons d’un même contrat. L’émetteur peut en minter davantage, déployer des collections similaires ou faire pointer plusieurs identifiants vers des médias équivalents. La rareté dépend des règles d’offre et des permissions qui les font respecter.

Mythe 2 : Le NFT comprend tous les droits de propriété intellectuelle

La blockchain enregistre un transfert de jeton. Le droit d’auteur, la reproduction, l’usage commercial, l’adaptation et la marque dépendent de la licence de la collection et du droit applicable ; ils ne se déduisent pas de ownerOf.

Mythe 3 : Annuler une annonce supprime toutes les autorisations

L’annonce, sa signature et son expiration, ainsi qu’un approve ou setApprovalForAll on-chain, sont des états distincts. Vérifiez et révoquez séparément l’autorisation on-chain lorsqu’elle n’est plus nécessaire.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...