Leaders d’opinion

Le besoin d’interopérabilité dans les protocoles de jetons de sécurité – Thought Leaders

mm
Ajouter Securities.io à vos sources préférées sur Google
Divulgation : Securities.io peut recevoir une compensation via les liens vers les produits évalués. Cela n’influence pas nos évaluations éditoriales. Nous ne sommes pas un conseiller en placement inscrit ; ceci ne constitue pas un conseil en placement. Consultez notre politique d’affiliation.
Note de l’éditeur:
Cet article a été soumis de manière externe pendant le début du développement des normes de jetons de sécurité. Il reflète l’état des protocoles de conformité basés sur Ethereum et les défis d’interopérabilité au moment de la rédaction. Bien que les implémentations spécifiques abordées aient depuis évolué, les compromis architecturaux et les points de friction décrits ici restent un contexte historique utile pour comprendre pourquoi les premières tentatives de tokenisation ont eu du mal à atteindre l’échelle.

Une brève histoire des jetons

Plus de 10 ans se sont écoulés depuis que le Bitcoin a introduit la technologie blockchain au monde. Durant cette période, la liste des cas d’utilisation potentiels des registres distribués s’est rapidement élargie, des monnaies numériques aux chaînes d’approvisionnement, en passant par la gestion d’identité. Au cœur, cependant, de nombreux cas d’utilisation partagent une structure similaire : ils permettent aux utilisateurs de détenir et de transférer des actifs numériques de pair à pair. En termes simples, nous pouvons désormais échanger et suivre des actifs numériques sans avoir besoin d’une autorité centrale de confiance pour gérer le processus.

Cette évolution du secteur a naturellement conduit à l’invention des « jetons » – des actifs numériques sur une blockchain qui sont possédables et transférables entre individus. Les jetons se divisent en deux catégories principales : ceux qui représentent un actif numérique natif, et ceux qui représentent un actif du monde réel sous-jacent. En exploitant ce nouveau paradigme, des centaines de milliers de jetons différents ont déjà été créés uniquement sur Ethereum, avec une capitalisation boursière combinée de plus de 15 milliards de dollars au moment de la rédaction.

L’une des applications les plus prometteuses des jetons est la représentation des titres du monde réel sur la chaîne, ce qui permet aux actifs traditionnellement illiquides comme l’immobilier commercial d’être fractionnés et transférés de pair à pair. Ce processus, appelé « tokenisation », a suscité un intérêt considérable tant de la part des institutions traditionnelles que des nouvelles start‑ups, en raison de son potentiel à atténuer de nombreux points de friction existants sur les marchés de capitaux.

Conformité réglementaire

Bien que la blockchain puisse faciliter le transfert de propriété sur le plan technique, les jetons de sécurité restent soumis aux mêmes lois et réglementations que les titres traditionnels. Garantir que les jetons de sécurité sont conformes à la réglementation est donc essentiel à toute tokenisation potentielle, et cela a constitué un frein à l’adoption jusqu’à présent. Comme le montre le graphique ci‑dessous, l’incertitude réglementaire est largement considérée comme le principal obstacle à l’adoption de la blockchain.

De nombreux projets ont émergé dans l’écosystème blockchain, chacun concevant un protocole visant à simplifier et standardiser la façon dont les jetons de sécurité sont réglementés, échangés et gérés. En se concentrant uniquement sur Ethereum, les projets qui ont publié des normes pour résoudre ce problème incluent Securitize, Harbor, Polymath, et d’autres. Cependant, en fin de compte, sans modifications de la conception actuelle de ces protocoles, les investisseurs et les bourses continueront de rencontrer des frictions importantes lors de l’achat et de la vente de titres tokenisés. Pourquoi ? L’interopérabilité.

L’interopérabilité est cruciale

L’interopérabilité est l’un des avantages les plus significatifs de la tokenisation. Elle permet à l’ensemble de l’écosystème des applications et produits des marchés de capitaux de s’intégrer les uns aux autres grâce à des normes logicielles communes. Cependant, pour permettre l’interopérabilité au niveau des applications et des produits, il faut commencer au niveau le plus bas, avec les jetons eux‑mêmes. Dans le domaine des jetons de sécurité, l’interopérabilité est essentielle pour deux parties clés : les bourses et les investisseurs.

