ERC-20, ERC-721, ERC-3643 : ce que le standard de ton token change vraiment

ERC-20 organise des unités interchangeables d’un même token. ERC-721 permet de distinguer des unités par un identifiant unique. ERC-3643 ajoute à une interface compatible ERC-20 une gestion des identités et des transferts contrôlés. Aucun de ces choix ne suffit à définir tes droits immobiliers.

Un standard est une interface commune

Un standard décrit un ensemble de fonctions et de comportements que des outils peuvent reconnaître. Il facilite le dialogue entre un contrat de token, un portefeuille et d’autres applications. C’est une question de compatibilité technique : quels appels sont disponibles, quelles informations ils renvoient et comment une opération est représentée.

Il ne faut pas confondre cette interface avec le contenu économique du produit. Deux émissions techniquement semblables peuvent représenter des droits très différents. À l’inverse, deux droits proches peuvent être enregistrés avec des architectures distinctes.

La première démarche consiste donc à lire le nom du standard sans s’arrêter à son prestige supposé. Demande ensuite quel contrat est réellement déployé, sur quel réseau, et quels documents relient ce contrat à l’émission. Un sigle dans une brochure n’est pas une vérification du code en service.

ERC-20 : compter des unités interchangeables

Le standard ERC-20 définit notamment des fonctions de consultation du solde, de transfert et d’autorisation donnée à un autre acteur pour utiliser des tokens. Les unités d’un même contrat sont traitées comme interchangeables.

Imagine une émission comportant 10 000 unités portant les mêmes droits. Détenir 40 unités revient à détenir une quantité, sans devoir désigner quarante numéros individuels. Cela rend la représentation d’une même catégorie de parts ou de créances techniquement commode.

Mais une unité ERC-20 n’est pas automatiquement une part sociale. Elle peut représenter autre chose, voire ne disposer d’aucun lien juridique suffisamment établi avec un actif. Les décimales constituent également un réglage de représentation ; elles ne prouvent pas qu’une fraction minuscule ouvre un droit juridiquement autonome.

Pour l’investisseur, la question utile devient : toutes les unités affichées comme identiques ont-elles effectivement les mêmes droits, la même priorité et les mêmes frais ? La réponse est documentaire, pas seulement informatique.

ERC-721 : distinguer chaque unité

Le standard ERC-721 distingue les tokens par des identifiants au sein d’un contrat. Cette architecture peut convenir quand les objets représentés ne doivent pas être confondus.

Un projet pourrait, par exemple, utiliser des identifiants différents pour référencer plusieurs lots ou plusieurs dossiers. Cela ne signifie pas que le détenteur du token devient propriétaire du lot correspondant. La relation avec le titre de propriété, un registre ou un engagement contractuel doit toujours être démontrée.

Le mot « unique » appelle aussi une question : unique de quelle manière ? Un identifiant est unique dans son contrat, mais cette unicité technique ne certifie pas qu’aucun autre jeton ne référence le même bâtiment ailleurs. Elle n’interdit pas non plus une modification des informations associées si l’architecture le permet.

Demande donc ce que l’identifiant désigne précisément et comment les changements sont tracés. Une photographie d’immeuble reliée à un token n’est pas une preuve suffisante de droits sur cet immeuble.

ERC-3643 : conditionner les transferts

La spécification ERC-3643 conserve une interface compatible ERC-20 et ajoute des contrôles fondés sur les identités et les règles de l’émission. Elle prévoit notamment des mécanismes de pause, gel, récupération et transfert forcé par des rôles autorisés.

Ce cadre aide à représenter des titres dont les transferts ne sont pas librement ouverts à toute adresse. Il ne délivre aucun agrément juridique. Les règles configurées, les personnes qui les administrent et leur adéquation au produit demeurent déterminantes.

Une restriction peut être cohérente avec les documents d’émission tout en limitant la liberté de mouvement du détenteur. Il faut alors pouvoir identifier l’autorité qui la décide et la procédure de contestation. « Mon token est dans mon portefeuille » ne signifie pas nécessairement « personne ne peut bloquer son transfert ».

Exemple fictif : trois architectures

Trois émissions fictives concernent un même ensemble immobilier.

La première représente 10 000 unités identiques avec un contrat ERC-20. La deuxième attribue un identifiant ERC-721 à chaque dossier de lot. La troisième utilise ERC-3643 pour représenter des unités transférables seulement à des détenteurs reconnus par son dispositif.

Aucune conclusion sur la rentabilité, la dette ou les droits de propriété ne découle de ces trois choix. Ils décrivent des modes d’enregistrement et de circulation. Pour comparer les placements, il faut encore lire les droits attachés à chaque émission.

Compatibilité ne veut pas dire circulation universelle

Un portefeuille peut afficher un solde sans permettre toutes les opérations attendues. Un marché peut reconnaître une interface technique sans accepter l’actif. Un acheteur peut posséder une adresse valide sans satisfaire les conditions de détention.

La chaîne de vérification comprend donc plusieurs questions distinctes : l’outil reconnaît-il le contrat ? Le transfert est-il autorisé ? Existe-t-il un lieu de négociation approprié ? Des acheteurs sont-ils présents ? À quel prix et avec quels frais ?

Ces étapes évitent un raccourci fréquent : déduire la liquidité de la compatibilité d’un standard. Une fonction de transfert peut fonctionner parfaitement sans qu’aucun acheteur ne propose le prix souhaité.

Regarder l’implémentation, pas seulement l’étiquette

La brochure annonce une famille technique. Le contrat déployé et ses dépendances révèlent les paramètres concrets. Les documents juridiques précisent les engagements. Une analyse sérieuse relie ces trois niveaux.

Pour les fonctions administratives, recherche notamment qui peut agir, si plusieurs validations sont nécessaires et comment les modifications sont communiquées. Un audit portant sur une version antérieure ne suffit pas à caractériser une version modifiée. L’examen doit correspondre à l’adresse et à la version utilisées.

Lire un standard sans surinterpréter le sigle

1. Vérifie le réseau et l’adresse exacte du contrat.
2. Identifie ce que chaque unité ou identifiant représente juridiquement.
3. Distingue les fonctions du standard des ajouts propres à l’émission.
4. Repère les personnes autorisées à modifier les règles ou à intervenir.
5. Vérifie les restrictions de transfert et les outils effectivement compatibles.
6. Évalue la possibilité de revente séparément de la technologie.

Le standard explique une partie du fonctionnement ; les droits et les risques exigent d’autres preuves.

Ce contenu fournit une explication générale des standards techniques. Il ne constitue pas une validation de contrat, un audit de sécurité ou un conseil d’investissement ou juridique personnalisé. Tout investissement comporte un risque de perte en capital.