Analyse approfondie : quelle émission de pièces inter-chaînes est la meilleure ?

Article original de : Arjun Chand

Traduction originale : TechFlow

Remarque : si vous connaissez déjà le fonctionnement du cadre de jetons introduit par le protocole d’interopérabilité, vous pouvez passer directement à la section d’analyse comparative.

introduction

Autrefois, l'émission d'un token était simple : il suffisait de le déployer sur Ethereum, car c'est là que se déroulait toute l'activité : utilisateurs, traders, capitaux et liquidités. Aujourd'hui, c'est beaucoup plus compliqué. La liquidité est répartie sur Bitcoin, Ethereum, L2, Solana et d'autres chaînes. Alors, où peut-on émettre un token ? Il n'y a pas de réponse simple.

Et si vous n'aviez pas à choisir une seule chaîne ? Imaginez un jeton qui pourrait être utilisé partout et circuler sans problème dans toute l'économie cryptographique.

Grâce à protocoles d'interopérabilité (également appelés ponts), il est désormais possible d’émettre des jetons pour un marché unifié sur plusieurs chaînes. Cela crée une liquidité sans frontières et simplifie les opérations pour les émetteurs de jetons : plus de liquidité, une plus grande acceptation et des effets de réseau plus forts – sans avoir à se soucier des problèmes liés à la fragmentation. En gros, c’est comme avoir un compte bancaire mondial qui fonctionne partout, intégré à tous les écosystèmes DeFi.

Dans cet article, nous allons comparer les principaux frameworks de tokens proposés par différents protocoles d'interopérabilité. Notre objectif est d'évaluer leurs caractéristiques, avantages et compromis uniques pour aider les équipes à choisir la meilleure solution pour l'émission de tokens multi-chaînes natifs. Nous examinerons les frameworks suivants :

• L'interchaîne d'Axelar Jeton Service (STI)

• Transferts de jetons natifs de Wormhole (NTT)

• Jeton fongible Omnichain de LayerZero (OFT)

• Jeton Warp d'Hyperlane

• xERC 20 (EIP 7281 : jeton de pont souverain)

Commençons.

Comment fonctionne le framework Token

Il existe deux approches principales pour les frameworks de jetons, selon que vous transformez un jeton existant en jeton multi-chaîne ou que vous lancez un jeton multi-chaîne natif dès le début.

Gravure et frappe : pour les jetons multi-chaînes natifs

Lorsqu'un jeton est émis de manière native sur plusieurs chaînes dès le premier jour, son approvisionnement est réparti sur ces chaînes. Lorsque des jetons sont transférés entre les chaînes, ils sont détruits sur la chaîne source et frappés sur la chaîne de destination, ce qui garantit que l'approvisionnement total reste constant.

Considérez-le comme un système de registre (comme l'expliquent de nombreuses équipes d'interopérabilité). Voici un exemple : considérez le jeton X, avec une offre totale de 1 000 jetons, répartis sur cinq chaînes en fonction de la demande :

• Chaîne A : 400 jetons

• Chaîne B : 200 jetons

• Chaîne C : 200 jetons

• Chaîne D : 100 jetons

• Chaîne E : 100 jetons

Si un utilisateur transfère 50 jetons de la chaîne E vers la chaîne A, ces jetons seront détruits sur la chaîne E et frappés sur la chaîne A. La distribution mise à jour est la suivante :

• Chaîne A : 450 jetons

• Chaîne B : 200 jetons

• Chaîne C : 200 jetons

• Chaîne D : 100 jetons

• Chaîne E : 50 jetons

Ce processus garantit que l’offre totale reste à 1 000 jetons, facilitant ainsi des transferts fluides sans glissement.

Verrouillage et frappe : pour les jetons existants

