Comment transférer des USDT de Tron à EVM sans être piégé par la liquidité ?

2 avril 2026 15 minutes de lecture

Si vous avez fréquenté DeFi suffisamment longtemps, l'exploit CrossCurve ne vous a probablement pas surpris. Le 1er février 2026, CrossCurve a été victime d'un incident de chaîne croisée qui a entraîné une perte d'environ $3M de pertes. Pour nous, il ne s'agit pas d'une simple “nouvelle du marché”. Il s'agit d'un contrôle de qualité obligatoire avant toute intégration d'un partenaire. Nous sommes responsables à la fois de notre propre architecture et de la sécurité de nos clients. C'est pourquoi, parallèlement aux mises à jour publiques de CrossCurve, nous avons examiné les détails de l'incident et évalué comment la cause première pourrait (ou ne pourrait pas) avoir un impact sur nos intégrations planifiées.

Le contexte de cet article

Qu'est-il arrivé exactement à CrossCurve ? Sans entrer inutilement dans la terminologie, il ne s'agissait pas d'un piratage de la blockchain, mais d'une modèle de conception non intuitif provenant du SDK Axelar GMP (v5.10.0) qui peut échapper aux audits professionnels si le risque n'est pas explicitement compris. Le contrat ReceiverAxelar lui-même avait été audité et vérifié sur la chaîne, mais la vulnérabilité se trouvait plus profondément dans un chemin d'exécution accéléré pour les messages inter-chaînes, où une opération critique pouvait être déclenchée sans validation complète de la source via la passerelle. Dans le cas spécifique de CrossCurve, la situation était encore amplifiée par une configuration de seuil de confirmation faible (seuil = 1), qui réduisait la robustesse globale du modèle de validation.

Cet incident est également un signal plus large pour les intégrateurs Axelar : en suivant les exemples officiels et en héritant des contrats d'exécution “express”, les projets peuvent involontairement exposer une surface d'attaque dangereuse, même si le reste du code est correct et semble prêt pour la production. Un autre point important est que le risque ne disparaît pas de lui-même lors de la mise à jour : même les versions plus récentes du SDK contiennent des modèles similaires, et si les équipes migrent sans reconnaître le problème architectural, elles peuvent reporter le risque sur l'avenir. En pratique, la conclusion est simple : tout chemin d'exécution rapide doit être soit strictement restreint, soit renforcé par de solides contrôles d'origine/d'autorisation du côté de l'intégrateur ; sinon, la mécanique de style express peut devenir un contournement de vos propres hypothèses de sécurité.

En même temps, notre position sur CrossCurve reste positive et, ironiquement, la complexité de leur architecture fait que cet incident est moins un scénario universel et reproductible qu'il n'y paraît à première vue. L'exploit reposait sur un modèle spécifique de messagerie/exécution (un choix de conception particulier du SDK), alors que la solution vers laquelle CrossCurve s'oriente actuellement - et celle que nous envisageons dans nos propres produits pour les transferts sécurisés d'actifs entre chaînes - ne dépend pas de ce lien vulnérable. Pour cette raison, même si nous avions déjà été intégrés à CrossCurve au moment de l'incident, ce vecteur d'attaque exact n'aurait pas eu d'impact sur notre architecture, Le système d'évaluation de la confiance et des points de validation est structuré différemment et ne s'appuie pas sur le même chemin d'exécution express.

Enfin, la mise à jour officielle de CrossCurve, publiée le 13 février 2026, a effectivement confirmé les conclusions auxquelles notre équipe était parvenue de manière indépendante. Ils restaurent le système par étapes, en commençant par les composants qui n'ont pas été affectés (l'agrégateur est déjà opérationnel, avec un routage via Rubic et Bungee), puis en réactivant le Token Bridge et le Consensus Bridge avec des mesures de sécurité supplémentaires. Ils ont notamment déclaré que le Consensus Bridge ne sera opérationnel qu'après avoir effectué des contrôles de sécurité renforcés. Ceci “ne restaurer que ce qui est vérifié avec certitude, et durcir avant la réactivation”.” s'aligne bien sur la façon dont nous évaluons la maturité du protocole du partenaire avant l'intégration.

