Quand un rollup cesse de fonctionner : explications sur l'arrêt de Polygon zkEVM

3 juillet 2026

10 min de lecture

Résumer avec l'IA

Polygon zkEVM est officiellement entré dans sa phase de fin de vie. Le 1er juillet 2026, Polygon Labs a désactivé le séquenceur de la version bêta du réseau principal Polygon zkEVM, les soldes des portefeuilles étant transférés vers Ethereum L1 via une procédure de réclamation. Il faut reconnaître que cette fermeture a été gérée avec soin : les utilisateurs ont eu une année entière pour s'y préparer, le pont est resté ouvert jusqu'au dernier jour et les réclamations restent possibles jusqu'à fin 2027.

Le problème, c’est que les blockchains ne se contentent pas de stocker des cryptomonnaies dans des portefeuilles. Au moment où un réseau cesse ses activités, une partie des liquidités est déjà enfouie à plusieurs niveaux de profondeur : dans des pools, des coffres-forts, des marchés de prêt, des positions de garantie et d’autres contrats que Polygon ne contrôle pas. Les ramener vers la couche 1 (L1) n’est plus une simple opération de pontage.

Nous avons donc posé à notre expert, Andrew Nalichaev, les questions que beaucoup de personnes du secteur se posent sans doute en ce moment : Qui est responsable de cette liquidité bloquée ? Qu'advient-il des stablecoins sur un réseau en déclin ? Et quelles leçons les autres rollups devraient-ils en tirer avant d'être confrontés au même problème ?

Andrew Nalichaev

Expert en blockchain et analyste DeFi

Andrew traduit les concepts décentralisés en outils financiers sécurisés et fonctionnels. Il navigue dans le paysage volatile de DeFi pour construire des infrastructures blockchain évolutives qui répondent à l'utilité du monde réel, dépassant les mots à la mode pour offrir une valeur technique.

Voir le profil

- Si l'on considère Polygon zkEVM comme une étude de cas concernant la fermeture d'un réseau de couche 2, quels aspects ont été bien gérés et quels éléments auraient dû être pris en compte dès le départ ?

La meilleure chose que Polygon ait faite dans ce cas, c’est d’avoir laissé du temps aux utilisateurs et de leur avoir proposé une procédure claire. La fin de vie de zkEVM a été annoncée environ un an à l'avance, le pont est resté ouvert jusqu'au dernier jour, un instantané des soldes a été réalisé et les utilisateurs ont eu la possibilité de récupérer leurs fonds sur Ethereum L1. En matière de fermeture, c'est une manière plutôt soignée de gérer les choses.

L’élément qui aurait dû être intégré dès le départ est le plan de sortie DeFi. Transférer les soldes des portefeuilles est une chose, car ces soldes correspondent parfaitement aux actifs placés dans le compte séquestre du pont. La DeFi est une tout autre affaire. Les jetons LP, les parts de coffre-fort, les positions de garantie et les créances doivent tous disposer de leurs propres voies de sortie d’urgence au niveau du protocole. Sans cela, une fois que le séquenceur s’arrête, il peut devenir très difficile, voire parfois impossible, d’accéder aux liquidités détenues dans des contrats tiers.

- Dans quelle mesure est-il réaliste de “ fermer proprement ” un réseau de couche 2 alors qu’il héberge déjà des protocoles DeFi, des positions de LP, des coffres-forts, des garanties et des jetons dérivés ?

Une fermeture en douceur est possible, mais seulement jusqu'à un certain point. S'il s'agit simplement de soldes de portefeuilles ou d'actifs directement liés au compte séquestre du pont, alors oui, on peut rendre le processus assez fluide. Dès que la composabilité de la DeFi entre en jeu, les choses se compliquent considérablement.

