Votre message a été envoyé.
Nous traiterons votre demande et vous contacterons dès que possible.
Le formulaire a été soumis avec succès.
Vous trouverez de plus amples informations dans votre boîte aux lettres.

Sélection de la langue


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.
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 ?.
À 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.
| Approche | Où vivent les liquidités | Type d'actif | UX à volume réel | Risque primaire |
| Ponts / piscines LP | Préfinancement des deux côtés | USDT natif | Bon jusqu'à la vidange des piscines | Épuisement des liquidités, déséquilibre |
| Lock-mint / burn-unlock | Verrouillé sur Tron | Ponté / enveloppé | Prévisible | Confiance, fragmentation |
| Exécution basée sur l'intention | Avec les solveurs / MM | Dépend de l'itinéraire | Très bien si les résolveurs restent | Sortie du solveur, tarification |
| Entrée hybride | Chaînes liquides externes | Canonical-by-design | Stable si le routage est maintenu | Messagerie, 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.
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.

Lorsque les bridges LP sont correctement mis en place, ils offrent plusieurs avantages indéniables.
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
À 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é.
Les ponts LP comportent simultanément plusieurs niveaux de risque.
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.
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 :
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.
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.

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 :
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.
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.
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.

Ce modèle correspond au cas d'utilisation de Tron pour quelques raisons concrètes :
Lorsque la participation des résolveurs est saine, l'exécution basée sur l'intention donne de bons résultats.
Les propriétés qui rendent les intentions attrayantes définissent également leurs limites.
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.
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.

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 :
Cet actif est synthétique au niveau du protocole, mais traité comme canonique dans la pile DeFi de Haust.
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.

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.
Il est important de comprendre que le modèle hybride ne déplace pas le risque, mais l'élimine.
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.
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.












Votre message a été envoyé.
Nous traiterons votre demande et vous contacterons dès que possible.

En vous inscrivant, vous acceptez notre Politique de confidentialitéy compris l'utilisation de cookies et le transfert de vos informations personnelles.