C'est exactement la raison pour laquelle déplacer des USDT de Tron vers des réseaux EVM n'est pas aussi simple que de brancher un pont et de s'arrêter là. Tron est l'endroit où une grande quantité d'USDT se déplace réellement : les frais étaient bon marché (ils ne le sont plus, d'où le besoin de ponts), les flux sont familiers et les volumes sont réels. Ainsi, lorsque vous dites “nous avons besoin de liquidités sur Tron”, la vraie question est de savoir où se trouve l'argent, qui est autorisé à le déplacer et ce qui se passe lorsqu'une hypothèse s'avère erronée.

Cet article a pour but de ralentir la conversation dans le bon sens du terme. Je vais vous présenter les principales façons dont l'USDT passe de Tron aux réseaux EVM, comment ces approches se comportent lorsque le volume réel arrive, puis je prendrai du recul pour poser la seule question qui compte vraiment : quels risques êtes-vous réellement prêt à prendre ?.

Obtenez un examen rapide du cheminement de votre message à travers la chaîne

Définir le cadre : Tron, la liquidité et les vrais compromis

À ce stade, la question est de savoir comment l'USDT passe réellement de Tron à un réseau EVM, et ce que vous supposez lorsque vous choisissez une voie plutôt qu'une autre.

La plupart des discussions restent bloquées au niveau du protocole, mais ce n'est pas le cas ici. Avant de nommer des solutions spécifiques, je tiens à être explicite sur les dimensions qui comptent réellement dès qu'un volume réel est impliqué. Dans la pratique, chaque conception de chaîne croisée finit par faire des compromis le long des mêmes axe, même si le langage marketing diffère.

Le premier est liquidité. Certains modèles exigent que le capital soit prépositionné de part et d'autre. D'autres l'évitent totalement mais introduisent différentes formes de confiance. La seconde est identité des actifs. Parfois, les utilisateurs reçoivent ce que tout le monde s'accorde à appeler “les” USDT. Parfois, ce n'est pas le cas, et cette distinction a de réels effets en aval sur DeFi. Ensuite, il y a comportement du coût sous charge, finalité vitesse, hypothèses de sécurité, effort d'intégration, et la dépendance à l'égard de la feuille de route de quelqu'un d'autre.

Si l'on aligne ces dimensions, l'espace de conception se réduit à quatre grandes approches. Il ne s'agit pas de variantes de la même chose, car elles résolvent des problèmes différents et échouent de manières différentes. Le tableau ci-dessous donne une orientation rapide.

Une carte rapide des quatre approches

ApprocheOù vivent les liquiditésType d'actifUX à volume réelRisque primaire
Ponts / piscines LPPréfinancement des deux côtésUSDT natifBon jusqu'à la vidange des piscinesÉpuisement des liquidités, déséquilibre
Lock-mint / burn-unlockVerrouillé sur TronPonté / enveloppéPrévisibleConfiance, fragmentation
Exécution basée sur l'intentionAvec les solveurs / MMDépend de l'itinéraireTrès bien si les résolveurs restentSortie du solveur, tarification
Entrée hybrideChaînes liquides externesCanonical-by-designStable si le routage est maintenuMessagerie, agrégation

Il est important de noter qu'aucune de ces approches n'élimine le risque ; elles ne font que le redistribuer. Certaines concentrent le risque dans l'approvisionnement en liquidités, tandis que d'autres le font porter sur la confiance, la logique d'exécution ou les opérateurs externes. Une fois que cela est clair, le reste de la discussion devient beaucoup plus simple.

Dans ce cadre, nous pouvons maintenant examiner chaque approche en détail et voir ce que vous obtenez réellement, et ce que vous assumez tranquillement, lorsque vous la choisissez.

Approche #1. Ponts LP et pools de liquidités natifs

Le modèle est simple. Un utilisateur dépose des USDT dans un pool sur Tron et reçoit des USDT d'un pool correspondant sur la chaîne EVM cible. Idéalement, aucun jeton enveloppé ou synthétique n'apparaît. Le même actif se déplace d'une chaîne à l'autre, mais il faut de la liquidité “ici et là” pour que cela soit possible.