Pour les jetons existants qui ont été initialement déployés sur une seule chaîne, le processus est différent : l'ensemble de l'offre est concentré sur une chaîne, et lorsqu'elle est transférée vers une autre chaîne, une partie de l'offre est verrouillée dans un contrat intelligent sur la chaîne source, tandis que le même nombre de jetons est émis sur la chaîne cible.

Cette approche est similaire au fonctionnement des tokens enveloppés. Les tokens verrouillés sur la chaîne A peuvent être frappés en tant que tokens enveloppés sur la chaîne B. Cependant, ces tokens peuvent désormais également être transférés de la chaîne B à la chaîne C en utilisant la méthode de gravure et de frappe, sans avoir à être verrouillés sur plusieurs chaînes. L'approvisionnement d'origine reste toujours sur la chaîne A, ce qui garantit que les transferts entre les chaînes ne nécessitent que de vérifier que les tokens brûlés correspondent aux tokens frappés.

Pourquoi les systèmes de jetons sont-ils importants ?

Voici les avantages pour les équipes d'avoir des jetons qui peuvent être échangés dans une chaîne croisée unifiée marché:

• Liquidité – Un marché unifié attire plus de traders et augmente la liquidité.

• Reconnaissance de la marque – Le jeton est disponible dans divers écosystèmes DeFi, augmentant la demande et la reconnaissance de la marque.

• Simplicité – La gestion des jetons devient plus simple et réduit la complexité.

• Redondance – Si une chaîne tombe en panne, le jeton peut toujours être utilisé sur d’autres chaînes, offrant ainsi un filet de sécurité.

• Marché expansion – Les tokens peuvent être déployés sur plusieurs chaînes plus rapidement, ce qui facilite leur adoption. De plus, les écosystèmes interconnectés laissent la place à davantage d’expérimentation dans l’espace DeFi.

• Effets de réseau – La collaboration avec d’autres projets augmente l’adoption et la valeur.

Jetez un oeil à Protocole de transfert inter-chaînes de Circle (CCTP) En lançant CCTP, Circle permet à l'USDC d'être négocié de manière transparente sur les chaînes prises en charge, résolvant ainsi des problèmes majeurs :

• Liquidité non fragmentée – Auparavant, il existait différentes versions de l’USDC sur chaque chaîne, ce qui entraînait des inefficacités. Désormais, l’USDC est le même sur toutes les chaînes.

• Expansion du marché – Le déploiement de l’USDC sur plusieurs chaînes lui permet d’accéder à davantage d’utilisateurs et de marchés.

• Efficacité du capital – Les utilisateurs peuvent gérer de grandes quantités d’USDC sans avoir besoin de pools de liquidités ou de wrappers.

• Frais minimes – Les frais de transfert sont principalement des frais d’essence.

• Aucun dérapage – Les transferts sont directs, éliminant ainsi le risque de dérapage.

L'ensemble de fonctionnalités uniques que Circle fournit pour l'USDC est rendu possible par leur protocole de pont personnalisé CCTP, un luxe que la plupart des projets n'ont pas. C'est là qu'entrent en jeu les cadres de jetons maintenus par des protocoles d'interopérabilité. Ces cadres fournissent des fonctionnalités similaires à celles fournies par CCTP pour l'USDC, mais pour n'importe quel jeton. En émettant des jetons via ces cadres, les projets peuvent établir des marchés unifiés sur plusieurs chaînes prises en charge, permettre des transferts simples, utiliser des mécanismes de gravure/verrouillage et de frappe.

Comparaison des frameworks de tokens

Maintenant que nous comprenons comment fonctionnent les frameworks de jetons et leurs avantages, comparons les différentes solutions disponibles sur le marché permettant aux équipes d'émettre des jetons.

Sécurité

Sécurité du cadre de tokens

Vous trouverez ci-dessous une explication des principaux aspects de sécurité abordés dans le tableau :

1. Mécanisme de vérification

