⚠️ Avertissement : Cet article a une vocation exclusivement informative et pédagogique. Il ne constitue en aucun cas un conseil financier, juridique ou d’investissement. Les technologies et réglementations évoquées sont en évolution constante. Consultez un professionnel qualifié avant toute décision impliquant vos données personnelles ou vos actifs numériques.
Imaginez un portefeuille Ethereum contenant votre diplôme universitaire, votre historique de remboursement de prêts crypto, votre réputation de contributeur dans une organisation décentralisée — et non des tokens à vendre. Aucune de ces informations ne pourrait changer de mains, ni disparaître. C’est précisément le modèle que le co-fondateur d’Ethereum, Vitalik Buterin, a théorisé en 2022 avec E. Glen Weyl et Puja Ohlhaver dans un document de recherche intitulé « Decentralized Society: Finding Web3’s Soul ». Ce texte reste toutefois un document de travail. Pas un standard technique. Il a néanmoins immédiatement alimenté des débats très concrets dans la communauté blockchain.
Ces tokens portent un nom : les Soulbound Tokens, ou SBT. Ils soulèvent une question centrale : peut-on construire une réputation numérique décentralisée sans créer une prison de données ? Cet article explore leur fonctionnement technique, leurs usages concrets, et les risques éthiques qu’ils soulèvent. Car une technologie ambitieuse, mal conçue, peut ressembler à un casier judiciaire permanent inscrit dans la blockchain.
De World of Warcraft à Ethereum : d’où vient l’idée « soulbound »
Le terme vient littéralement des jeux de rôle en ligne massivement multijoueurs. Dans World of Warcraft, certains objets portent l’étiquette « soulbound ». Une fois équipés par un personnage, personne ne peut plus les échanger. L’idée est simple — ces objets symbolisent un accomplissement personnel, pas une marchandise. Buterin et ses co-auteurs ont repris ce concept en 2022. Ils l’ont appliqué à des attestations numériques non transférables. Ces attestations se rattachent à une « Soul » — autrement dit, une adresse Ethereum représentant une entité ou une personne.
Concrètement, un SBT constitue une attestation enregistrée sur une blockchain. Une entité tierce — université, protocole, employeur — émet ce token et l’attache de façon permanente à une adresse. Ce document de mai 2022 pose l’hypothèse que ces tokens pourraient représenter des qualifications, des informations d’identité ou des engagements passés. Ce texte reste cependant un document de travail. Ethereum n’a pas encore formalisé cela en standard technique.
Techniquement, qu’est-ce qui rend un NFT « non transférable » ?
Un NFT classique transfère librement grâce à des fonctions du standard ERC-721, notamment transferFrom(). Pour rendre un token « soulbound », l’approche la plus directe bloque cette fonction — ainsi que safeTransferFrom — de sorte que tout appel à ces méthodes échoue automatiquement.
Plus précisément : dans un ERC-721 standard, tout mécanisme de transfert doit déclencher un rejet (« revert ») si le token est « verrouillé ». C’est la base de l’ERC-5192. Plusieurs approches vont plus loin. Certaines maintiennent un registre de révocation : le token reste sur l’adresse, mais le registre signale s’il est encore valide. D’autres encodent une date d’expiration dans les données du token, ce qui le rend invalide passé ce délai. Reste alors une question clé : où stocker les données ? Les garder sur la blockchain les rend permanentes et accessibles à tous. Les héberger ailleurs (via IPFS par exemple) apporte plus de souplesse, mais réduit la fiabilité. Le vrai piège : ce choix de stockage.
Pour être précis : l’ERC-5192 définit une interface minimale pour signaler qu’un NFT est « verrouillé ». Il ne couvre pas tous les besoins liés à l’identité numérique — révocation, expiration, confidentialité, schémas de métadonnées. Plusieurs propositions comblent partiellement ce vide : l’ERC-4973 (statut : en révision) et l’ERC-5114 (statut : dernière phase de consultation, délai fixé au 2023-09-19). Leur adoption effective reste donc incertaine.
Ce que les SBT rendent possible : diplôme, réputation, crédit DeFi sans collatéral
L’un des problèmes structurels de la finance décentralisée actuelle est ce qu’on appelle la sur-collatéralisation. Pour emprunter 1 000 € en stablecoins sur un protocole comme Aave ou Compound, vous devez déposer 1 500 € (voire davantage) en garantie. C’est l’équivalent de devoir déposer une caution plus élevée que le montant du prêt lui-même. Ce modèle fonctionne parce qu’on ne sait rien de l’emprunteur — l’adresse Ethereum est pseudonyme, sans historique vérifiable.
Les SBT pourraient, en théorie, changer ce modèle. Imaginons un protocole de prêt qui attribue un SBT « remboursement ponctuel » à chaque emprunteur ayant soldé sa dette dans les délais. Cet historique formerait alors un score de crédit décentralisé. Il ouvrirait l’accès à des prêts avec moins de garanties, voire sans garantie du tout. C’est plausible, et plusieurs projets explorent cette direction. Toutefois, le domaine reste largement expérimental. La résistance aux faux profils — problème central de tout système de réputation — demeure un défi ouvert.
Le cas concret : Karim emprunte sans garantie
Prenons un cas concret. Karim, développeur indépendant, contribue depuis trois ans à trois protocoles différents. Six prêts remboursés sans défaut. Un protocole hypothétique lui attribue des SBT attestant chacun de ces faits. Il souhaite emprunter 5 000 USDC pour financer un audit freelance. Son historique lui permettrait d’obtenir ce prêt avec une garantie réduite — sans révéler son identité réelle.
Sur le papier, ça tient. Mais voilà la vraie question : qui vérifie l’authenticité de ces SBT ? Et surtout, qui garantit que Karim n’a pas ouvert plusieurs adresses pour se fabriquer une réputation fictive ? C’est le problème de l’invariant de cohérence. Un score de crédit décentralisé ne vaut rien si le lien entre le token et la personne réelle reste fragile. On n’y est pas encore.
DAO : passer de « 1 token = 1 voix » à « 1 personne = 1 voix » (et le risque Sybil)
La gouvernance par token subit souvent une critique simple : celui qui détient le plus de tokens impose le plus de voix. C’est donc un système où le pouvoir suit l’argent — une démocratie où le vote s’achète. Les SBT offrent une alternative : attribuer à chaque membre vérifié d’une communauté un token de gouvernance non transférable. Résultat : personne ne peut voter plusieurs fois avec des identités différentes.
Cependant, le risque Sybil — c’est-à-dire la création de multiples fausses identités pour manipuler un vote — ne disparaît pas magiquement. Il se déplace. Au lieu d’acheter des tokens, un acteur malveillant devrait désormais fabriquer de faux profils suffisamment crédibles pour obtenir des SBT légitimes. Autrement dit, le modèle de menace change, mais il ne s’annule pas. La solidité anti-Sybil d’un système SBT dépend entièrement de la qualité du processus d’émission — et donc de la confiance qu’on accorde aux émetteurs. Un token non transférable ne garantit pas automatiquement la résistance à la manipulation.
Le piège : le « redlisting » permanent et la réputation impossible à laver
C’est ici que les SBT deviennent vraiment préoccupants. Considérons ce scénario : un protocole attribue automatiquement un SBT « défaut de remboursement » à chaque adresse n’ayant pas soldé sa dette avant liquidation. Ce token s’inscrit de façon permanente sur la blockchain, visible par tous. L’adresse concernée rejoint de facto une liste noire décentralisée — sans recours possible, sans appel, sans tribunal.
Quand la transparence devient une sanction permanente
C’est de la transparence, en théorie. En pratique, ce mécanisme punit sans distinguer trois situations très différentes : le défaut volontaire (stratégie délibérée), le défaut forcé (vol du portefeuille), et l’erreur technique (bug dans le protocole). De plus, ce « redlisting » vise une adresse, pas forcément une personne. Sauf que les points de corrélation entre identité réelle et adresse blockchain se multiplient : exchanges imposant une vérification d’identité, passerelles vers la monnaie traditionnelle, preuves d’identité liées à un portefeuille, informations publiées sur des forums. Dès que l’un de ces liens s’établit, les conséquences d’un SBT négatif dépassent largement le cadre de la finance décentralisée.
Peut-on se réhabiliter ? La question mérite d’être posée. Dans les systèmes de crédit traditionnels, un défaut de paiement disparaît du registre après quelques années. Avec des données permanentes sur une blockchain, en revanche, aucune procédure d’effacement automatique n’existe. Certaines propositions envisagent que le protocole émetteur « brûle » un SBT négatif après remboursement tardif — mais cela suppose que l’émetteur reste actif, coopératif, et que ses règles de gouvernance le prévoient.
Révocation, expiration, burn : pourquoi « effacer » n’est pas si simple
Pour atténuer ce caractère permanent, trois mécanismes existent. La révocation permet à l’émetteur de marquer un token comme invalide dans un registre dédié, sans le détruire. L’expiration, quant à elle, rend le SBT inactif après une date définie, encodée dans le token lors de son émission. Le burn, enfin, envoie le token vers une adresse inaccessible pour le rendre définitivement irrécupérable.
Chacune de ces approches implique des compromis. La révocation concentre le pouvoir chez l’émetteur — qui peut révoquer arbitrairement, ou simplement disparaître. L’expiration exige qu’on anticipe la durée de validité d’une attestation dès l’émission. Le burn, pour sa part, reste irréversible même en cas d’erreur. Par ailleurs, la plupart des implémentations actuelles n’intègrent pas de mécanisme de révocation standardisé. Corriger une erreur — émission frauduleuse, changement de situation — devient alors particulièrement difficile.
Peut-on se racheter ? Si le protocole prévoit un mécanisme explicite — burn conditionnel, gouvernance de révocation, attestation de remboursement tardif — la réponse est oui. Mais cela exige une gouvernance active, un émetteur joignable cinq ans après l’émission, et des règles clairement inscrites dans le code. Dans un écosystème où des protocoles disparaissent du jour au lendemain, c’est une hypothèse optimiste.
Vie privée : DID, corrélation d’adresses, et identité sous contrainte
⚠️ Point YMYL : dès qu’un SBT permet de relier une adresse à une personne — directement ou par corrélation — il peut devenir une donnée personnelle au sens du RGPD. Ce risque n’est pas théorique : il dépend du contexte (KYC, passerelles fiat, liens publics entre adresses, etc.).
Les identifiants décentralisés, ou DID (de l’anglais Decentralized Identifiers), constituent un standard du W3C (recommandation du 19 juillet 2022). Ils permettent à une entité — une personne ou une organisation — de créer et contrôler ses propres identifiants numériques sans dépendre d’un registre centralisé. Concrètement, un DID forme une adresse unique que son propriétaire rattache à une clé cryptographique et contrôle lui-même. Les SBT peuvent cibler une adresse contrôlant un DID, ce qui ajoute une couche d’identité vérifiable sans révéler l’identité réelle.
Mais voilà le problème structurel : accumuler des SBT sur une même adresse, c’est construire un profil de plus en plus riche, visible par n’importe quel nœud du réseau. Chaque token émis ajoute une donnée. Chaque interaction laisse une trace. Un observateur extérieur — un État, un employeur, un concurrent — peut croiser ces informations et reconstituer un profil détaillé. Il n’a pas besoin de connaître le nom réel derrière l’adresse. C’est la surface d’attaque principale du modèle SBT.
Si je devais auditer un système de SBT, mon premier réflexe ne serait pas d’examiner la création des tokens. J’irais regarder l’indexation, les lecteurs autorisés, et la procédure de contestation. C’est là que se construit — ou se casse — la réalité sociale du système.
La fausse sécurité du pseudo-anonymat
L’hypothèse selon laquelle « mon adresse est anonyme » s’effrite de plus en plus. Des outils d’analyse de blockchain — comme Chainalysis, Elliptic, ou des dizaines d’alternatives en libre accès — relient des adresses à des identités réelles avec un taux de succès croissant. Ils exploitent les points d’entrée et de sortie vers le système financier traditionnel. Si des SBT contenant des données sensibles — état de santé, convictions politiques, antécédents de crédit — atteignent une adresse traçable, le pseudo-anonymat ne protège plus personne.
Des pistes existent néanmoins pour limiter cette exposition. La divulgation sélective permet de prouver qu’on possède une attestation sans en révéler le contenu — par exemple, démontrer qu’on a plus de 18 ans sans divulguer sa date de naissance exacte. Les preuves à divulgation nulle de connaissance (zero-knowledge proofs) rendent cette approche réalisable. Des protocoles comme Sismo ou Polygon ID explorent d’ailleurs déjà ces modèles. Par ailleurs, conserver certaines attestations hors de la blockchain — signées numériquement, présentées à la demande — permet de rester vérifiable sans s’exposer en permanence. Ces approches respectent mieux la vie privée, mais elles complexifient l’architecture et réduisent la compatibilité entre protocoles.
Conclusion : technologie à double tranchant, responsabilité collective
Les Soulbound Tokens représentent une idée séduisante : donner à la blockchain la capacité de représenter des identités, des qualifications, des réputations — et plus seulement de la valeur financière. C’est une avancée réelle vers une finance décentralisée plus inclusive. Je ne le nie pas. Cependant, les choix de conception actuels comportent des risques que la plupart des promoteurs minimisent. Réputation permanente sans mécanisme de réhabilitation, corrélation d’adresses facilitant la désanonymisation, concentration de pouvoir chez les émetteurs. En audit, la première question n’est jamais « comment crée-t-on le token » — c’est « qui émet, qui révoque, et que se passe-t-il quand ces deux entités disparaissent ».
Avant de déployer des systèmes SBT à grande échelle, des réponses concrètes s’imposent. Comment protéger le droit à l’oubli dans un système par essence permanent ? Qui supervise les émetteurs de tokens d’identité ? Comment corriger une erreur d’attribution ? Ces questions ne relèvent pas seulement de la technique — elles touchent aussi au droit, à l’éthique, et à la gouvernance collective du Web3.
La blockchain peut-elle devenir un outil d’émancipation personnelle, ou risque-t-elle de construire la plus transparente — et la plus implacable — des bureaucraties numériques ?
— Dans la DeFi, le code est roi. Mais même un roi a besoin d’une bonne armure.
Ce qu’on ne sait pas encore / ce qui reste débattu
Standard technique : Il existe un standard minimal (ERC-5192) pour les NFT non transférables, mais pas de standard complet couvrant l’ensemble du périmètre SBT — attestations d’identité, révocation, expiration, schémas de métadonnées. Les propositions ERC-4973 (statut : en révision) et ERC-5114 (statut : dernière phase de consultation) sont encore à des stades de discussion. Par conséquent, leur adoption reste incertaine.
Compatibilité RGPD : La question de la compatibilité des SBT permanents avec le droit européen à l’effacement (article 17 du RGPD) n’a pas encore été tranchée. En effet, les avis juridiques divergent selon que le contrôleur de données est identifiable ou non.
Résistance Sybil à grande échelle : Aucun mécanisme anti-Sybil robuste et décentralisé n’a encore été validé en production à grande échelle. Les approches actuelles impliquent soit un tiers de confiance, soit des mécanismes sociaux (cercles de confiance) dont la fiabilité reste, pour l’instant, hypothétique.
Interopérabilité : La question de savoir si des SBT émis par un protocole sont reconnus par un autre reste largement ouverte. Elle dépend en outre de standards de métadonnées qui n’existent pas encore.
🔍 Modèle de menace : avant de « tokeniser » une réputation, demandez-vous : qui peut émettre ? Qui peut lire ? Qui peut corréler ? Qui peut contester ? Et que se passe-t-il si l’émetteur disparaît ? Un système SBT mal conçu transforme chacune de ces questions sans réponse en une vulnérabilité réelle.
Risques et contre-mesures
| Risque | Description | Contre-mesure envisagée |
|---|---|---|
| Réputation permanente | Un SBT négatif reste visible indéfiniment, sans mécanisme de réhabilitation automatique. | Expiration timestamp, mécanisme de burn conditionnel, gouvernance de révocation. |
| Corrélation d’adresses | L’accumulation de SBT sur une adresse facilite la désanonymisation via analyse on-chain. | Divulgation sélective, zero-knowledge proofs, stockage off-chain des attestations sensibles. |
| Émetteur défaillant | Si l’émetteur du SBT disparaît, la révocation devient impossible et les erreurs sont irréparables. | Revocation registry décentralisé, mécanismes de gouvernance multi-signataires. |
| Identité volée | Si un wallet est compromis, tous les SBT liés à cette adresse sont potentiellement exposés. | Mécanismes de récupération sociale (social recovery), dissociation SBT / wallet principal. |
| Exclusion algorithmique | Les protocoles peuvent automatiquement exclure des adresses sur la base de SBT sans recours possible. | Obligation de procédure de contestation, supervision réglementaire des émetteurs. |
💡 L’essentiel à retenir
- ✅ Un SBT est un token non transférable lié à une adresse Ethereum, représentant une attestation (diplôme, réputation, appartenance).
- ⚠️ ERC-5192 définit une interface minimale pour les NFT « locked », mais il n’existe pas de standard couvrant l’ensemble du périmètre SBT (identité, révocation, confidentialité, schémas de métadonnées) — ce domaine est encore expérimental.
- 🔴 Un SBT « négatif » (défaut de paiement, exclusion) peut devenir une sanction permanente sans mécanisme de réhabilitation standardisé.
- 🔒 Le pseudo-anonymat ne protège pas contre la corrélation d’adresses — des outils d’analyse on-chain permettent de relier adresses et identités réelles.
- 💡 Des alternatives comme la divulgation sélective et les zero-knowledge proofs offrent des modèles plus respectueux de la vie privée, mais restent complexes à implémenter.
FAQ — Soulbound Tokens (SBT)
Quelle est la différence entre un NFT et un Soulbound Token ?
Un NFT standard peut être transféré ou vendu librement — sa valeur est précisément liée à sa liquidité. Un SBT, en revanche, est conçu pour être non transférable : il reste lié à l’adresse qui l’a reçu, représentant une attestation personnelle (qualification, réputation, appartenance) plutôt qu’un actif financier.
Existe-t-il un standard Ethereum officiel pour les SBT ?
Il existe un standard minimal (ERC-5192) pour les NFT « locked » (non transférables). Mais il n’existe pas de standard unique couvrant tout le périmètre SBT — identité, révocation, expiration, confidentialité. Les propositions ERC-4973 (statut : Review) et ERC-5114 (statut : Last Call) sont encore en cours de discussion dans la communauté Ethereum. Leur adoption effective reste incertaine et évolutive.
Un SBT peut-il être supprimé ou révoqué ?
Techniquement oui, si l’implémentation le prévoit : via un mécanisme de burn (destruction), un revocation registry, ou un expiration timestamp. En pratique, ces mécanismes doivent être explicitement codés lors de l’émission du token, et dépendent de la coopération de l’émetteur — qui peut avoir disparu. Il n’existe pas de mécanisme universel de révocation.
Les SBT sont-ils compatibles avec le RGPD ?
C’est une question juridique ouverte et très débattue. Le RGPD prévoit un « droit à l’effacement » (article 17) pour les données personnelles. Or, les données stockées on-chain sont par nature permanentes et publiques. Des solutions comme le stockage off-chain ou la divulgation sélective via zero-knowledge proofs sont explorées pour concilier ces deux contraintes, mais aucune réponse réglementaire définitive n’a été apportée à ce jour.
Comment les SBT pourraient-ils améliorer le crédit en DeFi ?
En théorie, les SBT permettraient de construire un historique de réputation on-chain vérifiable : remboursements passés, participation à des protocoles, certifications techniques. Des protocoles de prêt pourraient utiliser ces données pour proposer des prêts sous-collatéralisés, réduisant la barrière à l’entrée actuelle de la DeFi. C’est un modèle plausible mais encore largement expérimental, sans déploiement à grande échelle validé.
Qu’est-ce que la divulgation sélective et en quoi protège-t-elle la vie privée ?
La divulgation sélective permet de prouver cryptographiquement qu’on possède une attestation (ex. « j’ai plus de 18 ans ») sans révéler les données sous-jacentes (ex. date de naissance exacte). Grâce aux zero-knowledge proofs, il est possible de vérifier une information sans l’exposer. C’est l’une des pistes les plus prometteuses pour concilier vérifiabilité des SBT et protection de la vie privée.
Tableau comparatif : designs SBT
| Design SBT | Avantage principal | Risque principal |
|---|---|---|
| On-chain permanent (données dans la blockchain) |
Résistance à la censure, transparence maximale, composabilité avec d’autres protocoles. | Exposition publique permanente des données, incompatibilité potentielle avec le RGPD, surface d’attaque pour la désanonymisation. |
| On-chain avec expiration / révocation (revocation registry, expiration timestamp) |
Flexibilité partielle, possibilité de corriger des erreurs ou de mettre à jour le statut. | Dépendance à la coopération de l’émetteur, risque de révocation arbitraire, complexité d’implémentation accrue. |
| Off-chain avec ancrage cryptographique (attestation signée, ZK-proof) |
Protection de la vie privée, divulgation sélective possible, compatible avec le RGPD si données hors chaîne. | Dépendance à l’infrastructure de stockage off-chain, composabilité réduite, complexité technique élevée. |
Sources et références
- Buterin V., Weyl E.G., Ohlhaver P. (2022). Decentralized Society: Finding Web3’s Soul. Working paper, SSRN.
- Ethereum Improvement Proposals. ERC-5192 : Minimal Soulbound NFTs (standard minimal pour NFT « locked »).
- Ethereum Improvement Proposals. ERC-4973 : Account-Bound Tokens (statut : Review).
- Ethereum Improvement Proposals. ERC-5114 : Soulbound Badge (statut : Last Call, deadline 2023-09-19).
- W3C. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 19 juillet 2022.
- W3C. Verifiable Credentials Data Model. Recommandation W3C.
- Règlement (UE) 2016/679 (RGPD). Article 17 — Droit à l’effacement. EUR-Lex.
Commentaires (Aucun)