Prenons un pool AMM classique. En théorie, on pourrait identifier les détenteurs des jetons LP, calculer leur part du pool et répartir les actifs sous-jacents. Il faut que ce soit le détenteur actuel, et non celui qui a effectué le dépôt initial, sinon on risque de payer deux fois la même personne. Mais dans la réalité, la DeFi est rarement aussi simple. Les jetons LP peuvent être placés dans des coffres-forts, mis en staking, utilisés comme garantie ou intégrés à un autre produit. Du coup, vous n’avez plus affaire à un seul droit, mais à toute une chaîne de droits, et il n’existe aucun moyen universel de déterminer qui est le “ véritable ” propriétaire à travers tous les contrats possibles.

La réponse honnête est donc la suivante : un L2 ne peut s'arrêter correctement que si les protocoles qui s'appuient sur lui ont prévu ce scénario dès le départ. Sinon, même si l'arrêt au niveau du réseau semble bien organisé, la couche DeFi peut tout de même se retrouver dans un état chaotique.

- Comment évalueriez-vous le risque de double dépense lorsque l'on tente de liquider manuellement des positions DeFi après une interruption du réseau ? S'agit-il principalement d'un problème technique, juridique ou économique ?

C'est un mélange des trois, mais au fond, il s'agit d'un problème économique.

Le compte séquestre « bridge » sur L1 ne contient que les actifs réels qui ont été déposés dans le système. La DeFi ajoute ensuite des couches supplémentaires par-dessus : jetons LP, parts de coffre-fort, positions de prêt, jetons de dette et autres créances. Sur un marché de prêt, par exemple, on peut rapidement se retrouver avec plus de créances qu’il n’y a d’actifs en dépôt fiduciaire, du moins si l’on tente de rembourser tout le monde en même temps.

C'est là que se pose le problème de la double dépense. Il est impossible de rembourser à la fois le déposant, l'emprunteur et tous les détenteurs de produits dérivés à partir d'un même ensemble d'actifs sous-jacents si celui-ci n'est pas suffisamment important pour couvrir l'ensemble de ces créances.

Il existe également un piège lié au timing. Certaines positions n’ont même pas de valeur établie au moment où on les gèle : un prêt “ sous l’eau ” nécessite une liquidation, les intérêts doivent s’accumuler, un oracle doit être mis à jour. Si l’on interrompt la chaîne en cours d’exécution, la part « équitable » de ces positions devient indéfinissable, et pas seulement difficile à calculer.

D'un point de vue technique, on peut essayer de démêler qui est propriétaire de quoi. D'un point de vue juridique, il faudra peut-être déterminer quelle revendication prime. Mais d'un point de vue économique, la limite est très simple : on ne peut pas distribuer plus d'actifs qu'il n'en existe réellement.

- Les équipes L2 devraient-elles exiger que les protocoles prévoient une « porte de sortie » avant de leur permettre de déployer des liquidités sur le réseau ?

Oui, surtout si un protocole est censé conserver l'argent des utilisateurs. On ne peut pas accepter des dépôts, créer de la liquidité, puis se demander “ comment faire pour que tout le monde puisse retirer son argent ? ” alors que le réseau est déjà en train d'être désactivé.

La L2 elle-même ne peut intervenir que sur la partie claire et simple : s'assurer que les soldes correspondent bien au montant détenu dans le compte séquestre du pont. Elle ne peut pas, de manière réaliste, se plonger dans chaque protocole DeFi pour démêler les comptes. À ce stade, l'équipe de la L2 devrait décider à qui appartient quoi, comment les positions doivent être évaluées et qui doit être payé en premier. C’est une lourde responsabilité, et ce n’est pas vraiment leur rôle.

Il est donc vrai que les protocoles DeFi doivent disposer de leurs propres mécanismes de retrait d'urgence, de leur propre logique de règlement ou de plans d'arrêt avant que les utilisateurs ne commencent à y injecter des liquidités importantes.

- En quoi l'arrêt d'un séquenceur modifie-t-il le modèle de confiance pour les L2 ? Les utilisateurs doivent-ils désormais évaluer non seulement le risque lié au pont, mais aussi le risque lié à l'arrêt ?