Le mécanisme de vérification est au cœur de la vérification des transferts inter-chaînes. Il fait référence à la manière dont les messages sont vérifiés et au type de paramètres que chaque infrastructure fournit en termes de mécanismes de vérification – qu'il s'agisse d'une option unique, d'un système modulaire avec plusieurs options ou d'une conception flexible compatible avec n'importe quel pont – cela permet aux émetteurs de jetons de choisir la solution la plus appropriée en fonction de leurs besoins de sécurité.

Bien que les mécanismes d’authentification personnalisés offrent de nombreux avantages, la configuration par défaut est toujours le plus utilisé . Il est donc important de prêter attention à la sécurité du schéma d'authentification par défaut. Il est recommandé aux équipes d'utiliser des mécanismes d'authentification supplémentaires en plus du schéma par défaut pour améliorer ses paramètres de sécurité.

Le recours à plusieurs schémas de validation présente à la fois des avantages et des inconvénients en matière de vivacité. L’avantage est une meilleure tolérance aux pannes : si l’un des fournisseurs tombe en panne, les autres peuvent assurer la continuité des opérations, améliorant ainsi la fiabilité du système. Cependant, cela augmente également la complexité du système. Chaque schéma supplémentaire introduit un point de défaillance potentiel, augmentant le risque de perturbation opérationnelle.

2. Flexibilité du mécanisme de vérification

Soulignez la flexibilité de chaque framework dans la personnalisation des mécanismes d’authentification, en particulier si les émetteurs de jetons peuvent choisir parmi une variété d’options ou sont limités à l’utilisation des paramètres par défaut.

3. Des solutions de vérification prédéfinies exceptionnelles

Les schémas prédéfinis sont des mécanismes d'authentification que les émetteurs de jetons peuvent utiliser directement pour l'authentification des messages, simplifiant ainsi le processus de déploiement. Un framework qui fournit des options prédéfinies plus fiables est généralement un signe positif.

Bien que certains frameworks offrent plus de schémas de vérification que d’autres, il est essentiel de les évaluer en fonction de leur sécurité , qui peut aller d’un seul vérificateur à un ensemble complet de vérificateurs.

Par exemple, OFT propose des options DVN (Dynamic Verification Network) qui incluent un seul validateur et des options plus puissantes comme CCIP ou Axelar qui utilisent un ensemble complet de validateurs. De même, Warp Token propose ISM (Smart Contract Management) qui comprend un ISM multi-signature géré par la communauté Hyperlane, tout en offrant également des options comme Aggregate ISM qui permet aux équipes de combiner la sécurité de plusieurs ISM.

De plus, de nombreux schémas d’authentification ne sont peut-être pas encore largement utilisés ou testés de manière adéquate dans le monde réel. Par conséquent, les équipes doivent évaluer soigneusement la qualité des schémas d’authentification disponibles et choisir celui qui correspond au niveau de sécurité requis. Nous recommandons vivement de tirer parti des options existantes pour créer un système d’authentification par jeton sécurisé et fiable. Dans de futurs articles de recherche, nous approfondirons les fonctionnalités de sécurité des différents schémas d’authentification fournis par divers frameworks de jetons.

4. Schéma d'authentification par défaut

Indique si le framework fournit un mécanisme d'authentification par défaut. Ceci est très important car la plupart des équipes choisissent généralement l'option par défaut pour plus de facilité d'utilisation. Si l'émetteur du jeton décide d'utiliser l'option par défaut, il est particulièrement important d'évaluer sa sécurité et d'envisager de tirer parti des fonctionnalités personnalisables pour améliorer la sécurité.

5. Vérification de la participation à l'application

Soulignez si les équipes peuvent participer au processus de vérification, ce qui peut ajouter une sécurité supplémentaire, ou leur permettre de prendre le contrôle de leur propre sécurité. Cela est très important car cela permet aux équipes d'améliorer la sécurité en combinant leurs propres systèmes de vérification avec les mécanismes existants. De cette façon, si d'autres méthodes de vérification échouent, elles peuvent compter sur leurs propres protections pour éviter les risques potentiels.

