cBridge 2.0 : Une plateforme universelle de pont inter-chaînes basée sur le réseau Celer State Guardian
TechFlow SélectionTechFlow Sélection
cBridge 2.0 : Une plateforme universelle de pont inter-chaînes basée sur le réseau Celer State Guardian
Ensuite, nous passerons à la deuxième phase, à savoir le mode « SGN en tant que passerelle de nœud cBridge et arbitre du contrat de niveau de service (SLA) ».
Dédié à des analyses Web3 approfondies
Depuis le lancement de cBridge 1.0, le volume total des fonds transférés via notre pont inter-chaînes a connu une croissance hebdomadaire exponentielle. Le premier mois, nous avons traité seulement 10 millions de dollars de transferts inter-chaînes ; dès le mois suivant, ce montant est passé à 170 millions de dollars, avec un volume quotidien régulièrement supérieur à 10 millions. Les fournisseurs de liquidités (LP) opérant des nœuds cBridge ont obtenu, sans aucune incitation supplémentaire, un rendement annuel de 45 % uniquement grâce aux frais de transfert inter-chaînes. C’est déjà impressionnant, mais ce n’est qu’un début.
Nous sommes heureux d'annoncer aujourd'hui le plan de mise à niveau vers cBridge 2.0 et d'en présenter brièvement les innovations clés.
L’architecture technique de cBridge 2.0 offrira la meilleure expérience de transaction inter-chaînes disponible sur le marché actuel. Elle permettra aux utilisateurs d’accéder à une profondeur de liquidité accrue, aux nœuds cBridge et aux fournisseurs de liquidités (LP) qui ne souhaitent pas exécuter de nœud de bénéficier d’une gestion de liquidité plus efficace et simple, et aux développeurs de disposer d'une fonctionnalité de messagerie inter-chaînes généralisée pour soutenir des applications avancées telles que les NFT inter-chaînes ou les DEX inter-chaînes. Toutes ces fonctionnalités reposent sur une mise à jour du réseau State Guardian Network (SGN), piloté par le staking de CELR, renforçant ainsi davantage la capture de valeur du réseau SGN.
Résumé de cet article : en quoi cBridge 2.0 constitue-t-il une amélioration ?
Pour les lecteurs moins intéressés par les détails techniques, voici un résumé des améliorations et avantages apportés par cBridge 2.0.
Pour les utilisateurs :
- Meilleure profondeur de liquidité : prise en charge de transferts inter-chaînes plus importants.
- Procédure d’utilisation simplifiée : fonction de transfert en un seul clic.
- Prise en charge du transfert vers le jeton natif de frais (gas token) : par exemple, le WETH sur BSC peut être directement converti en ETH natif sur Arbitrum pour payer les frais de transaction sur Arbitrum.
- Extension et prise en charge multi-chaînes et multi-jetons.
- Mécanisme de garantie de qualité de service des nœuds du pont : pour les utilisateurs choisissant un nœud de pontage, un nouveau système d’assurance qualité de service est introduit. Nous pénaliserons les nœuds déconnectés et indemniserons les utilisateurs affectés.
Pour les fournisseurs de liquidités (LP) et les nœuds cBridge :
- Fournir de la liquidité sans exécuter de nœud : dans cBridge 1.0, la seule façon de fournir de la liquidité était d'exécuter un nœud cBridge. Dans la version 2.0, nous introduisons un nouveau mode où le SGN lui-même agit comme un nœud cBridge. Les LP peuvent déléguer leur liquidité au nœud géré conjointement par le SGN et percevoir les frais de transfert inter-chaînes sans avoir à exécuter personnellement un nœud cBridge.
- Expérience optimale de gestion de liquidité : contrairement à d'autres solutions inter-chaînes, les LP de cBridge 2.0 n'ont pas besoin de créer de jetons synthétiques, ni de rejoindre forcément un pool AMM volatil, ni de subir de pertes permanentes élevées. Ils fournissent simplement un jeton unique et peuvent gérer librement la répartition de leur liquidité pour réaliser des arbitrages.
- Efficacité maximale de la liquidité : contrairement aux autres solutions, cBridge 2.0 n’exige pas de verrouillage double de liquidité, augmentant ainsi la valeur unitaire et l’efficacité de la liquidité, et maximisant les gains des LP.
- Conception équilibrée de la reconstitution de liquidité : grâce à une gestion commune via le SGN, cBridge 2.0 supporte et génère des courbes AMM asymétriques optimales selon l’offre et la demande, incitant les arbitragistes et LP à maintenir une liquidité suffisante et symétrique au sein du réseau.
- Ordonnancement optimal des nœuds cBridge auto-gérés : pour les LP qui choisissent d'exécuter et gérer eux-mêmes leurs nœuds, le SGN assure un routage optimisé centré sur l’expérience utilisateur.
Pour les utilisateurs ayant misé du CELR dans le SGN et les nœuds validateurs :
- Capture de valeur : les participants au staking dans le SGN fournissent un service indispensable à cBridge 2.0. Ils captent directement la valeur du réseau via les frais de transfert inter-chaînes et les récompenses de minage de liquidité.
- Gouvernance du protocole : les paramètres systèmes tels que les courbes de prix ou les taux de frais sont gérés de manière décentralisée par un protocole basé sur le staking de CELR.
Pour les développeurs :
- SDK blanc personnalisable : permet aux dApps multi-chaînes d’intégrer facilement les fonctions de cBridge localement, afin que les utilisateurs puissent effectuer des transferts inter-chaînes directement depuis l’interface de l’application.
- Fonctionnalité de messagerie inter-chaînes pour prendre en charge des cas d’usage comme les NFT inter-chaînes : permet aux développeurs de concevoir des applications plus complexes que le simple transfert d’actifs, telles que les NFT inter-chaînes ou les DEX inter-chaînes.
Comment donc cBridge 2.0 parvient-il à implémenter toutes ces nouvelles fonctionnalités ?
Réponse : le réseau State Guardian Network (SGN) de Celer.
Dans cBridge 2.0, nous étendons les capacités du SGN pour supporter deux modes de pontage différents, répondant ainsi aux préférences variées des utilisateurs et LP. Ce document présente l’architecture globale du système.
Retour sur le réseau State Guardian
Le réseau State Guardian Network (SGN) est un composant central de l’architecture globale de Celer. Il s’agit d’une chaîne PoS spéciale, chargée de surveiller les événements L1 liés aux états L2, et de transmettre fidèlement les informations de la couche 2 vers la couche 1 lorsque nécessaire.
Dans les canaux d’état Celer, le SGN aide à stocker l’état des canaux et intervient en cas de tentative de règlement malveillante sur L1. Dans la chaîne rollup layer2.finance de Celer, le SGN s’étend en un réseau décentralisé de production de blocs, relayant les données d’appel (call data) et les racines d’état vers L1. Même en cas de défaillance du consensus PoS, tout nœud SGN peut soumettre une preuve de fraude (fraud-proof) sur la chaîne pour assurer la sécurité du système.
Les détenteurs de CELR peuvent participer en devenant validateurs SGN ou en déléguant leur CELR au sein du SGN. En échange, ils perçoivent des récompenses de staking et des frais pour les services fournis.
Le SGN en tant que passerelle des nœuds cBridge et arbitre des accords de niveau de service (SLA)
Choix architecturaux et limites de cBridge 1.0
Dans cBridge 1.0, lorsqu’un nœud rejoint le réseau, il s’enregistre auprès d’un service passerelle en fournissant diverses informations telles que sa grille tarifaire et son état de liquidité. Cette passerelle surveille continuellement l’état et les performances du nœud. Lorsqu’une requête utilisateur est envoyée, elle est dirigée vers cette passerelle, qui évalue les nœuds inscrits selon plusieurs critères (liquidité disponible, taux de succès historique, frais, etc.) et recommande ensuite le nœud de pontage le plus adapté. Dans la version 1.0, nous avons choisi une passerelle centralisée afin d’acquérir rapidement de l’expérience opérationnelle sur les stratégies de routage.
La passerelle 1.0 fournit aux utilisateurs des recommandations « à titre indicatif » quant au choix d’un nœud cBridge particulier.
Bien que cBridge 1.0 soit construit sur une architecture non détentrice (non-custodial), où les utilisateurs n’ont jamais à faire confiance aux nœuds pour la sécurité de leurs fonds, des problèmes d’expérience utilisateur liés à la « disponibilité des nœuds » subsistent. Par exemple, si un utilisateur envoie une transaction conditionnelle (première étape HTLC) à un nœud qui se déconnecte avant la fin du transfert HTLC en deux étapes, l’utilisateur doit attendre l’expiration du délai, sans que le nœud inactif ne soit pénalisé ni que l’utilisateur reçoive une compensation.
Ces deux limitations sont résolues dans la version 2.0 grâce au SGN.
Ordonnancement décentralisé et efficace des nœuds cBridge via le SGN
Dans cBridge 2.0, nous migrons d’abord toute la logique de la passerelle centralisée vers le SGN distribué. Les nœuds cBridge s’enregistrent désormais directement auprès du SGN, en indiquant leurs préférences tarifaires, leur disponibilité en liquidités, etc., au lieu de passer par un service centralisé.
Lorsqu’un utilisateur lance une requête, le flux normal du système est le suivant :
- L'utilisateur interroge l'état actuel du SGN pour obtenir une estimation des frais et de la disponibilité de liquidité.
- Si les frais estimés sont acceptables, l'utilisateur envoie la première partie du transfert HTLC en spécifiant sa tolérance maximale aux frais.
- Le SGN surveille et reçoit la transaction. Selon les règles d’ordonnancement, il attribue un ou plusieurs nœuds cBridge inscrits à cette transaction. Cette attribution est enregistrée sur la chaîne SGN et marquée dans le transfert HTLC de l’utilisateur.
- Le(s) nœud(s) désigné(s) accepte(nt) l’attribution et répond(ent) en complétant la deuxième partie du transfert conditionnel.
- Le SGN continue de surveiller et suivre la transaction. Une fois celle-ci terminée avec succès, les états associés sont effacés de la chaîne SGN.
Grâce à cela, le nombre de nœuds cBridge peut croître de manière plus évolutive, tout en assurant un processus de sélection équitable et consensuel. Mais les bénéfices de cette migration vers le SGN vont au-delà.
Garantie SLA des nœuds du pont et mécanisme de confiscation
Contrairement à la passerelle 1.0, dans l’architecture où le SGN fait office de couche d’ordonnancement (passerelle), celui-ci surveille l’intégralité du processus de transfert inter-chaînes. En tant que chaîne PoS décentralisée, le SGN peut désormais aller au-delà de simples « recommandations indicatives » : il peut sanctionner les nœuds cBridge qui ne remplissent pas leur transfert alloué « conformément à leurs engagements ».
Lorsqu’un nœud cBridge s’enregistre auprès du SGN, il peut déposer dans un contrat-piscine une « garantie SLA » (un ensemble de jetons ayant de la valeur) liée à certaines promesses de niveau de service (SLA), telles que disponibilité, niveau de frais ou réserve de liquidité. Si le SGN constate qu’un nœud viole son SLA — par exemple en se déconnectant sans achever le transfert — il peut alors confisquer sa garantie, en guise de compensation pour la dégradation de l’expérience utilisateur et le coût d’opportunité de la liquidité bloquée. (Notez qu’il n’y a jamais de risque de perte des fonds utilisateur ; cette compensation concerne uniquement les coûts d’opportunité dus au blocage temporaire des fonds.)
Durant le processus de sélection des nœuds, la valeur disponible de la garantie SLA devient un facteur clé de priorité. Les nœuds honnêtes et fiables ont un fort incitant à miser une garantie pour augmenter leurs chances d’être sélectionnés. À l’inverse, les nœuds peu fiables seront progressivement exclus ou relégués au dernier rang.
Grâce à la fonction de garantie SLA soutenue par la « passerelle SGN » décentralisée, les nœuds du pont peuvent opérer selon des SLA de haute qualité. Cela vise à fournir un réseau sain, en croissance rapide et décentralisé de nœuds cBridge pour les fournisseurs de liquidités souhaitant conserver une « liquidité auto-détenue ».
Certains pourraient objecter que, puisqu’un consensus PoS peut théoriquement échouer, la garantie SLA pourrait être injustement confisquée, rendant ainsi ce modèle imparfaitement auto-détenu.
Nous soulignons que la garantie SLA ne représente qu’une petite fraction de la liquidité totale, mais suffit largement à assurer une expérience fluide et un écosystème de nœuds auto-réparateur. Ce compromis est hautement justifié. Plus important encore, du point de vue de l’utilisateur, l’ensemble du processus inter-chaînes reste strictement « non dépositaire », sans aucun risque financier.
Règles d’ordonnancement des nœuds
Le principe de conception des règles d’ordonnancement est d’optimiser l’expérience utilisateur. Nous avons élaboré une formule empirique de « score de qualité du nœud », intégrant plusieurs facteurs tels que les paramètres SLA du nœud (frais, temps de réponse) et ses performances historiques (taux de réussite, temps de réponse moyen). Lors de la sélection d’un nœud pour une requête, nous hiérarchisons les nœuds selon ce score. Nous espérons que cette formule sera itérée et optimisée au fil du temps par gouvernance du protocole, basée sur l’expérience opérationnelle.
Comparé au protocole nxtp récemment lancé par Connext — également non dépositaire — cBridge offre une interaction utilisateur plus simple, une latence inférieure, des coûts moindres, sans nécessiter de procédure complexe d’enchères entre nœuds multiples, tout en garantissant effectivement le niveau de service et protégeant les intérêts des utilisateurs.
Le SGN en tant que gestionnaire de pools de liquidité partagés
Fournir de la liquidité sans exécuter de nœud cBridge
Les améliorations décrites précédemment concernent principalement les LP auto-gérés capables d’exécuter un nœud cBridge. Toutefois, nous reconnaissons qu’un grand nombre de LP et d’utilisateurs souhaitent fournir de la liquidité sans exécuter personnellement de nœud, et qui ont confiance dans le niveau de sécurité offert par le consensus PoS du SGN et le staking de CELR. De plus, un modèle de pool de liquidité partagé permet de démarrer rapidement la liquidité du réseau, favorisant ainsi une meilleure expérience utilisateur dès le départ.
Par conséquent, dans cBridge 2.0, nous introduisons un nouveau mode opératoire : le SGN gère collectivement les contrats de pools de liquidité partagés sur plusieurs chaînes. En d’autres termes, le SGN — chaîne PoS distribuée — et ses pools de liquidité forment ensemble un « nœud » unique. Cela donne aux LP la possibilité de déléguer facilement leur liquidité au SGN, percevoir les frais de transfert inter-chaînes, sans avoir à exécuter de nœud.
Quelles garanties de sécurité ce modèle offre-t-il ?
Sécurité de niveau PoS et gouvernance décentralisée
Dans ce mode de cBridge 2.0, les contrats de pools de liquidité partagés sont gérés par le consensus PoS du SGN. Tout transfert de fonds depuis le pool nécessite une signature multichaine pondérée par le staking de CELR. Seulement si plus des deux tiers des nœuds valides deviennent malveillants, les fonds du pool seraient menacés. Soulignons que, à mesure que le volume des transactions inter-chaînes augmente et que la valeur totale verrouillée dans le réseau croît, toute tentative malveillante devient naturellement plus difficile et coûteuse. Ceci diffère fondamentalement des solutions utilisant le TSS (signature seuil), car le TSS n’est pas lié à un staking de jeton, et donc sa sécurité ne s’intensifie pas avec la valeur du réseau.
Le modèle de gouvernance des validateurs dans le SGN est ouvert et décentralisé : de nouveaux validateurs peuvent être élus et intégrés à l’ensemble des validateurs via le processus de staking, sans coordination particulière.
Expérience simple pour les fournisseurs de liquidités (LP) et efficacité élevée de la liquidité
Comment les LP gèrent-ils leur liquidité dans ce modèle ? Des solutions existantes comme Hop Protocol ou Thorchain obligent les LP à placer leur liquidité en jeton avec un autre jeton de règlement contrôlé par le protocole dans un pool AMM sur chaîne. Ce modèle présente plusieurs inconvénients :
- Thorchain exige que les LP utilisent RUNE, un jeton de règlement très volatile, entraînant inévitablement de fortes pertes permanentes.
- Même dans les cas où des jetons de liquidité natifs sont utilisés pour frapper des jetons synthétiques, les LP font face à une complexité opérationnelle importante lorsqu’ils ajoutent, retirent ou rééquilibrent leur liquidité sur plusieurs chaînes.
- Hop Protocol, dans son modèle nécessitant un « bonder » fournissant de la liquidité, souffre d’une faible efficacité : la liquidité effective requise pour tout transfert est le double de la liquidité nécessaire.
cBridge 2.0 résout intelligemment le « problème d’attribution de la liquidité » par une conception novatrice, offrant une expérience LP simple et une efficacité maximale de la liquidité. Pour mieux comprendre notre conception, expliquons d’abord ce qu’est l’« attribution de la liquidité ». Dans tout système de pont multi-chaînes, lorsque l’utilisateur envoie des fonds de la chaîne source vers la chaîne cible, le LP (ou le pool agrégé) paie l’utilisateur sur la chaîne cible tout en recevant les fonds sur la chaîne source. Supposons qu’un LP fournisse de la liquidité sur la chaîne A. Quand un utilisateur envoie des fonds de la chaîne B vers la chaîne A, la liquidité du LP est essentiellement « réaffectée » : elle diminue sur A et augmente sur B. Le problème d’attribution de la liquidité consiste à savoir comment le système informe chaque LP de l’emplacement de sa liquidité, et comment gérer efficacement celle-ci pour optimiser le rendement des frais.
Les solutions basées sur des pools AMM suivent implicitement la liquidité des LP en répartissant des jetons de règlement et des jetons natifs dans le pool AMM. La structure du pont (TSS validateurs ou protocole de messagerie L2-L1) gère uniquement la création et la destruction du jeton de règlement. L’utilisateur doit toujours payer des frais pour échanger le jeton de règlement contre le jeton natif sur la chaîne cible, parfois même sur la chaîne source. En cas de déséquilibre de liquidité, il devient rentable de transférer de la liquidité d’une chaîne saturée vers une chaîne déficitaire pour profiter des écarts de prix. Les arbitragistes auront alors intérêt à envoyer des fonds de la chaîne déficitaire vers la chaîne saturée pour rééquilibrer.
Les LP ont encore plus d’incitations à équilibrer, car ils n’ont pas à payer de frais de pont pour profiter de ces arbitrages. Toutefois, leur processus de rééquilibrage est complexe. Par exemple, notons S la chaîne déficitaire et A la chaîne saturée. Un LP devrait alors :
- Retirer sa liquidité du pool AMM sur S.
- Transférer le jeton de règlement de S vers A.
- Vendre le jeton de règlement avec une prime sur le pool AMM de A pour récupérer le jeton natif.
- Rapporter le jeton natif sur S.
- Acheter le jeton de règlement sur S.
- Réinjecter la liquidité dans le pool AMM sur S.
Ces étapes entraînent des coûts opérationnels, transactionnels et temporels significatifs.
Dans cBridge 2.0, nous considérons que la structure du pont (ici le SGN) peut être hautement optimisée, réduisant fondamentalement les coûts par rapport aux opérations sur contrats intelligents. Ainsi, la liquidité de chaque LP est explicitement tracée. Ajouter de la liquidité est extrêmement simple : une seule transaction pour ajouter un jeton natif au contrat de pool, et le SGN enregistre la quantité de liquidité de chaque LP dans son état de chaîne. En substance, le SGN maintient une table (chain_id, adresse_LP, type_jeton, solde).
Lors du traitement d’une requête de transfert inter-chaînes, le SGN utilise la liquidité totale du pool pour calculer le glissement et le prix (détaillé dans la section suivante), puis traite les LP comme des « nœuds cBridge virtuels » et répartit la requête selon leur allocation de liquidité. Conceptuellement, pour chaque transfert, le solde de liquidité d’un LP sur la chaîne cible diminue proportionnellement à sa liquidité disponible, tandis que son solde sur la chaîne source augmente. En pratique, nous utilisons des méthodes comme l’échantillonnage aléatoire et des algorithmes approximatifs pour minimiser les changements d’état et les coûts, tout en conservant une équité statistique entre les LP. Ces détails sont approfondis dans notre documentation technique.
Cette architecture s’applique aussi à l’équilibrage par arbitrage, tout en offrant aux LP une flexibilité maximale dans la gestion de leur liquidité. Chaque LP voit clairement la répartition de sa liquidité à tout instant, ce qui leur permet de prendre des décisions éclairées lorsqu’ils ajoutent ou retirent de la liquidité sur une chaîne donnée. Ce processus passe ainsi de 6 étapes à 3, sans frais d’échange AMM :
- Le LP retire directement la liquidité en jeton natif sur A. Grâce au glissement du système, il verrouille immédiatement le gain d’arbitrage.
- Le LP transfère le jeton natif de A vers S.
- Le LP ajoute le jeton natif au pool sur S.
Un LP peut toujours retirer toute sa liquidité d’une chaîne ou d’un groupe spécifique de chaînes. Dans cBridge 2.0, cela se fait en déclenchant un transfert inter-chaînes interne, en traitant le LP comme un utilisateur pour transférer sa liquidité vers la chaîne souhaitée, puis retirer la liquidité. Notez que dans ce cas, le LP supporte le glissement du système. Toutefois, cela revient à peu près au même coût que l’échange du jeton de règlement sur une solution AMM, voire moins cher.
Plus important encore, dans cBridge 2.0, les LP utilisent directement des jetons natifs, évitant ainsi de lourdes pertes permanentes. Comparé à Hop Protocol, cBridge n’exige aucun verrouillage supplémentaire de liquidité « bonder », atteignant ainsi l’efficacité maximale de la liquidité et un rendement optimal des frais.
Tarification inter-chaînes pour inciter à une liquidité équilibrée
Dans un système de pont inter-chaînes, la liquidité d’un même jeton natif existe sur plusieurs chaînes. Avec les variations de demande entre chaînes, la valorisation intrinsèque de ce jeton fluctue dynamiquement selon les coûts potentiels de transfert via les ponts natifs et l’équilibre offre-demande de liquidité sur chaque chaîne.
Pour toute solution de pont, il est crucial de capturer ces variations de prix par une courbe d’agrégation (bonding curve) bien conçue. Cela crée une forte incitation pour les LP à rééquilibrer la liquidité entre chaînes selon les économies d’échelle, maintenant ainsi un réseau doté d’une liquidité suffisante et équilibrée pour traiter toutes les demandes utilisateur.
Fidèle à notre principe de « conception intelligente », nous avons intégré dans le SGN un mécanisme de tarification inspiré des AMM stables de Curve. Lorsqu’un utilisateur transfère un jeton d’une chaîne à une autre, le SGN calcule la quantité reçue selon la liquidité disponible sur les chaînes source et cible. Outre le prix, des frais fixes sont prélevés sur la transaction et reversés aux LP.
Plus précisément, pour toute paire de chaînes i et j, notons xi et Xj les soldes respectifs du jeton donné sur les chaînes i et j. Lors du calcul du glissement pour un transfert entre ces chaînes, l’invariant suivant doit toujours être respecté :
- A est une constante propre à chaque paire de chaînes. Pour une paire donnée, A est identique pour tous les jetons.
- D est une variable. La valeur initiale de D peut être obtenue en résolvant une équation cubique à partir des liquidités initiales sur les deux chaînes. Ensuite, D doit être mis à jour itérativement selon l’état de liquidité.
- Wi et Wj sont les poids relatifs des deux chaînes, contrôlant l’asymétrie du glissement. Notez que la configuration des poids est spécifique à chaque paire de chaînes et doit satisfaire Wi + Wj = 2.
Nous utilisons ces paramètres de poids dans la courbe d’agrégation pour refléter les asymétries intrinsèques de certaines chaînes. Par exemple, entrer sur Arbitrum ou Optimism (rollups) est beaucoup plus simple et moins coûteux que d’en sortir, ce qui prend jusqu’à 7 jours. Nous pouvons donc ajuster les poids dans la courbe pour tenir compte de ces différences inhérentes.
Sur la courbe rouge asymétrique ci-dessus (avec une ligne de référence bleue symétrique), on observe que, lors d’un déséquilibre, un transfert de la chaîne i vers j subit un glissement accru. Si Wi = 1 et Wj = 1, la courbe se ramène à celle utilisée par Curve Finance.
Messagerie inter-chaînes généralisée
cBridge 2.0 crée une infrastructure intelligente inter-chaînes basée sur le SGN. Cette structure va au-delà du simple transfert d’actifs : c’est un cadre généralisé de messagerie inter-chaînes, où le SGN surveille les événements sur la chaîne source et publie sur la chaîne cible un certificat de consensus attestant de ces événements, réalisant ainsi le transfert d’information.
Nous ouvrirons progressivement cette fonctionnalité aux développeurs sous forme de SDK, pour construire non seulement des ponts, mais aussi d’autres cas d’usage comme les NFT inter-chaînes ou l’agrégation DeFi inter-chaînes.
Capture de valeur du réseau
Contrairement à de nombreux jetons de gouvernance (où les détenteurs n’assument pas de fonctions quotidiennes du protocole), il est clair que les détenteurs de CEL
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