Du point de vue de l'utilisateur, cela s'apparente souvent à un transfert direct. Le pont ne crée pas un nouvel actif. Il redistribue les liquidités existantes entre des pools déployés sur différents réseaux.

Illustration d'un pont entre chaînes où les USDT passent de Tron à une chaîne EVM par le biais de liquidités mises en commun et de relais de messagerie.

Pour

Lorsque les bridges LP sont correctement mis en place, ils offrent plusieurs avantages indéniables.

  • L'interface utilisateur est généralement très bonne. Les transferts sont rapides, les flux sont faciles à comprendre et les utilisateurs ont l'impression d'avoir obtenu le même bien de l'autre côté.
  • Pas de fragmentation de la liquidité au niveau des actifs. Il n'y a pas de prolifération de “différentes versions de l'USDT”, ce qui simplifie les intégrations DeFi sur les EVM.
  • Une économie transparente pour les fournisseurs de liquidités. Les frais se comportent “comme sur un pool DEX”, ce qui rend les rendements plus faciles à expliquer et à raisonner.

Cons

Le principal inconvénient est la liquidité. Les ponts LP nécessitent des liquidités d'amorçage, parfois de l'ordre de plusieurs millions d'euros.. Sans cela, les transferts importants “mangeront le pool”, ce qui conduira soit à des limites strictes, soit à une forte augmentation des frais et des dérapages. Cette contrainte s'applique quel que soit le réseau EVM du côté récepteur.

Il existe également un dépendance critique à l'égard de l'infrastructure de messagerie. Les ponts de ce type s'appuient sur la messagerie inter-chaînes pour coordonner les mises en commun, et la plupart des solutions prêtes à l'emploi s'intègrent aux principaux fournisseurs de messagerie. En pratique, cela signifie que

  • l'intégration d'un protocole de messagerie de premier plan,
  • payer des coûts d'intégration qui s'élèvent généralement à de $250k à $500k en fonction de l'urgence,
  • dans des files d'attente d'intégration qui peuvent durer jusqu'à six mois.

À ce moment-là, il ne s'agit plus de “raccorder un pont”. Il s'agit du lancement et de l'entretien d'un marché de la liquidité.

Risques

Les ponts LP comportent simultanément plusieurs niveaux de risque.

  • Risque lié aux contrats intelligents et risque lié à l'infrastructure de messagerie ou de relais. Des défaillances dans le traitement des contrats ou des messages peuvent bloquer les fonds ou les débloquer de manière incorrecte.
  • Scénarios de faillite bancaire en cas de déséquilibre et de panique. Si l'écoulement penche fortement dans une direction, les piscines peuvent se vider plus rapidement qu'elles ne peuvent se rétablir.
  • Risque de conformité de Stablecoin. La mise sur liste noire ou en pause par un émetteur s'applique à toutes les approches, mais dans les passerelles basées sur les pools, elle est particulièrement visible car les pools représentent une cible claire et concentrée.

De récents incidents entre chaînes ont montré comment des défaillances dans la validation des messages peuvent se répercuter en cascade sur les réseaux. Bien que ces incidents n'aient pas nécessairement impliqué des pools LP, ils soulignent que le traitement correct des messages se trouve également sur le chemin critique des ponts basés sur des pools.

Exemples du monde réel et ce qu'ils impliquent

Allbridge Core (messagerie à l'intérieur d'Allbridge)
Allbridge se présente comme un échange de stablecoins entre chaînes construit autour du modèle du pool, avec des frais distribués en faveur des fournisseurs de liquidités. Les documents publics soulignent que la sécurité ne repose pas sur un seul contrôle, mais sur de multiples pratiques et couches de contrôle. Les communications publiques décrivent également une répartition des frais selon la formule suivante : “80% pour les LPs et 20% pour le trésor”.

Porte des étoiles / écosystème LayerZero (messagerie via LayerZero)
Stargate traite historiquement les pools unifiés et les dynamiques de déséquilibre en ajustant les frais en fonction de la direction du flux. Dans le même temps, l'écosystème a évolué vers une “distribution officielle sur l'ensemble de la chaîne” des stablecoins, avec notamment l'émergence de l'USDT0 en tant qu'actif OFT dans le cadre de la norme LayerZero.