Par exemple, des équipes comme Stargate, Tapioca, BitGo, Cluster et Abracadabra exécutent leurs propres DVN sur LayerZero, démontrant ainsi comment d’autres équipes peuvent tirer parti des capacités de personnalisation disponibles. Bien que cela nécessite des efforts supplémentaires, davantage d’équipes devraient tirer parti de cette couche de sécurité supplémentaire. Lorsqu’elle est mise en œuvre efficacement, cette fonctionnalité peut éviter des problèmes majeurs en cas de panne critique.

6. Résistance à la censure

Définissez si et comment les messages peuvent être censurés, ce qui peut entraîner l'échec de l'application et affecter le fonctionnement normal de l'équipe. Dans la plupart des cas, même si l'application est censurée, ils peuvent toujours passer à un autre mécanisme de vérification ou relais dans le même cadre. Cependant, cela nécessite des efforts supplémentaires et peut ne pas être une solution pratique pour les problèmes à court terme.

7. Open Source

La base de code open source permet aux développeurs d'auditer les fonctionnalités de sécurité et la configuration globale du framework, garantissant ainsi la transparence du code exécuté. Cette transparence est essentielle pour garantir la sécurité et la fiabilité du logiciel.

Comparaison des coûts

Ce tableau compare les structures de frais de plusieurs frameworks de tokens, en se concentrant sur la manière dont chaque framework gère les opérations de protocole, la messagerie et d'autres frais supplémentaires. Il convient de noter que tous les frameworks permettent d'ajouter des frais d'application personnalisés au niveau de la couche applicative. De plus, dans tous les frameworks, les processus de vérification et de transfert impliquent des frais, y compris des frais payés aux relais, aux émetteurs-récepteurs ou à des entités similaires.

Actuellement, la plupart des frais sont associés à la vérification et au relais des messages. Comme mentionné précédemment, tous les frameworks de jetons fournissent plusieurs mécanismes pour vérifier les messages. Bien que chaque schéma de vérification supplémentaire augmente la sécurité du système, il augmente également les frais et les coûts pour les utilisateurs.

Les frais sont liés au cadre du jeton

Frais de couche de protocole

Il s'agit des frais facturés par chaque framework lors de l'exécution d'un transfert ou d'une autre opération.

Étant donné qu'il existe un changement de frais géré par la DAO, les émetteurs de jetons peuvent avoir besoin de payer des frais supplémentaires au protocole d'interopérabilité derrière le framework de jetons (par exemple LayerZero pour les OFT ou Hyperlane pour les jetons Warp). Cela introduit une dépendance avec la gouvernance de la DAO, car toute modification du changement de frais affectera directement les jetons émis via ces frameworks, les rendant ainsi soumis aux décisions de la DAO.

Contrats intelligents

Ce tableau présente les principales propriétés des contrats intelligents pour chaque framework, soulignant leurs différences en termes de flexibilité, de sécurité et de personnalisation, avec un accent particulier sur l'historique de déploiement, les audits de sécurité, les récompenses offertes et les options de personnalisation notables pour un contrôle plus granulaire.

Notamment, tous les frameworks permettent aux applications de définir des limites de débit et des listes noires, des fonctionnalités de sécurité clés qui peut aider à prévenir des pertes financières importantes lorsqu'ils sont utilisés efficacement. De plus, chaque framework offre la flexibilité de déployer des contrats intelligents comme immuables ou évolutifs, en fonction des besoins spécifiques de l'application.

Cadre de jetons pour les contrats intelligents

• Temps de déploiement

Ce champ affiche le temps de déploiement de chaque contrat intelligent du framework, reflétant le temps opérationnel du framework.

• audit

Le nombre d'audits est un indicateur important de sécurité. Les audits garantissent l'intégrité des contrats intelligents et identifient les vulnérabilités et les problèmes qui peuvent affecter le système.

• prime