En tant que bourse, vous souhaitez pouvoir autoriser les investisseurs à acheter n’importe quel jeton de sécurité qu’ils sont autorisés à acquérir – quelle que soit la société qui a créé le jeton. Cela signifie ne pas devoir développer une intégration sur mesure pour chaque jeton de sécurité, mais disposer d’une intégration simple et générique uniforme pour tous les jetons de sécurité.

En tant qu’investisseur, vous souhaitez que le processus d’onboarding soit aussi simple et fluide que possible. Actuellement, lorsqu’un investisseur veut acheter des actions à plusieurs endroits, il doit fournir ses informations personnelles à maintes reprises dans un processus appelé Know Your Customer « KYC ». La blockchain a le potentiel de transformer ce processus en stockant ces informations de façon immuable sur la chaîne, où elles peuvent ensuite être référencées par tous les jetons de sécurité. Cela signifierait ne plus avoir à fournir à chaque fois les mêmes informations personnelles lors de l’achat d’un nouveau jeton, seules les informations complémentaires ou mises à jour seraient nécessaires après l’inscription initiale. Cependant, ce processus ne sera possible que si l’interopérabilité entre les jetons de sécurité est intégrée aux normes qui régissent le système.

Les protocoles

Trois des principaux protocoles de jetons de sécurité d’Ethereum ont été publiés par Securitize, Harbor et Polymath. Ces trois protocoles sont construits sur la norme de jeton ERC‑20 d’Ethereum, qu’ils étendent ensuite pour imposer la conformité lors du trading du jeton de sécurité. Cela est réalisé en interrogeant un second contrat sur la légalité de chaque transaction au moment où elle se produit.

Bien que nommés différemment dans les protocoles, l’utilisation d’un second contrat est cohérente dans les trois, obtenant le même résultat : empêcher les transactions non conformes. Ce second contrat « Regulator » est maintenu à jour avec les informations KYC et d’accréditation des utilisateurs par des services hors chaîne autorisés à le faire – par exemple une bourse ou l’émetteur du jeton.

Bien que ces trois composants puissent sembler être tout ce dont vous avez besoin pour réguler un jeton de sécurité (et sous leur forme la plus simple, ils le sont), c’est la façon dont les composants sont programmés qui détermine réellement l’interopérabilité. Malheureusement, les protocoles manquent d’interopérabilité dans deux domaines clés, ce qui continuera de créer des frictions et de ralentir l’adoption de cette technologie :

 

  1. Comment les parties autorisées mettent‑elles à jour les informations en chaîne concernant les utilisateurs?

 

Harbor

Harbor indique dans son livre blanc qu’il sera la seule partie autorisée à mettre à jour les informations des utilisateurs en chaîne pour le moment. La centralisation de ce rôle signifie que les bourses ne mettraient pas à jour les données référencées par le Regulator. Elles ne pourront donc pas approuver de nouveaux destinataires du jeton, empêchant ainsi les jetons d’être facilement échangés en dehors de la plateforme Harbor.

 

Securitize

Securitize a déjà mis en place un système permettant à plusieurs parties d’être autorisées, ce qui signifie que les investisseurs peuvent enregistrer leurs informations de conformité à plusieurs endroits et ne sont pas obligés de passer par Securitize eux‑mêmes. Les données en chaîne sont alors mises à jour directement par la partie autorisée et peuvent être consultées par tous les jetons de Securitize. De plus, afin d’éviter que les investisseurs aient à fournir leurs informations plusieurs fois, Securitize a conçu une API permettant aux parties autorisées d’accéder aux informations privées des investisseurs stockées hors chaîne, leur permettant de déterminer facilement si un individu est conforme ou si des informations supplémentaires sont nécessaires.

 

Polymath

Polymath possède un jeton utilitaire numérique natif appelé POLY qui est requis sur l’ensemble de sa plateforme pour exécuter diverses tâches, y compris pour permettre à une partie autorisée de mettre à jour vos données en chaîne. Pour qu’un individu puisse se KYC, il doit d’abord acheter des jetons POLY, qui ne disposent pas d’un marché fiat‑POLY liquide. Au lieu de cela, l’individu doit acheter une autre cryptomonnaie telle que l’« ether » (ETH) d’Ethereum avec des fiat, puis l’échanger contre du POLY. Les jetons peuvent ensuite être utilisés sur le marché KYC de Polymath pour faire une offre à un fournisseur KYC. Si le fournisseur KYC accepte l’offre, il est payé en jetons POLY pour effectuer la vérification KYC de l’individu. Ce processus constitue clairement une friction importante lors de l’onboarding sur la plateforme Polymath, et rend le processus plus complexe que nécessaire.

 

  1. Comment ces informations sur les utilisateurs sont‑elles ensuite stockées et accessibles en chaîne?

 