C'est là que l'idée consistant à “ simplement retirer ses fonds ” commence à montrer ses limites. Cela fonctionne si vos fonds se trouvent simplement dans un portefeuille. Cela ne se passe pas aussi bien s'ils sont bloqués sur un marché de prêt, dans une position LP, dans un coffre-fort ou dans un contrat qui nécessite encore une transaction supplémentaire pour vous permettre de les retirer.

Lorsque le séquenceur s'arrête, la chaîne cesse de recevoir des instructions. Il se peut que vous ayez encore une réclamation valide quelque part, mais vous n'aurez peut-être plus de chemin viable pour y donner suite. C'est là que réside le problème : l'actif n'a peut-être pas disparu, mais le chemin permettant d'y accéder peut s'effacer.

Les utilisateurs doivent voir plus loin que la sécurité des ponts. Pour les L2 de plus petite envergure, en particulier celles dont la liquidité est faible ou dont l'écosystème est encore expérimental, il convient également de se poser la question suivante : que se passerait-il si ce réseau venait à disparaître, et puis-je réellement en sortir avant que cela n'arrive ?

- Qu'advient-il des réserves des stablecoins sur un réseau en déclin, notamment lorsqu'on compare l'USDC.e transféré via un pont à une émission native via un modèle de type CCTP ?

Avec les stablecoins “ bridged ” comme l’USDC.e, l’USDC réel est conservé en dépôt fiduciaire sur la couche 1 d’Ethereum. Si votre USDC.e se trouve simplement dans votre portefeuille, il peut être migré ou réclamé. S’ils sont bloqués dans un contrat avec lequel plus personne ne peut interagir, l’USDC sous-jacent est toujours présent, mais l’utilisateur n’a aucun moyen concret d’y accéder. L’émetteur ne tire aucun profit « supplémentaire » de cette situation. La couverture est toujours là, mais la valeur est en quelque sorte piégée.

Les stablecoins natifs fonctionnent différemment. Dans une configuration de type CCTP, le token est émis directement sur la L2, et la réserve en monnaie fiduciaire est détenue par l’émetteur. Pour se retirer proprement, il faut brûler le token sur la L2 avant la fermeture, puis l’émettre ailleurs. Si le token est bloqué dans un contrat inactif, il n’est plus possible de le détruire sur la chaîne. L’émetteur se retrouve donc avec des réserves réelles correspondant à des tokens qui existent toujours, mais sur un réseau qui ne fonctionne plus.

À ce stade, l'émetteur doit décider de la marche à suivre : conserver les réserves, accepter les réclamations hors chaîne accompagnées d'une preuve, ou, à défaut, considérer ces jetons comme abandonnés.

Ne laissez pas les risques liés à l'infrastructure se transformer en risques liés au produit

Innowise permet de concevoir des infrastructures Web3 avec moins de points aveugles

- Quels enseignements les équipes chargées de développer de nouveaux écosystèmes de rollups devraient-elles tirer de l'arrêt de Polygon zkEVM ?

Polygon zkEVM nous rappelle que chaque rollup doit disposer de deux feuilles de route : l'une pour la croissance, et l'autre pour une fermeture en toute sécurité. Attirer des liquidités ne représente que la moitié du travail. Les équipes doivent également disposer d'un moyen clair de retirer ces liquidités si le réseau venait à fermer.

Cela implique d'avertir les utilisateurs suffisamment tôt, de maintenir le pont ouvert aussi longtemps que possible, de mettre en place une procédure claire de remboursement des soldes des portefeuilles, et de communiquer avec les protocoles DeFi bien avant la date de fermeture. Cela implique également de préciser clairement ce qu'il adviendra des actifs transférés via le pont, des actifs natifs et des stablecoins.

Avant tout, les équipes devraient cesser de considérer la TVL comme un élément que l'on peut simplement emballer pour le déplacer plus tard. Une fois que le séquenceur s'est tu, la vraie question est la suivante : quelle quantité de liquidité doit encore faire l'objet d'une transaction pour être libérée ?