La documentation de LayerZero mentionne explicitement que l'USDT0 est compatible avec l'OFT. Dans les descriptions publiques, le lancement de l'USDT0 suit le modèle “lock on Ethereum, mint on target networks”.

Cette nuance est importante. Elle montre que Dans la pratique, la logique LP et la logique lock-and-mint se confondent souvent. Dans certains cas, la “nativité” ne provient pas des pools, mais de la création, au niveau de l'émetteur ou de l'infrastructure, d'un actif omnichain canonique.

Celer cBridge / État de symbiose (messagerie et validation via le réseau Guardian)
Ces solutions offrent généralement une large couverture de la chaîne, mais elles reviennent à la même question sous-jacente : où se trouvent les liquidités et qui les détient ?

Pour les réseaux EVM, la réponse se réduit généralement à deux options :

  • les partenaires ou les investisseurs injectent des liquidités dans les pools,
  • ou le système accepte des limites en termes de volume et de qualité des itinéraires.

La question récurrente de savoir qui finance les liquidités est ce qui détermine en fin de compte jusqu'où les ponts LP peuvent amener un écosystème EVM.

Obtenez une note de risque simple sur votre configuration actuelle de pont.

Approche #2. Ponts verrouillés et minés / ponts brûlés et déverrouillés

Ce modèle suit une logique différente de celle des pools de liquidité. Sur Tron, l'actif original est bloqué. Du côté de la destination, une version “pontée” de cet actif est frappée. Lorsque les fonds reviennent, l'actif ponté est brûlé et l'actif original est déverrouillé sur Tron.

Il n'y a pas de pools qui doivent être équilibrés entre les chaînes. La capacité est déterminée par la quantité de liquidités bloquées, et non par la quantité de liquidités disponibles ailleurs. Cependant, il faut garder à l'esprit une complexité technique. Étant donné que les réseaux basés sur Tron et EVM diffèrent considérablement, la plupart des ponts de verrouillage et de monnayage s'appuient sur des technologies différentes de part et d'autre. Cela accroît la complexité de la mise en œuvre et place la barre plus haut pour un fonctionnement correct, en particulier lorsqu'il s'agit de stablecoins.

Illustration du processus de combustion et de déverrouillage, avec l'USDT verrouillé sur Tron et les jetons pontés émis sur le réseau EVM.

Avantages du modèle de pont canonique

  • Pas d'exigence de liquidité bilatérale
    • Les piscines LP ne sont pas une condition obligatoire.
    • Il n'est pas nécessaire de préfinancer les liquidités sur la chaîne de destination.
  • Capacité prévisible
    • Les transferts n'échouent pas parce qu'un pool est “épuisé”.
    • La capacité varie en fonction de la quantité verrouillée.
  • Démarrage rapide
    • Peut être lancé “à partir de zéro”, même avec un petit TVL.
    • Ne dépend pas de partenaires ou d'investisseurs qui injectent des fonds à l'avance.

Le coût des actifs emballés

Le compromis est l'identité de l'actif.

Dans presque tous les cas, un bien enveloppé ou ponté apparaît sur le réseau EVM. Cela pose plusieurs problèmes :

  • Risque de confiance et de rachat
    • Les utilisateurs doivent avoir confiance dans le bon fonctionnement du mécanisme de verrouillage et de déverrouillage.
    • Le rachat dépend du fait que le pont continue à fonctionner comme prévu.
  • Fragmentation de l“”USDT"
    • Plusieurs versions de l'USDT peuvent coexister sur le même réseau.
    • Chaque version est en concurrence pour la liquidité et l'adoption.
  • Résistance à l'adoption de DeFi
    • Les protocoles et les pools peuvent refuser de prendre en charge la “mauvaise” version.
    • Les intégrations deviennent plus sélectives et fragmentées.

Pour les stablecoins, ce problème est particulièrement aigu. Le marché préfère systématiquement la version la plus canonique d'un actif.