Harbor

En examinant le livre blanc et les contrats intelligents sur GitHub, il est techniquement possible que de nombreux jetons de Harbor partagent tous un même contrat Regulator et une même source de données utilisateur, cependant cela est improbable en raison des différences de réglementation entre les différents jetons. L’absence de jetons Harbor actifs sur Ethereum n’a pas clarifié s’il s’agit de leur intention ou si chaque jeton sera déployé avec son propre Regulator.

 

Securitize

Le protocole de Securitize est conçu de manière à ce que son contrat Regulator interroge un troisième contrat intelligent qui stocke les informations des utilisateurs. Cela permet à chaque jeton d’avoir des réglementations uniques encodées dans son propre Regulator, tout en partageant une source commune de données utilisateur dans le troisième contrat, ce qui signifie que lorsqu’un utilisateur effectue un KYC pour un jeton Securitize, ses informations sont stockées et prêtes pour l’achat de futurs jetons.

 

Polymath

Il n’est pas explicitement indiqué dans leur livre blanc si Polymath possède une source centrale de données de conformité stockée en chaîne avec laquelle chaque Regulator interagit, ou si les jetons ont leur propre source locale d’information. Cependant, d’après les contrats d’exemple de Polymath, il semble que chaque jeton utilise une source locale d’information, qui n’est pas partagée entre différents jetons. Bien que cela puisse présenter des avantages, cette configuration comporte le risque de redondance et d’incohérences de données.

Prenons l’exemple suivant : Bob a manifesté son intérêt pour deux jetons de sécurité Polymath, ABC et DEF, et a été approuvé en tant qu’investisseur pour chacun d’eux. Ces informations sont envoyées au contrat Regulator de chaque jeton. Un mois plus tard, Bob tente d’acheter davantage de jetons DEF mais il s’avère qu’il n’est plus accrédité. Cette information est transmise au Regulator de DEF pour mettre à jour le statut d’investisseur de Bob en non‑accrédité. Maintenant, en chaîne, il y a des informations contradictoires : ABC considère que Bob est un investisseur vérifié, tandis que DEF n’est pas d’accord. Il est évident qu’une source centrale d’information éviterait de telles divergences.

Interopérabilité des protocoles

Comme discuté précédemment, deux parties principales sont impliquées dans l’émission et l’échange de jetons de sécurité pour lesquelles l’interopérabilité sera cruciale : les bourses et les investisseurs. Ces deux parties souhaitent une expérience fluide lorsqu’elles interagissent avec différents jetons de sécurité. Ainsi, en utilisant les protocoles tels quels, examinons comment les bourses et les utilisateurs seront affectés.

Exchanges

En tant que bourse, l’intégration de ces protocoles à des fins de transfert est simple : tous les jetons utilisent la norme ERC‑20, offrant une interface uniforme pour invoquer les transferts, les approbations et les vérifications de solde. Cependant, l’intégration supplémentaire de l’aspect conformité de chaque protocole devient beaucoup plus complexe. Vous vous souviendrez qu’il n’est actuellement pas possible pour une partie de confiance d’être autorisée sur le protocole de Harbor – elle devra plutôt diriger les utilisateurs vers Harbor pour qu’ils effectuent eux‑mêmes le KYC. Pour intégrer le protocole de Securitize, la partie de confiance doit être autorisée par Securitize, ce qui lui permettra d’accéder aux données KYC des investisseurs via l’API hors chaîne, et de mettre à jour les informations en chaîne stockées dans le magasin de données en chaîne.

L’intégration du protocole de Polymath est probablement la plus complexe. La partie de confiance doit s’inscrire en tant que fournisseur KYC sur le marché KYC de Polymath et se préparer à recevoir des offres en jetons POLY en échange de la prestation de services KYC. En fournissant des services KYC aux investisseurs, la partie de confiance doit alors mettre en place un moyen d’assurer que les données en chaîne dupliquées stockées sur chaque Regulator de sécurité ne deviennent pas incohérentes.