Les primes sont des incitations financières fournies par le cadre pour encourager les chercheurs en sécurité externes à découvrir et signaler les vulnérabilités.

• Des caractéristiques distinctives pour un contrôle précis

Les cadres de contrats intelligents permettent aux applications d'implémenter une variété de fonctionnalités de sécurité personnalisables en fonction de besoins spécifiques. Ce champ met en évidence certaines des fonctionnalités de sécurité clés fournies par le cadre pour garantir la sécurité du système.

Adoption et promotion

Chaque framework possède ses propres caractéristiques uniques, et le niveau d’implication des développeurs, des protocoles et des plateformes varie en fonction de l’orientation technique, de l’approche d’intégration et de l’assurance de sécurité.

• Principaux contributeurs

Cette section met en évidence l'implication active de diverses équipes dans la création et la maintenance de chaque framework. La diversité des participants au-delà de l'équipe de développement d'origine est un indicateur positif de plusieurs facteurs : (1) la demande plus large pour le framework, et (2) l'accessibilité et la facilité d'utilisation du framework, à la fois par des moyens sans autorisation et par une collaboration générale.

• Adoption

L'adoption reflète le niveau d'utilisation et de traction de chaque framework, mesuré par le nombre de jetons déployés et la valeur totale verrouillée. Elle donne un aperçu de l'acceptation générale du framework par les développeurs et les protocoles, ainsi que de sa fiabilité en matière de sécurisation des actifs.

• Une équipe connue

Cette section met en évidence les meilleures équipes et protocoles adoptant chaque cadre, reflétant leur confiance et leur traction globale dans l'industrie.

• Superposition de machine virtuelle

La couverture des machines virtuelles fait référence à la gamme de machines virtuelles prises en charge par chaque infrastructure. La prise en charge d'un plus grand nombre de machines virtuelles offre une plus grande flexibilité et une meilleure compatibilité dans différents environnements de blockchain. Cela offre davantage de choix aux applications et aux émetteurs de jetons, leur permettant d'atteindre une communauté diversifiée

• Nombre de chaînes de déploiement

Ce champ reflète le nombre de chaînes déployées par chaque framework, c'est-à-dire le nombre de chaînes que chaque application ou émetteur de token peut prendre en charge s'il décide d'utiliser un framework spécifique. Ceci est directement lié au nombre de marchés et d'écosystèmes de finance décentralisée (DeFi) auxquels l'application peut accéder. Un déploiement de chaîne plus élevé signifie un accès plus large à la liquidité.

De plus, bien que l’extension sans autorisation du framework sur différentes chaînes présente un grand potentiel, elle peut également présenter des défis si les développeurs doivent créer et maintenir eux-mêmes une infrastructure critique. Pour certaines équipes, comme celles qui cherchent à créer un support de pont pour de nouvelles chaînes, ce travail peut en valoir la peine. Mais pour les émetteurs de jetons qui souhaitent simplement étendre la portée de leur jeton à une autre chaîne, cela peut s’avérer trop complexe et gourmand en ressources.

• Une différenciation unique

Chaque framework apporte un différenciateur unique, généralement sous la forme de fonctionnalités, d'outils ou d'intégrations spéciaux, qui le distinguent des autres. Ces différenciateurs attirent souvent les développeurs et les protocoles qui recherchent des fonctionnalités spécifiques, une facilité d'utilisation ou qui souhaitent obtenir une plus grande distribution pour leurs jetons.

Expérience du développeur

Avis de non-responsabilité : cette section reflète les connaissances acquises par @SlavaOnChain (Responsable des relations avec les développeurs chez LI.FI) et des discussions avec des développeurs familiarisés avec différents frameworks. Les expériences des développeurs peuvent varier en fonction de leur parcours et de leur cas d'utilisation.

Expérience du développeur avec le framework Token

• Facilité d'intégration

Fait référence à la facilité avec laquelle il est possible de déployer un jeton à l’aide du framework pour la première fois sans l’aide d’une équipe.

