Frais de bridge, finalité, slippage et transferts bloqués

2026-08-24

Frais de bridge, finalité, slippage et transferts bloqués

Déplacer un actif d'une chaîne vers une autre n'est pas une transaction. C'est une transaction sur la chaîne source, une attente pendant laquelle cette transaction devient difficile à annuler, et une seconde transaction sur la chaîne de destination que quelqu'un doit soumettre et payer. Chaque frais qu'on vous annonce et chaque minute d'attente sortent de cette séquence. Cet article la démonte pièce par pièce, et se termine par la façon de déterminer où se trouve réellement un transfert qui n'est pas arrivé.

Ce qui compose réellement les frais d'un bridge

Le bridge vous affiche un nombre, mais vous payez au moins quatre choses distinctes, libellées dans des jetons différents sur des réseaux différents. La documentation de LayerZero découpe sa tarification exactement en ces quatre composantes, et cette forme se retrouve dans la plupart des conceptions.

La première est la transaction sur la chaîne source. Verrouiller, brûler ou déposer votre actif est une transaction ordinaire sur la chaîne que vous quittez, tarifée par son propre marché des frais. Elle n'a rien de particulier, ce qui veut dire aussi qu'aucun bridge ne peut la rendre moins chère : si la chaîne source est chargée, cette part augmente.

La deuxième est la vérification. Quelque chose doit attester que l'événement sur la chaîne source a bien eu lieu : un ensemble de validateurs qui signe une attestation, un groupe configuré de réseaux vérificateurs, ou un service d'attestation hors chaîne. Ce travail se paie, et le prix suit la quantité de vérification demandée. Plus de vérificateurs indépendants signifie des frais plus élevés.

La troisième et la quatrième se situent du côté de la destination. Quelqu'un doit soumettre la transaction sur la chaîne de destination, et cette transaction consomme du gas sur place. La partie qui la soumet s'appelle généralement un relayeur ou un exécuteur, et elle facture son service. Le gas lui-même est acheté à l'avance, et c'est cette partie qui étonne le plus.

Pourquoi le gas de destination se paie d'avance, et ce qu'est un gas drop

Vous ne pouvez pas payer une transaction sur la chaîne de destination avec des jetons de cette chaîne que vous n'avez pas encore. Tout le problème est là : vous arrivez sur un réseau où votre adresse ne détient peut-être rien du tout. La cotation convertit donc le gas de destination en jetons de la chaîne source et vous le prélève d'avance.

La conversion repose sur trois grandeurs : le gas nécessaire à l'appel sur la chaîne de destination, le prix du gas là-bas à cet instant, et le rapport des prix de marché entre les jetons natifs des deux chaînes. Que l'une d'elles bouge et les frais changent sans que vous ayez rien fait, et c'est aussi pourquoi le même message coûte différemment dans chaque sens.

Certaines routes vont plus loin et déposent sur votre adresse une petite quantité du jeton natif de la chaîne de destination en même temps que l'actif. Le relayeur automatique de Wormhole, par exemple, interroge le contrat de destination sur ce montant natif, l'inclut dans la livraison et rembourse l'excédent. On appelle cela un gas drop ou un native drop.

Cela compte plus qu'il n'y paraît. Arriver sur une nouvelle chaîne avec l'actif mais sans son jeton natif, c'est posséder quelque chose que vous ne pouvez pas bouger, puisque le bouger demande un gas que vous n'avez pas. Vérifiez avant d'envoyer si la route inclut un gas drop, ou envoyez-vous d'abord un peu de jeton natif.

D'où vient le slippage, et où il n'existe pas

Pour cette question, les bridges se rangent en deux familles et une seule connaît le slippage. Dans les conceptions verrouillage-frappe et destruction-frappe, le montant est inscrit dans le message : on brûle une quantité ici, on frappe la même quantité là-bas. Aucun pool ne le valorise, il n'y a donc aucun impact de prix sur le montant lui-même.

Les routes fondées sur des pools fonctionnent autrement. Vous payez dans un pool sur la chaîne source et vous êtes payé depuis un autre pool sur la chaîne de destination, et ce que vous recevez dépend du remplissage de ces pools. La documentation de Stargate définit ses frais de transaction comme l'écart entre ce que l'utilisateur verse sur la chaîne source et ce qui arrive sur la chaîne de destination, et prévoit des ristournes sur les trajets où la demande a vidé le pool.