Profil de risque des ponts à sas

  • Risque lié au validateur, à la clé ou à l'administrateur
    • Si le pont n'est pas entièrement minimisé, le contrôle de la frappe et du déverrouillage devient une hypothèse de confiance critique.
  • Risque lié au message et à la cohérence
    • Les passerelles qui dépendent de l'orchestration ou de la messagerie asynchrone peuvent souffrir d'éventuels problèmes de cohérence.
    • Les défaillances ou les retards dans la coordination peuvent conduire à des états bloqués ou incohérents.

Les passerelles "Lock-and-Mint" éliminent la pression constante des pools de financement, mais elles la remplacent par des questions de confiance, d'identité des actifs et d'acceptation à long terme au sein des écosystèmes DeFi.

Approche #3. Exécution basée sur l'intention (solvers et market makers)

Les systèmes basés sur l'intention renversent le flux habituel. Au lieu de dire au système comment pour déplacer des actifs étape par étape, l'utilisateur déclare la fonction résultat qu'ils souhaitent. Par exemple, “Je veux des USDT sur le réseau EVM”. Les détails du routage, de l'échange et du pontage sont laissés au marché.

Les solvers sont en concurrence pour répondre à cette intention en proposant des prix. Les règles d'exécution sont appliquées au sein de la chaîne, de sorte qu'une fois que l'offre d'un solveur est acceptée, le règlement suit les conditions du protocole. L'atomicité ne provient pas d'un contrat-pont unique, mais des règles qui régissent l'appariement et l'exécution des intentions.

Visuel du modèle d'exécution basé sur l'intention montrant la demande de l'utilisateur, les devis des concurrents et le règlement en cours de chaîne sur le modèle d'exécution basé sur l'intention.

Pourquoi les intentions semblent attrayantes pour Tron

Ce modèle correspond au cas d'utilisation de Tron pour quelques raisons concrètes :

  • Vitesse : Les solvers détiennent déjà un inventaire, de sorte que l'exécution peut se faire rapidement sans attendre le rééquilibrage des pools.
  • Efficacité du capital : La liquidité n'est pas bloquée dans des pools appartenant à des protocoles. Elle appartient aux teneurs de marché qui décident comment la déployer.
  • Volonté des MM de détenir des stocks : Certains teneurs de marché sont prêts à détenir des USDT et des actifs connexes s'il existe un rendement clair ou un flux d'ordres fiable, ce qui permet d'alléger le fardeau du capital du réseau lui-même.

Là où les systèmes basés sur l'intention brillent

Lorsque la participation des résolveurs est saine, l'exécution basée sur l'intention donne de bons résultats.

  • Meilleure interface utilisateur de sa catégorie : Les utilisateurs n'effectuent qu'une seule action au lieu d'enchaîner les étapes de pontage, d'échange et de pontage.
  • Coût potentiellement le plus bas : La concurrence entre les résolveurs peut comprimer les écarts, ce qui rend les intentions moins coûteuses que les itinéraires multi-sauts.
  • Accès aux liquidités à l'échelle du réseau : La couverture augmente avec le marché des résolveurs plutôt qu'avec la liquidité détenue par le protocole, ce qui permet une expansion sans avoir à reconstruire les pools sur chaque réseau.

Là où le modèle commence à se déformer

Les propriétés qui rendent les intentions attrayantes définissent également leurs limites.

  • Dépendance du solveur : Si les résolveurs quittent l'entreprise ou réduisent leur activité, la qualité de l'exécution diminue immédiatement.
  • Risque de tarification implicite : Les coûts sont intégrés dans les devis du solveur, qui peuvent s'élargir ou devenir agressifs sur des marchés étroits.
  • Prévisibilité limitée pour les débits très importants : La fixation des prix reflète des règles comptables fixes plutôt que le comportement des teneurs de marché, ce qui explique pourquoi les modèles "mint-and-burn" restent souvent préférés pour les rails lourds.

Profil de risque des intentions