• document

Évaluer l’efficacité des conseils, des exemples et des documents de référence du cadre pour aider les développeurs à comprendre et à utiliser la plateforme.

• Outils de développement

Considérez la suite complète d’outils, notamment les bibliothèques, les kits de développement logiciel (SDK) et les utilitaires qui facilitent la création, le test et le déploiement de jetons à l’aide du framework.

Points clés à retenir

A. Tendances en matière d’interopérabilité

• Mécanismes de personnalisation et de validation – Tous les frameworks proposent des mécanismes de validation personnalisables, ce qui marque une nouvelle tendance dans les protocoles interopérables. La discussion sur wstETH dans le forum de gouvernance du DAO de Lido a été un moment clé qui a mis en évidence la nécessité de cette fonctionnalité.

• Pratiques de sécurité – Des fonctionnalités telles que la limitation du débit, la liste blanche/liste noire et la possibilité pour les émetteurs de jetons de participer à la validation des messages et aux paramètres de sécurité via des politiques et des rôles personnalisés sont devenues des pratiques standard dans tous les frameworks, ce qui indique que la sécurité dans l'espace d'interopérabilité évolue dans une direction positive.

• Les défis de l’adoption au-delà des valeurs par défaut – Bien que les mécanismes d’authentification personnalisés soient bénéfiques, les taux d’adoption au-delà des valeurs par défaut restent faibles, ce qui nécessite une meilleure formation sur les options de sécurité. Il est essentiel de garantir que les schémas d’authentification par défaut sont hautement sécurisés, car ce sont les plus couramment utilisés.

• Mécanismes de validation – L’ensemble de validateurs d’Axelar et le réseau de garde de Wormhole sont des mécanismes de validation largement adoptés qui sont déjà disponibles dans divers frameworks.

B. Principaux cadres de jetons

• OFT de LayerZero – Leader en nombre de jetons déployés et en valeur sécurisée, grâce à son avantage d'entrée précoce sur le marché, à son large support pour la plupart des chaînes et à ses ressources complètes pour les développeurs.

• Jeton Warp par Hyperlane – L’équipe s’efforce de rendre le framework et les outils de développement plus conviviaux pour les opérations sans autorisation. Cela se reflète dans plusieurs implémentations de machines virtuelles créées et maintenues par des équipes externes, ce qui montre la commodité d’utiliser le framework de manière sans autorisation.

• NTT du trou de ver – a rapidement été largement adopté, dispose d'un jeton de grande valeur déployé sur diverses chaînes et offre de nombreuses fonctionnalités uniques dans sa conception, telles que l'absence de frais de commutation au niveau du protocole. C'est un choix populaire pour les équipes qui cherchent à faire évoluer leurs jetons vers Solana ou à intégrer les jetons Solana à l'écosystème EVM.

• Le STI d'Axelar – Avec plus de $400M En termes de Total Value Locked (TVL), Axelar est classé parmi les 25 premières chaînes Proof of Stake (PoS). Le framework ITS est un moteur de croissance clé, générant à la fois la croissance de TVL et le volume de messages envoyés via le réseau Axelar.

• Cadre xERC 20 – Le seul framework complètement indépendant des ponts, contrairement à d’autres frameworks qui s’apparentent davantage à des produits. De nombreux protocoles interopérables qui ne disposent pas de leurs propres frameworks encouragent les équipes à utiliser xERC 20 pour émettre des jetons, et certains protocoles fournissent également des modèles prédéfinis pour l’intégration.

• Différences dans les structures tarifaires – xERC 20 et NTT sont deux frameworks qui ne disposent pas de commutateurs de frais au niveau du protocole.

Résumer