Sur une route à pools, le chiffre présenté comme le montant reçu est donc une cotation à cet instant et non une promesse. Entre le moment où vous signez et celui où la transaction de destination s'exécute, le pool peut bouger. C'est à cela que servent les réglages de montant minimum reçu et de tolérance au slippage : c'est le seuil sous lequel vous préférez que le transfert n'aboutisse pas.

Deux habitudes en découlent. Lisez le montant qui arrive plutôt que les frais affichés, car le montant qui arrive contient déjà tout. Et gardez l'échange distinct du passage entre chaînes : si la route convertit au passage un actif en un autre, ce segment a son propre impact de prix et relève de l'échange, pas du bridge.

Ce que vous attendez, c'est la finalité

Les minutes passées devant une barre de progression ne traduisent généralement pas la lenteur du bridge. C'est le bridge qui refuse de libérer de la valeur à destination tant que la transaction source reste facile à annuler. Libérer trop tôt, et une réorganisation de la chaîne source peut laisser d'un côté des actifs frappés qui, de l'autre, n'ont jamais vraiment été brûlés.

La durée est une propriété de la chaîne source, pas du bridge. La preuve d'enjeu d'Ethereum fonctionne par créneaux de 12 secondes regroupés en époques de 32 créneaux, et un bloc n'est finalisé que lorsque les votes sur les points de contrôle représentent deux tiers de l'ETH en staking : la finalité se compte donc en époques et non en blocs. Le tableau de finalité publié par Wormhole situe Ethereum autour de 19 minutes, Solana autour de 14 secondes et Avalanche autour de 2 secondes.

Les rollups sont l'endroit où l'intuition se trompe. Une transaction sur un rollup se confirme en quelques secondes, mais sa finalité est héritée de la chaîne sur laquelle le rollup publie. Circle attend que le bloc Ethereum contenant un lot OP Stack soit finalisé, ce que sa documentation chiffre à environ 65 blocs, soit 15 à 19 minutes après la publication du lot ; la même page donne 6 à 32 heures pour les transferts standards depuis Linea et 4 à 8 heures depuis Starknet.

C'est aussi pourquoi des voies rapides existent et pourquoi elles sont plafonnées. Circle atteste les transferts rapides après quelques confirmations, de l'ordre de 8 à 20 secondes, et les soumet à un plafond global précisément parce qu'ils acceptent un risque de réorganisation que l'attente de la finalité dure n'a pas. La vitesse n'est pas ici une optimisation : c'est un réglage de risque que quelqu'un a choisi.

Pourquoi la même route n'attend pas toujours autant

Il y a deux attentes distinctes et elles échouent différemment. La première est l'attente de finalité côté source, fixée par la chaîne source et par le niveau de sécurité avec lequel la route a été configurée. La seconde est l'inclusion côté destination : même une fois le message prêt, la transaction de destination doit encore entrer dans un bloc, et une chaîne de destination congestionnée la retarde.

Certaines routes ajoutent volontairement une troisième variable. Regrouper les transferts de plusieurs utilisateurs dans un seul message répartit le coût du message entre eux et revient donc moins cher, mais le lot doit se remplir ou un minuteur doit expirer avant le départ. La documentation de Stargate décrit exactement cet arbitrage entre son mode groupé et son mode immédiat. Moins cher et plus lent est un choix que vous faites.

Un délai annoncé est donc un cas typique et non une garantie, et le même couple de chaînes peut se comporter différemment sur deux routes parce que leurs intégrateurs ont choisi des réglages de finalité différents. Wormhole dit clairement aux intégrateurs que choisir autre chose que le niveau finalisé augmente l'exposition au risque de réorganisation.

Avant d'appuyer sur envoyer, notez cinq choses : le hash de la transaction source, le bridge ou la route utilisée, la chaîne et l'adresse de destination, le montant de sortie annoncé et le délai annoncé. Sans le hash, vous ne pouvez rien vérifier du tout, et c'est justement ce qui manque le plus souvent ensuite.

Frais de bridge, temps de finalité et slippage : les quatre composantes des frais, ce qui fixe l'attente, et les trois étapes où peut se trouver un transfert qui n'est pas arrivé

Où se trouve un transfert qui n'est pas arrivé