Tout cela nous enseigne également une leçon en matière de conception. Si la mise hors service d’un système s’avère aussi pénible, il vaut la peine de se demander honnêtement, avant le lancement, si la charge de travail avait réellement besoin de sa propre chaîne. De nombreux cas d’utilisation “ inviolables ” sont mieux gérés par une base de données vérifiable ou un journal de transparence avec un point d’ancrage externe. Il n’y a pas de séquenceur à désactiver dans ce cas.

- Quels éléments devraient figurer au minimum dans le plan d'arrêt d'un réseau de niveau 2 avant le lancement du mainnet : communication, réclamations relatives aux ponts, coordination DeFi, politique relative aux stablecoins, ou autre chose ?

Un plan d'arrêt de L2 bien conçu doit détailler l'ensemble du processus, depuis le premier avertissement jusqu'à la date limite de réclamation. Les équipes doivent déterminer dès le début à quel moment les utilisateurs seront informés, combien de temps le pont restera ouvert, quand aura lieu le dernier instantané, comment fonctionneront les réclamations L1, et ce qu'il adviendra des fonds non réclamés.

La DeFi mérite un plan spécifique. Les protocoles doivent préciser si les utilisateurs peuvent effectuer des retraits en cas d'urgence, comment les positions peuvent être liquidées, et ce qu'il advient des jetons LP, des parts de coffre-fort, des garanties et de la dette si le réseau cesse de traiter les transactions.

Les stablecoins doivent bénéficier de la même clarté. Les actifs transférés via des ponts et ceux émis en natif se comportent de manière très différente en cas d'arrêt d'un réseau ; les utilisateurs doivent donc savoir exactement quelles règles s'appliquent à chaque token.

- Dans ces situations, quel est généralement le plus difficile : mettre fin techniquement au réseau, attribuer juridiquement les responsabilités ou résoudre, sur le plan économique, le problème du gel des liquidités ?

La mise hors service du réseau est sans doute la partie la plus simple de tout le processus. Les vrais problèmes commencent dès lors que l'on examine qui a encore de l'argent immobilisé, où se trouve cet argent et qui a le droit de prendre des décisions à son sujet.

Sur le plan juridique, la responsabilité devient très vite floue. L'équipe L2 gère l'infrastructure, mais elle n'est pas propriétaire de tous les protocoles DeFi construits par-dessus. Sur le plan économique, la situation se complique encore davantage, car la DeFi peut créer plusieurs niveaux de créances sur la même liquidité sous-jacente. Si cette liquidité est limitée, bloquée ou déjà engagée sous différentes formes, certaines créances ne peuvent tout simplement pas être honorées dans leur intégralité.

Le plus difficile est donc de trouver un moyen équitable de gérer les liquidités gelées sans payer deux fois le même actif sous-jacent, sans créer de nouveaux engagements et sans obliger l'équipe chargée de l'infrastructure à jouer le rôle de juge pour chaque protocole de l'écosystème.

- Selon vous, quel impact cette affaire aura-t-elle sur la confiance accordée aux L2 de plus petite taille et aux écosystèmes de zk-rollups à faible TVL ?

Cette affaire va faire en sorte que les réseaux L2 de plus petite taille soient perçus comme beaucoup moins “ sûrs par défaut ”. Un TVL déjà faible suscite déjà des interrogations. Désormais, les utilisateurs se posent une autre question : si ce réseau venait à fermer, pourrais-je réellement récupérer mes fonds ?

Pour les zk-rollups, la confiance ne se résumera pas à la technologie, aux frais et à la vitesse. La dépendance vis-à-vis des séquenceurs, les réclamations liées aux ponts, les voies de sortie de la DeFi et la gestion des stablecoins font désormais partie de la liste des critères à prendre en compte. Un rollup doit désormais prouver que les utilisateurs peuvent en sortir aussi facilement qu’ils y sont entrés.

L'expertise d'Andrew au travail

Plus d'informations sur ce sujet

Blog

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

Blog

Top Layer 2 blockchains: trouvez la solution adaptée à votre projet

Blog

Qu'est-ce qu'un DID ? Guide sur l'identité numérique

Contactez-nous

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

Nom

Entreprise

Courriel :

Téléphone

Message

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?

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

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.

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

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