Les cadres de jetons émergent et pourraient changer tous les aspects de la façon dont la valeur circule dans un monde multi-chaînes. Actuellement, le transfert d'actifs entre chaînes nécessite généralement des pools de liquidités ou solveurs , mais les frameworks de jetons éliminent le besoin de pools de liquidité ou de solveurs. Au lieu de cela, les actifs peuvent être créés directement sur la chaîne cible via des protocoles interopérables.

En fait, le Token Framework pourrait bien être la fin des actifs enveloppés. La liquidité n'a plus besoin d'être fragmentée sur les chaînes. Vous pouvez créer des actifs fongibles sur n'importe quelle chaîne, et ils peuvent être échangés entre les chaînes pour seulement les frais de gaz. Nous voyons déjà des signes de cette tendance. Circle a lancé le CCTP pour contourner les problèmes liés aux tokens enveloppés pour l'USDC, et de nombreuses grandes équipes et tokens de grande valeur adoptent désormais le Token Framework. Cela suggère que les progrès s'accélèrent.

Il existe toutefois des inquiétudes légitimes concernant les risques de réaction en chaîne de tiers. si les protocoles interopérables échouent , cela pourrait affecter tous les projets construits sur eux. Malgré ces risques, l'adoption des frameworks de jetons continue de croître.

Un autre point de vue est le suivant : dans un avenir où la chaîne sera abstraite, les frameworks de tokens n’auront plus d’importance car les solveurs échangeront des tokens natifs contre des utilisateurs en coulisses. Bien que cela ait du sens – les utilisateurs n’auront pas besoin de penser aux tokens – il manque un facteur clé. Alors, qu’en est-il des solveurs eux-mêmes ? Pour les solveurs, les frameworks de tokens peuvent être très utiles. Ils résolvent le problème difficile de l’inventaire des actifs et du rééquilibrage car ils ne nécessitent pas de transfert de liquidité entre les chaînes. C’est pourquoi les frameworks comme CCTP sont privilégiés par les solveurs lors du déplacement de l’USDC – ils sont bon marché, efficaces et parfaits pour le rééquilibrage inter-chaînes.

On ne sait pas encore comment tout cela va se dérouler. Peut-être n’aurons-nous besoin de frameworks de tokens que sur quelques chaînes périphériques, ou peut-être deviendront-ils la norme pour le déploiement de tokens dans l’espace crypto. Ce que nous savons aujourd’hui, c’est que l’adoption de frameworks interopérables se développe et que la concurrence s’intensifie. Quel est le problème de cette croissance ? La fragmentation. Des frameworks concurrents fragmenteront les actifs et la liquidité, et nous ne verrons pas de solution universelle. Ce n’est pas faisable compte tenu de la structure des incitations.

Lien d'origine

Cet article provient d'Internet : Analyse approfondie : quelle émission de pièces inter-chaînes est la meilleure ?

En relation : Rapport d'observation du marché XEX : Un examen des événements majeurs récents dans l'espace des crypto-monnaies

Le président français Emmanuel Macron a démenti les rumeurs selon lesquelles l'arrestation du fondateur de Telegram, Pavel Durov, était motivée par des raisons politiques, tandis que les flux de cryptomonnaies ont augmenté pendant cinq semaines consécutives au milieu des rumeurs d'une baisse des taux en septembre aux États-Unis. Parallèlement, Polygon, Avalanche et ZKsync ont tous été touchés par des attaques d'escroquerie Discord en 48 heures. Macron affirme que l'arrestation de Durov n'est pas motivée par des raisons politiques Le président Macron a confirmé l'arrestation de Durov dans un message publié sur la plateforme de médias sociaux X le 26 août. Dans son message, Macron a répondu à de fausses informations circulant sur les réseaux sociaux affirmant que l'arrestation de Durov était motivée par des raisons politiques. Macron a déclaré qu'il ne s'agissait en aucun cas d'une décision politique. Le 24 août, Durov a été arrêté dans un aéroport près de Paris, déclenchant des rumeurs d'éventuelles accusations contre lui et des mesures des forces de l'ordre contre Telegram. Le 26 août…