Quand rien n'est apparu, la question utile n'est pas comment récupérer l'argent. C'est de savoir à laquelle des trois étapes le transfert se trouve : la chaîne source l'a-t-elle confirmé, le message a-t-il été vérifié, la chaîne de destination l'a-t-elle exécuté. Chaque étape a une réponse différente, et vous pouvez vérifier les trois vous-même avec des outils publics.

L'étape une, c'est la chaîne source. Ouvrez l'explorateur de blocs de la chaîne source, collez le hash de votre transaction et lisez le statut. Toujours pending signifie qu'elle n'a pas encore été incluse. Dropped signifie que rien n'a quitté la chaîne source et que votre actif n'a pas bougé. Reverted signifie que la transaction a échoué sur la chaîne source : l'actif est resté où il était, mais le gas a bien été dépensé.

L'étape deux, c'est le message. La transaction source est confirmée mais la destination reste muette, ce qui signifie le plus souvent que vous êtes dans la fenêtre de finalité décrite plus haut, et la réponse honnête est d'attendre l'intervalle exigé par cette chaîne. La plupart des bridges tiennent leur propre explorateur de messages, où vous pouvez voir si l'attestation de votre transfert a déjà été produite. Certaines conceptions permettent aussi de terminer à la main : la documentation de Wormhole décrit l'utilisateur soumettant lui-même l'attestation signée, et ajoute qu'un transfert manuel devrait être achevé dans les 24 heures, car l'ensemble des validateurs peut ensuite avoir changé et les signatures devoir être remplacées avant que la destination ne les accepte.

L'étape trois, c'est la destination. Si une transaction de destination existe mais a échoué, les causes habituelles sont un gas insuffisant alloué à l'appel de destination ou un contrat destinataire qui l'a rejeté. Comme plusieurs conceptions séparent la vérification de l'exécution, ce cas peut souvent être réessayé côté destination sans rien renvoyer depuis la source, et c'est l'entrée de l'explorateur de messages qui vous dit si une nouvelle tentative est possible.

Puis la part que personne n'a envie d'écrire : certaines issues n'ont pas d'annulation. Un transfert confirmé sur une chaîne ne peut être annulé par personne, et si l'actif a atterri sur une chaîne ou à une adresse que vous ne contrôlez pas, aucune procédure ne le récupère. C'est exactement dans cet écart que se vendent les services de récupération. Le FBI a averti que ces sociétés facturent des frais d'avance puis cessent de répondre ou remettent un rapport de traçage inexact en réclamant davantage, souvent en se prétendant liées aux forces de l'ordre, et il indique clairement que les sociétés privées de récupération ne peuvent pas émettre d'ordres de saisie. Lisez vos propres explorateurs et ne payez pas un inconnu qui vous a trouvé dans une section de commentaires.

Conclusion

Les frais d'un bridge, ce sont une transaction sur la chaîne source, le coût de la vérification qu'elle a eu lieu, la rémunération d'un relayeur pour la soumission de l'autre côté, et du gas de destination acheté à l'avance au rapport de prix des deux chaînes. L'attente, c'est la chaîne source qui atteint la finalité : une propriété de cette chaîne, plus le niveau de sécurité choisi par la route, les rollups héritant de la leur de la chaîne du dessous. Le slippage n'apparaît que là où un pool valorise votre versement : lisez donc le montant qui arrive plutôt que les frais. Et quand un transfert n'arrive pas, localisez-le au lieu de le pleurer : source confirmée, message vérifié, destination exécutée. Trois explorateurs répondent à cette question, et personne qui vous contacte en premier n'y répondra mieux.

Articles associés

Autres articles Bitbase sur ce sujet :

- Bagholders, degens, maxis et exit liquidity : les archétypes crypto

- Stratégie de stop-loss en crypto : protéger chaque position

- Les ordres OCO, take-profit et stop-loss expliqués

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en août 2026 ; référez-vous aux informations officielles les plus récentes.

Sources

[1] Finality and Block Confirmations (CCTP) developers.circle.com

[2] Transaction Pricing Model docs.layerzero.network

[3] Flow of Wrapped Token Transfers (WTT) wormhole.com

[4] Wormhole Finality | Consistency Levels wormhole.com

[5] Proof-of-stake (PoS) ethereum.org

[6] Stargate V2 Fees stargateprotocol.gitbook.io

[7] Increase in Companies Falsely Claiming an Ability to Recover Funds Lost in Cryptocurrency Investment Scams ic3.gov

Articles connexes

Plus