Non seulement les protocoles possèdent des interfaces différentes que la partie de confiance doit intégrer, mais chaque protocole a également une manière différente de fournir des rapports d’erreur à la bourse. Lors de la création d’une interface, il est important de pouvoir traduire les erreurs qui surviennent en quelque chose de compréhensible pour les utilisateurs. Par exemple, si un utilisateur ne peut pas acheter un jeton, cela peut être dû à de nombreuses raisons : le titre peut avoir une période de détention qui n’est pas encore remplie, ou peut restreindre le nombre maximal de détenteurs autorisés. Pour pouvoir communiquer ces messages aux utilisateurs, la bourse devra intégrer une méthode de rapport d’erreur différente pour chaque protocole.

Investors 

Les différentes méthodes par lesquelles l’onboarding des investisseurs est actuellement conçue dans les protocoles signifient que les investisseurs devront probablement fournir leurs informations personnelles de nombreuses fois à différentes plateformes et de manières différentes. Cela est dû au fait que Harbor n’a autorisé aucune autre partie, et que Polymath oblige les investisseurs à enchérir pour les processus KYC en utilisant des jetons POLY. La friction engendrée par l’application de ces méthodes de conformité peut rendre les investisseurs réticents ou incapables d’acheter des titres qu’ils achèteraient autrement.

L’ampleur de cette friction induite par les protocoles sur les investisseurs pourrait être partiellement atténuée par la manière dont les bourses intègrent chaque protocole. Par exemple, si un investisseur choisit de faire son KYC sur une bourse pour acheter un jeton Polymath, cette bourse, si elle est autorisée, pourrait choisir de mettre à jour simultanément le stockage de données de Securitize. Cela signifierait que les informations de l’investisseur sont en chaîne au cas où elles seraient nécessaires à l’avenir. Cependant, si aucun changement n’est apporté aux conceptions actuelles des protocoles, le processus d’enregistrement et d’achat de titres restera décourageant.

Solutions

La solution à ce problème n’a pas besoin d’être complexe. En fait, il est possible d’introduire certaines solutions sans modifier les jetons déjà actifs sur Ethereum. Une solution idéale, qui minimise les frictions tant pour les bourses que pour les investisseurs, et qui empêche les incohérences de données causées par la multiplicité des sources de conformité, ressemblerait étroitement au magasin de données centralisé en chaîne de Securitize ; cependant, une telle configuration devrait ensuite être adoptée à l’échelle de l’industrie.

En disposant d’une source centrale d’information en chaîne, les risques d’incohérences de données sont éliminés, et les investisseurs peuvent acheter différents titres grâce à une seule vérification de conformité. Ce contrat central effectuerait la vérification que le transfert est conforme pour tous les jetons de sécurité, et le transfert se poursuivrait ou serait annulé. L’API hors chaîne accessible à toutes les bourses autorisées permet de communiquer les informations de conformité des investisseurs aux bourses et réduit le nombre de fois où les investisseurs doivent fournir leurs données. Ces aspects, combinés, réduisent considérablement la charge d’intégration requise par les bourses.

L’introduction d’un tel nouveau système engendre clairement certaines complications, et plusieurs problèmes devront encore être résolus. Par exemple, dans la conception de la façon dont chaque bourse devient autorisée : qui prend la décision qu’une bourse doit être fiable ? Il faut du temps pour concevoir un système qui permette d’atteindre un consensus.

Conclusion

La tokenisation des titres reste un domaine encore en phase de développement et d’adoption, en partie à cause des complexités de la conformité réglementaire. Bien que la publication de protocoles simplifie la conformité à nombre de ces réglementations en permettant leur application lors de chaque transfert, il reste encore un long chemin avant que ce processus ne devienne fluide. Tant que nous n’aurons pas d’accord entre les protocoles sur la façon dont les informations des investisseurs sont stockées et mises à jour à la fois en chaîne et hors chaîne, des frictions importantes persisteront tout au long des processus d’enregistrement et d’investissement pour toutes les parties concernées.

Alice Henshaw est un ingénieur en contrats intelligents chez Fluidity. Fluidity est une entreprise basée à New York qui travaille sur la DeFi, et est surtout connue pour avoir créé la plateforme d'échange décentralisée Airswap. Auparavant, Alice a travaillé chez ConsenSys où elle a conçu et mis en œuvre des systèmes de contrats intelligents responsables de plus de 100 millions de dollars de volume de transactions. Elle est diplômée de l'Université d'Oxford avec un diplôme en informatique.