Comment évaluer un pont L2 avant de le traverser

Ce que fait réellement un pont L2, et pourquoi c'est important pour votre argent

Un pont est un logiciel qui vous permet de déplacer un actif d'une chaîne à une autre. Lorsque vous déposez des ETH dans le pont Arbitrum, vos ETH sont verrouillés dans un smart contract sur le mainnet Ethereum et une quantité équivalente d'ETH wrapped est émise sur Arbitrum. Lors d'un retrait, les ETH wrapped sur Arbitrum sont brûlés et les ETH d'origine sont libérés sur le mainnet. Dans les deux sens, quelque part dans la pile se trouve un contrat qui détient votre actif réel, et ce contrat est la cible des attaquants.

C'est pourquoi chaque pont, quelle que soit la qualité de son interface, fonctionne comme un dépositaire de dernier recours. Pendant que vos tokens séjournent dans le contrat du pont, vous ne les contrôlez pas comme un utilisateur de portefeuille matériel contrôle ses pièces. Si le contrat est exploité, vidé ou gelé par la gouvernance, vos fonds suivent le même chemin. L'histoire des ponts est en grande partie l'histoire de ces contrats qui ont été cassés : Ronin (plus de 600 millions de dollars, 2022), Wormhole (plus de 300 millions de dollars, 2022), Multichain (estimé entre 125 et 265 millions de dollars selon les sources, 2023), le pont Horizon de Harmony (environ 100 millions de dollars, 2022) et le pont Nomad (environ 190 millions de dollars, 2022). Des milliards ont été dérobés sur des ponts ; presque aucune de ces pertes ne provenait des L1 ou L2 eux-mêmes.

Ce bilan est le point de départ de toute diligence raisonnable. Vous ne choisissez pas entre deux chemins techniques également sûrs. Vous choisissez entre différents dépositaires avec différentes surfaces d'attaque, et votre travail consiste à déterminer lesquels ont fait le travail ingrat de se renforcer et lesquels sont à un rapport de bug près de la une des journaux.

Les signaux d'alerte à repérer avant de signer une transaction de pont

Avant de passer à la checklist en 7 points, il est utile de savoir ce dont il faut se méfier au premier regard. Les ponts présentant un ou plusieurs de ces signaux d'alerte ont déjà fait perdre de l'argent à des utilisateurs ou sont structurellement similaires à des ponts qui en ont fait perdre.

• Pas d'audit tiers, ou seulement un audit auto-hébergé réalisé par un cabinet inconnu. Traitez le pont comme non audité.
• Équipe anonyme sans historique et sans entité juridique. Il n'y a personne à poursuivre et aucun moyen de vérifier que les opérateurs ne sont pas déjà dans le système.
• TVL annoncée sur le tableau de bord propre du projet qui ne correspond pas aux données on-chain. Une fausse TVL est une tactique fréquente pour attirer les dépôts avant un exit.
• Pas de bug bounty, ou un bounty conditionné à des tokens et si faible qu'il n'attire pas de vrais chercheurs. Si payer 50 000 dollars permet de vider 200 millions de dollars, les attaquants ne signaleront pas la faille.
• Contrats upgradables contrôlés par un multisig à seuil bas. Un multisig 2-sur-5 qui gère tous les fonds du pont est à une seule campagne de phishing d'une perte.
• Base de code copiée-collée d'un pont déjà exploité. Les forks héritent des bugs de leur parent, sauf si chaque ligne a été ré-auditée.
• Wrapper porteur de rendement sans source de rendement claire. Si le pont promet 4 % sur vos stablecoins et que la page ne peut pas expliquer d'où vient le rendement, le rendement est probablement votre principal.

Si vous en repérez deux ou plus sur le même pont, la seule action sûre est de ne pas déposer. La checklist qui suit indique ce qu'il faut vérifier quand aucun de ces points ne crie « danger », mais que vous voulez quand même vérifier avant d'engager des sommes importantes.

Point de la checklist 1 : pont canonique ou pont tiers

