Qu'est-ce qu'un « jeton lié à l'âme » (SBT) ? Peut-il être vendu ou transféré comme un NFT normal ?

Définition et caractéristiques principales

1. Un jeton soulbound (SBT) est un identifiant numérique non transférable délivré à une adresse blockchain spécifique, conçu pour représenter des affiliations, des réalisations ou des attributs immuables de cette identité.

2. Contrairement aux jetons ERC-20 ou ERC-721 standard, les SBT sont intentionnellement codés pour manquer de fonctions de transfert : aucune méthode transferFrom ou safeTransferFrom n'existe dans leur logique de contrat intelligent.

3. Ils sont généralement déployés sur des chaînes compatibles Ethereum à l'aide de normes personnalisées telles que ERC-5114 ou d'implémentations expérimentales construites sur EIP-4973, qui imposent la liaison à un seul portefeuille pendant tout son cycle de vie.

4. Le terme « lié à l'âme » s'inspire des objets liés à l'âme de World of Warcraft : une fois acquis, ils ne peuvent en aucun cas être échangés, vendus ou offerts.

5. Les SBT contiennent souvent des métadonnées stockées en chaîne ou via un stockage décentralisé comme IPFS, reliant des affirmations vérifiables telles que les diplômes universitaires, le statut de membre ou l'historique des contributions au sein des DAO.

Mécanismes techniques d’application

1. Les contrats intelligents régissant les SBT incluent des retours explicites dans tous les points d'entrée liés au transfert, garantissant que toute tentative de déplacement du jeton déclenche un échec de transaction avec un message d'erreur du type « Soulbound : Transfert interdit » .

2. Certaines implémentations utilisent des modèles de proxy dans lesquels l'ID du jeton correspond directement au hachage d'adresse du propriétaire, rendant la propriété indissociable de l'identité cryptographique.

3. La validation économe en gaz est obtenue en vérifiant msg.sender == OwnerOf(tokenId) avant d'autoriser toute opération de modification d'état, renforçant ainsi l'immuabilité au moment de l'exécution.

4. Les outils de vérification en chaîne tels que l'interface de lecture de contrat d'Etherscan exposent uniquement les fonctions OwnerOf et tokenURI : aucune interface de transfert n'apparaît dans l'ABI.

5. Les intégrations de portefeuille comme MetaMask omettent délibérément les SBT des listes d'actifs à moins qu'elles ne soient explicitement activées via une détection de jeton personnalisée, réduisant ainsi les risques d'interaction accidentelle.

Cas d'utilisation dans les systèmes d'identité décentralisés

1. La gouvernance DAO utilise les SBT pour émettre des droits de vote liés à une participation à long terme, empêchant ainsi les systèmes d'achat de votes courants avec les jetons de gouvernance négociables.

2. Les plateformes d'accréditation déploient des SBT pour attester des cours ou des certifications terminés, où la révocation nécessite un consensus des institutions émettrices plutôt qu'une action unilatérale du titulaire.

3. Les protocoles de prêt intègrent des SBT pour évaluer la solvabilité en fonction du comportement historique, comme une activité de jalonnement cohérente ou le parrainage de propositions, sans s'appuyer sur un KYC centralisé.

4. Les rôles de modération communautaire sont attribués via les SBT pour garantir la responsabilité ; les modérateurs ne peuvent pas se décharger de leur responsabilité en vendant leur autorité.

5. Les ponts de réputation inter-chaînes utilisent les SBT pour ancrer les mesures de confiance dans tous les écosystèmes, permettant un contrôle d'accès cohérent sans dupliquer l'infrastructure d'identité.

Distinction avec les NFT traditionnels

1. Les NFT standards tirent leur valeur en partie de la rareté et de la liquidité du marché, tandis que les SBT gagnent en utilité grâce à l'intégrité contextuelle et à la cohérence relationnelle.

2. Les marchés comme OpenSea ou Blur rejettent les SBT lors de la cotation en raison d'événements de transfert manquants dans leurs journaux d'événements : aucun événement de transfert n'est émis lors de la frappe ou des interactions ultérieures.

3. Les métadonnées pour les SBT mettent l'accent sur les attestations plutôt que sur l'esthétique ; Les champs de traits contiennent généralement des horodatages, des signatures d'émetteur et des preuves Merkle au lieu de descripteurs visuels.

4. Les indexeurs tels que The Graph excluent les SBT des sous-graphes NFT génériques, à moins que les développeurs ne construisent une logique d'indexation dédiée axée sur la persistance de la propriété plutôt que sur la vitesse des transactions.

5. Les interprétations juridiques traitent les SBT différemment dans le cadre actuel des actifs numériques : les régulateurs les classent plus étroitement avec les diplômes numériques qu'avec les titres ou les objets de collection.

Foire aux questions

Q : Un SBT peut-il être gravé et réémis à une autre adresse ? R : Non. La gravure nécessite l'autorisation du propriétaire et les fonctionnalités autorisées par le contrat ; la plupart des contrats SBT désactivent complètement la gravure ou la limitent aux émetteurs uniquement. Et même dans ce cas, la réémission suit de nouvelles règles d'émission, et non la sémantique de transfert.

Q : Les SBT prennent-ils en charge la composabilité avec les protocoles DeFi ? R : Il existe une composabilité limitée. Les protocoles peuvent accepter les SBT comme garantie s’ils mettent en œuvre des oracles d’évaluation personnalisés, mais aucun mécanisme de liquidation automatisé n’existe puisque les SBT ne peuvent pas être saisis ou vendus sur les marchés secondaires.

Q : Existe-t-il un moyen de prouver la propriété de SBT sans révéler les clés privées ? R : Oui. Les preuves sans connaissance telles que les zk-SNARK permettent aux détenteurs de démontrer la possession d'un SBT sans exposer les adresses de portefeuille ni signer les clés – ceci est largement utilisé dans les systèmes de participation DAO préservant la confidentialité.

Q : Que se passe-t-il si l'entité émettrice disparaît ? R : Les SBT restent valables sur la chaîne tant que le contrat intelligent sous-jacent est actif. Leur authenticité repose sur l'immuabilité du code de déploiement, et non sur l'implication opérationnelle continue de l'émetteur d'origine.