L'exécution basée sur l'intention comporte trois risques principaux. Il y a risque d'inefficacité si les résolveurs partent. Il y a risque d'intégrité des prix si les prix deviennent agressifs ou déformés dans des conditions de faible liquidité. Et il y a le risque opérationnel, Cela signifie que la qualité de l'exécution doit être surveillée et que des itinéraires de repli doivent être disponibles lorsque l'exécution de l'intention se dégrade.

Envoyez-nous votre flux d'appels et nous dresserons la carte des lacunes en matière de confiance.

Approche #4. Modèle hybride. Méta-agrégation et entrée individuelle.

Le modèle hybride part d'un principe différent de celui des modèles basés sur les piscines : ne possèdent pas de liquidités.

Au lieu d'essayer d'attirer et de maintenir des capitaux dans des pools appartenant à des protocoles, le système s'appuie sur les liquidités qui existent déjà sur de grands réseaux liquides. Le réseau EVM lui-même ne contrôle que le point d'entrée et de sortie final, et non l'ensemble de la chaîne.

Cette conception permet d'éviter la principale contrainte des passerelles basées sur les LP. Il n'y a pas de réserve locale à épuiser, car les liquidités ne sont pas concentrées dans le réseau de destination. Il n'y a pas de plafond de volume imposé par la TVL locale. Les transferts évoluent en fonction de la profondeur des marchés extérieurs, et non du montant des capitaux que le réseau a réussi à attirer.

La liquidité reste là où elle existe déjà, sur les grandes chaînes, dans les DEX établis et dans les systèmes de routage matures.

Visualisation d'un modèle hybride inter-chaînes combinant l'agrégation de routes et un pont d'entrée 1:1 pour le transfert d'USDT.

Comment cela fonctionne-t-il en pratique ? L'exemple de Haust

Haust est un réseau de couche 2 compatible avec l'EVM, construit sur des zk-rollups, avec une prise en charge native de l'abstraction de compte, de l'exécution inter-chaînes et du routage agrégé. Cela en fait un bon cas de référence pour le modèle hybride, car il traite déjà l'entrée dans la chaîne croisée comme une infrastructure, et non comme un ajout.

En pratique, le flux se présente comme suit :

  1. Sélection de la chaîne d'approvisionnement
    Haust sélectionne une ou deux chaînes EVM où la liquidité en stablecoins est déjà importante et activement acheminée. Les candidats typiques sont BNB Smart Chain, Arbitrum ou Base. Aucune tentative n'est faite pour reproduire cette liquidité au sein de Haust.
  2. Entrée individuelle dans Haust
    Un pont dédié relie chaque chaîne source sélectionnée à Haust. Le pont suit un modèle "lock-and-mint" ou un modèle équivalent "one-to-one" :
    • L'USDT est bloqué sur la chaîne source.
    • Une représentation en pont est frappée à l'intérieur de Haust.

    Cet actif est synthétique au niveau du protocole, mais traité comme canonique dans la pile DeFi de Haust.

  3. Routage agrégé en amont
    Les utilisateurs n'interagissent pas directement avec le pont. Au lieu de cela :
    • L'utilisateur entre par un agrégateur d'itinéraires à partir de n'importe quelle chaîne prise en charge,
    • L'agrégateur achemine les fonds dans la chaîne source choisie et les normalise dans le stablecoin requis,
    • Le dernier saut dans Haust s'effectue par le pont unidirectionnel.
  4. Piquage et exécution des itinéraires
    Toutes les étapes sont assemblées au niveau de la couche d'agrégation. Du point de vue de l'utilisateur, il s'agit d'un itinéraire unique. Du point de vue de Haust, seule l'entrée finale est détenue et appliquée.

La propriété clé est que la liquidité ne se trouve jamais à l'intérieur des piscines Haust. Il reste sur les grandes chaînes, les DEX et les agrégateurs. Haust contrôle l'exactitude de l'exécution à la frontière et intègre le résultat directement dans sa couche d'abstraction de portefeuille et de compte.

Présentation visuelle d'un transfert agrégé d'USDT et d'USDC, assemblé et réglé sur une couche 2 compatible avec l'EVM.

Les compromis architecturaux

L'approche hybride n'est pas gratuite.