La question la plus importante est de savoir si le pont que vous vous apprêtez à utiliser est le pont canonique géré par l'équipe du rollup elle-même (le pont officiel d'Arbitrum, le pont standard de l'OP Stack, le pont fourni avec un zk-rollup tel que zkSync) ou un pont tiers opéré par un protocole externe (Across, Stargate, Hop, Wormhole, Synapse, Rhino.fi, etc.).

Un pont canonique hérite du modèle de sécurité du rollup. Si vous faites confiance à Arbitrum pour être une exécution fidèle d'un rollup optimiste, vous étendez cette confiance à son pont canonique. Un pont tiers ajoute une hypothèse de confiance supplémentaire par-dessus le rollup, car le tiers exécute ses propres contrats, sa propre infrastructure de nœuds et, en général, sa propre logique de transmission de messages. Certains ponts tiers, comme Across, ont évolué vers des conceptions light en validateurs avec des relais cautionnés et des preuves de fraude au niveau du relayeur, ce qui réduit l'écart de confiance. D'autres s'appuient encore sur des multisigs ou des ensembles de validateurs externes.

Pour un utilisateur qui a simplement besoin de transférer des fonds entre Ethereum et Arbitrum ou OP, le pont canonique est généralement la bonne réponse par défaut. Utilisez un pont tiers lorsque vous avez spécifiquement besoin de ce qu'il offre : des retraits plus rapides sur les rollups optimistes, des envois multichaînes en un clic, ou des itinéraires que le pont canonique ne prend pas en charge. Dans ces cas, les points suivants de la checklist comptent encore davantage.

Point de la checklist 2 : le système de preuves et ce qu'il implique pour le délai de retrait

Les ponts ne sont pas tous aussi rapides, et la différence de vitesse n'est pas cosmétique. Elle est une conséquence directe du système de preuves utilisé par le rollup.

Les rollups optimistes (Arbitrum, OP Mainnet, Base) supposent que les transactions sont valides sauf contestation durant une fenêtre de litige. La période de contestation est actuellement d'environ 7 jours sur Arbitrum et OP, avec des fenêtres plus courtes dans les configurations plus récentes. Lorsque vous retirez vers le mainnet via le pont canonique, vous attendez à peu près ce laps de temps avant que les fonds ne puissent être réclamés, car le pont ne libérera pas l'actif bloqué tant que la fenêtre de preuve de fraude ne se sera pas fermée sans contestation gagnante. La contrepartie, ce sont des frais moins élevés et une conception éprouvée.

Les rollups à validité (zkSync, Starknet, Linea, Polygon zkEVM, et les nouvelles chaînes OP Stack évoluant vers des preuves de faute avec des fenêtres plus courtes) génèrent une preuve cryptographique attestant que chaque lot de transactions L2 est correct. Une fois cette preuve de validité vérifiée sur la L1, le pont peut libérer les fonds. Les retraits se finalisent généralement en quelques dizaines de minutes à quelques heures, selon le prouveur et l'encombrement de la L1, et non en plusieurs jours.

Concrètement, si un pont tiers propose un « retrait rapide » sur un rollup optimiste, il fait quelque chose en coulisses pour vous fournir de la liquidité immédiatement (en général en vous avançant l'actif depuis un pool de liquidité, puis en encaissant plus tard le retrait canonique). Ce produit est raisonnable si le pont est réputé, mais il ajoute une contrepartie qu'il faut bien comprendre. Le pont canonique lent est l'option qui minimise la confiance ; le pont rapide est l'option pratique assortie d'un risque supplémentaire.

Point de la checklist 3 : audits, programme de bug bounty, et la différence entre « audité » et « sûr »

Un audit est une revue ponctuelle du code de contrats intelligents par un cabinet externe. Il ne couvre pas tous les bugs possibles, il ne couvre pas le risque de gouvernance ou économique, et il ne couvre pas les mises à jour introduites après la publication de l'audit. Des ponts peuvent être audités et pourtant être exploités, tout comme des ponts peuvent ne pas être audités et fonctionner pendant des années sans incident. La posture d'audit est un signal probabiliste, pas une garantie.

Ce qu'il faut rechercher : des audits réalisés par des cabinets réputés (OpenZeppelin, Trail of Bits, Spearbit, ChainSecurity, Zellic, Cantina, reviewers affiliés à Code4rena, Certora pour des travaux plus formels), publiés avec un périmètre clair, des dates et la version du code revue. Plusieurs audits au fil du temps. Un programme de bug bounty sur une plateforme comme Immunefi ou Code4rena, avec une taille significative (un bounty de 50 000 $ sur un pont détenant 10 millions de $ relève du théâtre ; un bounty de 2 millions de $ sur un pont détenant 500 millions de $ est au moins dans le bon ordre de grandeur).

Tout aussi important : un processus documenté de réponse aux incidents, des post-mortems publics pour tout problème passé, et un multisig avec un seuil élevé et des signataires publiquement connus. L'exploitation de Wormhole en 2022 s'est produite en partie parce que le processus de mise à jour du réseau de gardiens a contourné une revue adéquate ; l'équipe a corrigé et remboursé les utilisateurs, mais la leçon est que la procédure compte autant que le code.

Vous pouvez vérifier la majeure partie de tout cela en un après-midi. Consultez la documentation du projet, cherchez les rapports d'audit sur GitHub, vérifiez la page du bounty sur Immunefi, examinez les permissions de mise à jour sur Etherscan (lire le contrat, vérifier les propriétaires, vérifier les motifs de proxy), et lisez les douze derniers mois de publications sur le forum de gouvernance.

Point de la checklist 4 : concentration de la TVL, historique de piratages et pression sur la fenêtre de sortie

La TVL, ou valeur totale verrouillée, est le montant en dollars immobilisé dans les contrats d'un pont. Deux risques opposés se cachent derrière ce chiffre unique.

Premièrement, le risque de concentration. Si un pont détient 3 milliards de $ dans un seul contrat, il constitue une cible plus importante qu'un pont avec la même TVL répartie sur de nombreux pools plus petits. Les pots de miel plus gros attirent des attaquants plus sophistiqués, et le rayon d'impact d'un seul bug est plus large. Si un pont détient 3 milliards de $ et qu'un multisig 2-sur-5 peut le mettre à niveau, c'est un problème structurel, quelle que soit la qualité de l'interface.

Deuxièmement, la question de la pérennité du pont lui-même. Les ponts perçoivent des frais sur les flux, mais les plus gros doivent aussi continuer à payer les audits, la surveillance et la réponse aux incidents. Les ponts qui peinent à se financer rognent parfois sur les dépenses, et les économies réalisées sur l'outillage de sécurité se traduisent par des bugs deux ans plus tard. Vérifiez si le pont dispose d'un modèle de revenus durable et si l'équipe est en place depuis suffisamment longtemps pour avoir traversé au moins un cycle de marché baissier majeur.

L'historique de piratages est le troisième volet de ce point. Un pont qui a été exploité puis reconstruit en traitant la cause de la perte précédente (post-mortem et re-audit de Nomad, refonte du réseau de gardiens de Wormhole) est d'une toute autre nature qu'un pont sans aucun historique. Un pont qui a été exploité et relancé discrètement sans traiter la cause doit être considéré comme compromis.

Croisez la TVL on-chain avec ce que le pont annonce. Les tableaux de bord DefiLlama, L2Beat et Dune dédiés au pont concerné vous permettent de comparer les soldes réels des contrats à la communication du projet. Un projet qui revendique 400 millions de $ de TVL alors que les contrats n'en détiennent que 40 millions fait quelque chose auquel vous ne voulez pas participer.

Point 5 de la checklist : quel actif vous recevez réellement

C'est le point que la plupart des utilisateurs négligent, et c'est celui qui leur coûte le plus. Lorsque vous transférez des USDC d'Ethereum vers Arbitrum via un bridge, ce qui arrive dans votre portefeuille dépend entièrement du bridge que vous avez utilisé et du contrat qui se trouve du côté de la réception.

L'USDC natif est émis directement par Circle sur chaque chaîne prise en charge par Circle. En 2025, Circle émet des USDC natifs sur Ethereum, Arbitrum, OP Mainnet, Base, Polygon, Avalanche, et une liste croissante d'autres chaînes, via un Cross-Chain Transfer Protocol (CCTP) qui brûle les USDC sur la chaîne source et émet des USDC natifs sur la chaîne de destination. Lorsque vous recevez des USDC natifs, l'actif sur Arbitrum a le même émetteur que celui sur Ethereum, et les attestations de Circle s'appliquent.

L'USDC bridgé est un token différent. Il s'agit d'une version enveloppée émise par un bridge tiers (USDC.e sur Arbitrum, par exemple, ou USDC sur des chaînes où Circle n'a pas effectué d'émission). L'émetteur est le bridge, pas Circle. Circle n'atteste pas de ce token enveloppé. Si le bridge est exploité, l'USDC enveloppé devient sans valeur ; l'USDC natif sur la même chaîne n'est pas affecté.

Pourquoi cela est important en pratique : de nombreux protocoles DeFi sur Arbitrum listent encore USDC.e plutôt que l'USDC natif, parfois les deux, parfois un seul. Avant de bridge, vérifiez quel token le protocole de destination accepte et quel token vous recevrez réellement. Recevoir de l'USDC natif via le CCTP de Circle se rapproche d'un bridge à confiance réduite plutôt que d'un bridge tiers générique, car le mécanisme de mint/burn de Circle signifie qu'il n'y a pas de liquidité mise en commun détenue par un tiers ; l'USDC est détruit côté source et recréé côté destination.

Points 6 et 7 de la checklist : mises à jour, gouvernance et petits signaux opérationnels

Les deux derniers points sont plus modestes en eux-mêmes, mais ils détectent des problèmes que les cinq premiers peuvent manquer.

Le point 6 de la checklist concerne l'évolutivité et la gouvernance. Le contrat du bridge est-il derrière un proxy ? Peut-il être mis à jour, et par qui, et à quelle vitesse ? Les bridges avec des timelocks sur les mises à jour (un délai de 24 à 72 heures avant que les modifications ne prennent effet) laissent à la communauté le temps de réagir à une action de gouvernance hostile. Les bridges sans timelock, ou avec un seul propriétaire EOA, ne conviennent pas à des dépôts sérieux. Pour une position de la taille d'un ETH, la gouvernance des mises à jour du bridge est une décision à plus fort levier que le choix du L2 sur lequel vous finirez par vous installer.

Le point 7 de la checklist concerne la dimension humaine. L'équipe est-elle publique, a-t-elle des antécédents solides, a-t-elle livré des mises à jour dans les délais, dispose-t-elle d'une page de statut fonctionnelle, publie-t-elle des rapports d'incident en anglais sur un forum public ? Une équipe de bridge qui réagit pendant un incident peut empêcher une perte de devenir une catastrophe totale. Une équipe de bridge qui reste silencieuse pendant les incidents aggrave la panique. Le bridge Harmony Horizon a été exploité en juin 2022 en partie parce que la surveillance avait manqué l'intrusion initiale ; une meilleure surveillance aurait pu réduire la perte.

Vous pouvez assembler tout cela dans une checklist d'une page avant chaque transaction via bridge : canonique ou tiers, système de preuve, audits et bug bounty, TVL et historique, actif reçu, gouvernance des mises à jour, qualité de l'équipe. La plupart de ces vérifications prennent trente minutes de lecture la première fois que vous examinez un bridge, et cinq minutes lors d'une revisite. Le coût de les négliger est payé par les personnes qui pensaient que leur bridge était le problème de quelqu'un d'autre.

Comment suivre les bridges L2 de manière intelligente

Les bridges L2 évoluent vite, et l'actualité autour d'eux aussi. Suivre quel bridge vient d'obtenir un audit, lequel a ajouté la prise en charge de l'USDC natif, lequel a vu un vote de gouvernance qui a affaibli son chemin de mise à jour, est un travail à part entière, et la plupart des utilisateurs n'ont pas le temps de le surveiller manuellement. Zippfeed met en avant les titres liés aux L2 et aux bridges avec une notation de sentiment (bullish, neutral ou bearish) et une note d'importance, afin que vous puissiez repérer les changements concernant les bridges que vous utilisez déjà, découvrir les nouveaux tôt, et éviter ceux qui sont sur le point de faire l'actualité pour de mauvaises raisons.