L'un des compromis est l'identité des actifs. Un pont univoque vers le réseau de destination crée une version du stablecoin qui est canonique au sein de ce réseau, mais pas globalement. Cela nécessite une décision consciente sur les actifs qui sont traités comme canoniques et ceux qui sont considérés comme importés ou hérités.

Il existe également des exigences en matière d'intégration. La messagerie, l'indexation et la prise en charge des portefeuilles doivent être gérées proprement afin que l'expérience d'entrée et de sortie soit cohérente, même si l'itinéraire traverse plusieurs systèmes.

Enfin, il peut y avoir des contraintes de temps. La prise en charge de chaînes de sources spécifiques, telles que Tron, dépend des feuilles de route des agrégateurs et des ponts, ce qui peut entraîner des retards temporaires.

Profil de risque du modèle hybride

Il est important de comprendre que le modèle hybride ne déplace pas le risque, mais l'élimine.

  • Dépendance à l'égard des agrégateurs : La qualité de l'exécution dépend des agrégateurs externes, notamment de leur couverture, de leur logique de routage et de leur comportement en matière de dégradation.
  • Exposition financière réduite par rapport aux modèles LP : Le réseau évite les coûts permanents de subventionnement des pools et de gestion des déséquilibres.
  • Risque temporel lié à l'activation de la chaîne : La disponibilité dépend du moment où les chaînes de sources spécifiques sont prises en charge par l'infrastructure environnante.

En échange de l'abandon du contrôle direct des liquidités, le réseau gagne en flexibilité et évite de dépendre en permanence de son propre bilan.

Ne paniquez pas. Pensez clairement.

Cet incident n'a rien à voir avec un “hack” tape-à-l'œil. Il s'agissait d'un chemin d'exécution qui permettait à une action sensible d'être exécutée sans les contrôles que les gens supposaient être en place. Mon conseil : utilisez les incidents de ce type de la bonne manière. Traitez-les comme un audit forcé de vos hypothèses. Notez ce en quoi vous avez confiance, pourquoi vous avez confiance et ce qui se passe si cette confiance est erronée.

Si vous souhaitez passer en revue votre flux exact, étape par étape, et voir où il peut se plier ou se casser, notre consultants blockchain peut l'examiner avec vous avant que la liquidité ne prenne la décision pour vous.

Expert en blockchain et analyste DeFi

Andrew vit et respire la blockchain. Il aide ses clients à naviguer dans un espace en constante évolution - en traduisant les grandes idées en stratégies techniques sécurisées, évolutives et conçues pour une utilisation dans le monde réel.

Table des matières

    Contactez-nous

    Réserver un appel ou remplissez le formulaire ci-dessous et nous vous contacterons dès que nous aurons traité votre demande.

    Envoyez-nous un message vocal
    Joindre des documents
    Charger fichier

    Vous pouvez joindre un fichier d'une taille maximale de 2 Mo. Formats de fichiers valables : pdf, jpg, jpeg, png.

    En cliquant sur Envoyer, vous consentez à ce qu'Innowise traite vos données personnelles conformément à notre politique de confidentialité. Politique de confidentialité pour vous fournir des informations pertinentes. En communiquant votre numéro de téléphone, vous acceptez que nous puissions vous contacter par le biais d'appels vocaux, de SMS et d'applications de messagerie. Les tarifs des appels, des messages et des données peuvent s'appliquer.

    Vous pouvez également nous envoyer votre demande
    à contact@innowise.com
    Que se passe-t-il ensuite ?
    1

    Une fois que nous aurons reçu et traité votre demande, nous vous contacterons pour détailler les besoins de votre projet et signer un accord de confidentialité.

    2

    Après avoir examiné vos souhaits, vos besoins et vos attentes, notre équipe élaborera une proposition de projet avec l'étendue des travaux, la taille de l'équipe, les délais et les coûts estimés projet avec l'étendue des travaux, la taille de l'équipe, les délais et les coûts estimés.

    3

    Nous prendrons rendez-vous avec vous pour discuter de l'offre et régler les détails.

    4

    Enfin, nous signons un contrat et commençons immédiatement à travailler sur votre projet.

    Autres services couverts

    flèche