Un nouveau rapport du Lazarus Security Lab de Bybit suggests que de nombreuses grandes blockchains ne sont pas aussi « trustless » qu’elles le paraissent. Dans une industrie fondée sur la décentralisation, cela paraît suspect.
Les chercheurs de Bybit ont examiné les bases de code de 166 blockchains grâce à une analyse assistée par l’IA et à une revue manuelle. Ils ont découvert que 16 réseaux disposent déjà de capacités intégrées de gel de fonds, et que 19 autres pourraient les activer avec seulement de légers ajustements de leurs protocoles.
Bien que conçues comme garde-fous contre les hacks et les transferts illicites, ces conclusions relancent une question de longue date : à quel point les systèmes qui sous-tendent l’industrie crypto sont-ils réellement décentralisés ?
L’enquête a été déclenchée par un incident très médiatisé : plus tôt cette année, la Sui Foundation a gelé plus de 160 millions de dollars d’avoirs volés après le hack du DEX Cetus, une intervention rapide qui a suscité un vif débat.
Si une fondation peut bloquer le portefeuille d’un hacker pour protéger les utilisateurs, qu’est-ce qui l’empêche de geler celui de n’importe qui d’autre ?
Ce rapport intervient dans le sillage des propres déboires de sécurité de Bybit.
Il y a seulement quelques mois, la plateforme a subi un hack massif de 1,5 milliard de dollars, l’un des plus importants de l’histoire de la crypto. Dans ce cas, des acteurs centralisés sont intervenus : des partenaires comme Circle et Tether ont gelé environ 42,9 millions de dollars de stablecoins volés, et d’autres protocoles ont aidé à récupérer des fonds supplémentaires.
La capacité d’appuyer sur « pause » en cas d’urgence présente clairement des avantages. Mais elle met aussi en évidence un paradoxe : plus les réseaux crypto s’appuient sur ces « interrupteurs d’arrêt » pour contenir les menaces, plus ils commencent à ressembler aux systèmes centralisés traditionnels qu’ils cherchaient à remplacer.

Geler des fonds crypto : défense contre les hacks vs risque pour la décentralisation
Sur une blockchain, « geler » un compte signifie arrêter le mouvement de ses fonds – les rendre effectivement immobiles.
En pratique, cela se fait généralement par les producteurs de blocs (validateurs) ou par des changements de règles du protocole qui empêchent une adresse sur liste noire de transacter. De tels pouvoirs d’urgence sont apparus en réponse aux hacks et fraudes endémiques qui frappent la DeFi.
La logique est simple : si des voleurs dérobent des millions en crypto, les stopper on‑chain avant qu’ils ne puissent les blanchir.
Par exemple, après l’exploit de 160 M$ sur Sui visant Cetus, la fondation a rapidement mis en place une liste de refus au niveau du protocole pour geler les portefeuilles du hacker.
De même, les développeurs de la BNB Chain BNB ont codé en dur une liste noire pour stopper le mouvement de 570 M$ siphonnés lors d’un hack de pont cross‑chain en 2022. Dès 2019, VeChain avait adopté une liste noire similaire après le vol de 6,6 millions de tokens depuis le portefeuille de sa fondation.
Ces interventions se sont révélées pragmatiquement efficaces pour contenir les pertes.
« Personne ne veut voir disparaître des centaines de millions », comme l’a fait remarquer un analyste du secteur.
En gelant les actifs volés, les projets gagnent du temps pour enquêter, récupérer les fonds ou négocier avec les attaquants. Dans le cas de Sui, un vote de gouvernance communautaire a finalement approuvé la récupération des fonds gelés du hack de Cetus, restituant de la valeur aux victimes.
D’un point de vue purement sécuritaire, la capacité de mettre en pause les transactions est un outil puissant dans la boîte à outils de réponse aux catastrophes des opérateurs de blockchain.
Cependant, le même pouvoir qui peut arrêter un braquage peut aussi saper l’ethos central de la décentralisation. Des transactions immuables et résistantes à la censure sont censées être une caractéristique fondamentale des blockchains publiques – « le code fait loi ». L’idée qu’un groupe central puisse rétroactivement stopper ou inverser des transactions va à l’encontre de ce principe.
Les critiques soutiennent que si une autorité peut unilatéralement geler des avoirs sur un registre, cela remet en cause la neutralité du réseau.
Après le gel d’urgence sur Sui, par exemple, certains membres de la communauté y ont vu une « trahison des idéaux de la décentralisation », soulignant qu’un réseau soi‑disant sans permission révélait un point de contrôle très permissionné. Cela soulève des questions inconfortables : qui, exactement, a l’autorité de basculer l’interrupteur d’arrêt sur une chaîne « décentralisée » ? Dans quelles circonstances ? Et de tels pouvoirs pourraient‑ils être abusés ou étendus à l’avenir ?
Le nouveau rapport de Bybit met en lumière ce compromis croissant entre sécurité et souveraineté. Sa conclusion clé est que ces fonctions de gel ne sont pas des exceptions rares – elles sont plus courantes (et discrètement implantées) que la plupart des utilisateurs ne le pensent. Sur 166 blockchains analysées, 16 (près de 10 %) avaient des mécanismes de gel natifs codés. Fait crucial, ces 16 incluent nombre des plus grands réseaux mondiaux, qui représentent ensemble plus de 80 % de la valeur totale verrouillée en DeFi. Autrement dit, l’essentiel de l’activité crypto actuelle passe par des systèmes qui peuvent être arrêtés, filtrés ou gelés par quelqu’un, au moins dans certaines conditions. Cette réalité heurte l’idée répandue que les blockchains échappent au contrôle de quiconque.
D’un point de vue gouvernance, les risques de centralisation sont évidents.
Les chercheurs du Lazarus Lab ont noté que près de 70 % des événements de gel documentés se produisaient au niveau des validateurs ou du consensus – un niveau profond du protocole, non visible immédiatement pour les utilisateurs ordinaires. Dans de nombreux cas, ces « contrôles d’urgence » ont été exercés par un petit groupe d’initiés : développeurs principaux du projet, conseil de fondation ou groupe de validateurs majeurs. Ces entités ne sont pas toujours transparentes dans leur prise de décision. Contrairement au code open‑source de la blockchain, ces processus de gouvernance humaine se déroulent souvent à huis clos ou dans l’urgence.
Ce manque de visibilité alimente la crainte que la confiance soit réintroduite dans des systèmes censés être « sans confiance ». Comme l’a résumé un observateur, la décentralisation s’arrête souvent là où commence l’accès des validateurs.

Comment fonctionnent les mécanismes de gel
Le rapport de Bybit identifie trois grandes catégories de fonctionnalités de gel on‑chain.
Listes noires codées en dur
Logique de gel écrite directement dans le code source de la blockchain. Des adresses spécifiques peuvent être bloquées au niveau du protocole via des mises à jour de code. Cette méthode – utilisée par BNB Chain, VeChain et d’autres – nécessite la publication d’un nouveau logiciel (ou d’un hard fork) pour ajouter ou retirer des adresses bannies. La liste noire est publiquement visible dans la base de code, mais seuls les développeurs du protocole ou des parties autorisées peuvent la modifier via une mise à jour.
Gel via fichiers de configuration
Une approche plus discrète, où les validateurs ou opérateurs de nœuds chargent une liste noire privée via des fichiers de configuration (par ex. YAML, TOML) que le logiciel consulte lors de la production des blocs.
Ce gel « basé sur la configuration » ne nécessite pas de modifier la base de code publique ; à la place, les opérateurs du réseau se mettent discrètement d’accord pour mettre à jour un fichier de paramètres avec les adresses à bloquer, puis redémarrent leurs nœuds. Aptos, Sui et Linea sont des exemples de blockchains de couche 1 disposant de cette capacité, gérée essentiellement par le consensus des validateurs hors‑chaîne. Puisque ces listes noires résident dans les configs des nœuds, elles ne sont généralement pas visibles du public, ce qui accentue les problèmes de transparence.
Gels via contrats on‑chain
Un contrat intelligent au niveau système qui peut immédiatement mettre sur liste noire ou « dégeler » des comptes via des commandes on‑chain. Il agit comme un contrat administratif doté d’une autorité sur le traitement des transactions.
La Heco (Huobi Eco) Chain est un cas notable : elle implémente un contrat que les validateurs consultent pour déterminer si une adresse est interdite de transaction. Ce modèle peut être plus dynamique (pas besoin de redémarrer les nœuds pour mettre à jour la liste), mais en fin de compte une clé d’admin ou une gouvernance privilégiée contrôle les entrées de ce contrat.
Implémentations pratiques
Chaque approche, en pratique, confère à un petit groupe le pouvoir d’arrêter des transactions sur le réseau – un rôle traditionnellement réservé aux banques ou aux régulateurs dans l’ancien système financier.
Ce qui est remarquable, c’est la discrétion avec laquelle ces contrôles ont été insérés dans l’architecture de diverses blockchains. Dans de nombreux projets, il y a eu peu de communication ou de documentation claire pour informer les utilisateurs de l’existence d’un tel « bouton pause ».
Souvent, la fonctionnalité est enfouie dans les dépôts de code ou les instructions de configuration, et non mise en avant dans les livres blancs ou les documents d’onboarding.
Cela signifie que les utilisateurs, et même de nombreux développeurs, peuvent ignorer l’existence d’un mécanisme de gel sur une chaîne jusqu’à ce qu’il soit activé en situation de crise.
Selon le rapport, 10 des 16 blockchains dotées de capacités de gel s’appuient sur la méthode des fichiers de configuration, donnant aux validateurs la possibilité d’imposer des listes noires privées en mettant à jour les paramètres des nœuds. Aptos, Sui, EOS et plusieurs autres entrent dans cette catégorie.
Comme les entrées de la liste noire résident dans des configs locales, le réseau semble normal pour les observateurs externes – rien dans le registre public n’indique explicitement les adresses gelées. Seuls les initiés qui coordonnent le gel (et d’éventuels explorateurs de blocs qui relèvent ensuite l’absence de transactions à partir de ces adresses) révèlent qu’une intervention a eu lieu.
Cinq autres des 16 chaînes possèdent des fonctions de gel codées en dur dans leur code source.
Les analystes de Bybit citent la BNB Chain de Binance, VeChain, Chiliz, « VIC » (un réseau plus modeste identifié dans le rapport) et le XDC Network de XinFin comme exemples. Dans ces systèmes, les développeurs ont intégré une logique de liste noire directement dans les règles de consensus – un filet de sécurité résolument centralisé. Par exemple, la base de code de BNB Chain contient une liste explicite d’adresses bloquées que les validateurs n’incluront pas dans les blocs. Modifier cette liste requiert une mise à jour de code (généralement orchestrée par l’équipe centrale de Binance). VeChain a de même ajouté un « module de liste noire » codé en dur après son hack de 2019, tout en affirmant que son activation a été approuvée par vote communautaire et qu’il ne s’agit pas d’une porte dérobée permanente (nous y reviendrons plus loin).
La seizième chaîne (Heco) utilise exclusivement l’approche du contrat intelligent on‑chain.
Fait notable, Tron – qui était également signalé dans le rapport – dispose aussi d’un module de liste noire avec autorisations intégrées, qui fonctionne d’une manière un peu analogue à un appel de contrat initié par la Tron Foundation pour geler des comptes (le mécanisme de Tron n’était pas détaillé dans le résumé de Bybit, mais on sait d’incidents précédents que les nœuds Tron peuvent être instruits de rejeter les transactions provenant de certaines adresses).
Dans tous les cas, qu’il s’agisse d’un gel basé sur le code, la configuration ou un contrat, le résultat est le même : certaines adresses peuvent être rendues incapables de transacter, à la discrétion de ceux qui contrôlent cette fonctionnalité.
Discrètement, une sorte de modèle de contrôle de gel s’est propagé à travers différents écosystèmes blockchain.
En passant au peigne fin les dépôts GitHub, l’équipe de Bybit a trouvé des schémas récurrents – des hooks dans le code de traitement des transactions, des références à des variables de « blacklist » ou des vérifications par rapport à certaines listes de comptes. Ceux-ci étaient présents dans des projets et des langages disparates (par exemple, des chaînes basées sur l’EVM comme BNB et Chiliz vs. des chaînes basées sur Rust comme Sui et Aptos), ce qui suggère que les développeurs ont indépendamment convergé vers l’idée qu’une blockchain devrait disposer d’un frein d’urgence. Ce qui a commencé comme des réactions ad hoc à des crises semble devenir une considération standard de conception. Et, fait important, ces contrôles concentrent souvent le pouvoir entre les mains de ceux qui maintiennent le code ou exploitent les nœuds validateurs principaux. Comme le note sèchement le rapport, la décentralisation « finit souvent là où commence l’accès aux validateurs ».

16 grandes blockchains dotées de capacités de gel
Les recherches de Bybit ont identifié seize blockchains publiques qui disposent actuellement de fonctionnalités natives pour geler des comptes ou des transactions. Voici la liste de ces réseaux et le mécanisme connu par lequel ils peuvent verrouiller des fonds :
- Ethereum (ETH) – Peut mettre en œuvre une pause d’urgence via une intervention de gouvernance (par exemple au moyen d’une mise à niveau du réseau ou de hooks EIP similaires à l’EIP-3074 proposé). Bien qu’Ethereum n’ait pas une simple fonction de « blacklist » intégrée, les développeurs pourraient pousser un fork spécial ou utiliser une logique de contrat pour obtenir un gel dans des situations extraordinaires, comme l’a montré le rollback du DAO en 2016.
- BNB Chain (BNB) – Utilise un consensus de liste noire piloté par les validateurs. La chaîne soutenue par l’exchange de Binance possède des fonctions de gel codées en dur ; ses validateurs, coordonnés par l’équipe centrale de Binance, peuvent refuser de traiter des transactions provenant d’adresses figurant sur une liste noire interne.
- Polygon (POL) – Met en œuvre un filtrage dynamique des adresses dans les pools de transactions. Les nœuds de Polygon peuvent être configurés (via des forks ou des mises à jour) pour filtrer les transactions impliquant certaines adresses, empêchant de fait les comptes sur liste noire d’être inclus dans de nouveaux blocs.
- Solana (SOL) – Prend en charge des mises à jour de configuration à l’exécution pour le blacklistage. La conception de Solana permet à l’équipe centrale ou à l’entité de gouvernance de déployer rapidement des modifications de configuration à l’échelle du réseau. En théorie, cela pourrait être utilisé pour déployer une liste noire au niveau du logiciel des validateurs ou pour bloquer certains comptes.
- Avalanche (AVAX) – Propose des arrêts de transactions déclenchés par la gouvernance. Avalanche peut utiliser sa gouvernance on-chain (via le vote des validateurs) pour mettre en œuvre des arrêts d’urgence ou des restrictions spécifiques à certaines adresses sur sa C-Chain et ses sous-réseaux, si une supermajorité de validateurs est d’accord.
- Tron (TRX) – Module de liste noire intégré à son protocole. Le réseau Tron, supervisé par la Tron Foundation, dispose d’une fonctionnalité permettant aux autorités de geler des comptes (par exemple pour se conformer aux demandes des forces de l’ordre ou se protéger contre des piratages, comme on l’a vu lors d’incidents passés impliquant des actifs basés sur TRON).
- Cosmos (écosystème ATOM) – Pause du module IBC et interdiction d’adresses. Cosmos et ses blockchains basées sur le SDK n’ont pas encore utilisé de gels globaux, mais le système de communication inter-chaînes (IBC) et les comptes de module pourraient être exploités pour interrompre des transferts ou mettre des adresses sur liste noire dans plusieurs zones via une mise à niveau coordonnée.
- Polkadot (DOT) – Gels propres aux parachains via la Relay Chain. La gouvernance de Polkadot peut appliquer des mises à jour de runtime sur les parachains. En cas d’urgence, la relay chain pourrait imposer un gel ou un revert pour une parachain ou une adresse problématique, sous réserve du vote on-chain de Polkadot.
- Cardano (ADA) – Hard forks avec exclusion d’adresses. Cardano n’a pas d’opcode de gel simple, mais, via ses mises à niveau combinatoires par hard fork, la communauté pourrait introduire des règles excluant certains UTXO ou adresses (par exemple, en ne reconnaissant pas les sorties contrôlées par une clé sur liste noire dans une nouvelle époque).
- Tezos (XTZ) – Votes de gouvernance permettant des gels. Le registre auto-amendable de Tezos pourrait intégrer un mécanisme de gel par amendement du protocole. Si les parties prenantes votaient pour inclure une fonctionnalité de liste noire ou de pause dans une mise à niveau (pour usage d’urgence), celle-ci deviendrait partie intégrante du protocole Tezos.
- Near Protocol (NEAR) – Filtres de transactions au niveau des shards. La conception shardée de NEAR pourrait permettre à ses nœuds de coordination de filtrer ou de refuser les transactions visant des adresses spécifiques dans un shard donné – une capacité qui pourrait être déployée via la gouvernance du protocole lors d’événements extrêmes.
- Algorand (ALGO) – Transferts atomiques avec clés de révocation. Le cadre des actifs standards d’Algorand (ASA) inclut une fonctionnalité d’opt-in permettant l’éditeur de geler et de reprendre la main sur l’actif. Bien que l’ALGO lui-même ne puisse pas être gelé, de nombreux tokens Algorand disposent de contrôles de gel. Algorand prend également en charge des transactions de transfert forcé (si elles sont autorisées), qui imitent un gel en déplaçant des fonds hors d’une adresse sur liste noire.
- Hedera Hashgraph (HBAR) – Contrôles administratifs de gel de tokens. Hedera, gouverné par son conseil d’entreprises, offre des fonctions d’administration intégrées pour les tokens. Des administrateurs approuvés peuvent geler les transferts de tokens ou même effacer des soldes. Le modèle permissionné du réseau signifie que le conseil pourrait probablement aussi bloquer des comptes au niveau du registre si nécessaire.
- Stellar (XLM) – Clauses de clawback et de gel dans l’émission d’actifs. Stellar permet aux émetteurs d’actifs (tokens) d’activer une fonctionnalité de « clawback », qui leur permet de geler ou de récupérer des tokens depuis des portefeuilles utilisateurs sous certaines conditions. Cela a été utilisé par des émetteurs de stablecoins réglementés sur Stellar et équivaut à un mécanisme de gel partiel dans l’écosystème.
- Ripple XRP Ledger (XRP) – Fonctionnalités d’entiercement et de gel de lignes. Le XRP Ledger ne permet pas de geler la monnaie native XRP, mais il autorise les émetteurs de tokens IOU (comme des stablecoins ou des titres sur le registre) à geler globalement des actifs ou des lignes de confiance spécifiques. Le réseau de Ripple prend également en charge le verrouillage de XRP dans des contrats d’entiercement (blocus soumis au temps), ce qui est lié à la restriction des mouvements de fonds.
- VeChain (VET) – Contrôles de transaction basés sur l’autorité. Le système de masternodes d’autorité de VeChain a permis la mise en place d’une liste noire en 2019 après un piratage. La fondation, avec l’approbation de la communauté, a activé des vérifications au niveau du consensus qui ont conduit les validateurs à rejeter toutes les transactions provenant des adresses du pirate – gelant de fait ces fonds.
Il est important de noter que tous les projets ne sont pas d’accord avec la manière dont leur capacité de gel a été caractérisée.
Par exemple, après la publication du rapport de Bybit, l’équipe de VeChain a publiquement contesté l’idée que son protocole disposerait d’un gel permanent codé en dur en tant que tel.
La VeChain Foundation a expliqué que lors de l’incident de 2019, la communauté avait voté l’émission d’un correctif ponctuel – une modification des règles de consensus – qui bloquait les adresses du pirate au niveau des validateurs.
« Le logiciel de VeChainThor inclut des vérifications au niveau du consensus qui, une fois activées via la gouvernance communautaire, ont rendu les actifs inamovibles », a écrit l’équipe, en soulignant que la mesure avait été approuvée par la gouvernance et n’était pas une fonctionnalité toujours active. En d’autres termes, VeChain soutient qu’il n’existe pas d’interrupteur secret de mise à mort en fonctionnement normal ; ils ont simplement amendé le code via la procédure appropriée pour geler ces fonds volés. Cette réponse met en lumière la sensibilité du sujet – aucune blockchain ne souhaite être perçue comme centralisée, même si, en situation d’urgence, elle agit de cette manière.
Les prochains sur la liste : 19 réseaux à quelques clics de pouvoirs de gel
Peut-être plus surprenant que les 16 blockchains dotées de fonctions de gel est l’avertissement du rapport selon lequel 19 autres réseaux pourraient adopter des contrôles similaires avec un effort minimal. Dans de nombreux cas, l’ossature de code pour des listes noires ou la mise en pause de transactions est déjà présente ou facile à ajouter. Il pourrait ne falloir que quelques lignes de code modifiées, ou l’activation d’un simple paramètre de configuration, pour mettre la fonctionnalité en marche.
À quel point cela pourrait-il devenir répandu ? Potentiellement très répandu – si les développeurs jugent que le compromis en vaut la peine.
Bybit’s team did call out several specific projects in this “could easily freeze” category.
Ils ont noté que des chaînes populaires comme Arbitrum, Cosmos, Axelar, Babylon, Celestia et Kava figurent parmi celles qui pourraient activer le gel de fonds avec des modifications de protocole relativement mineures. Ces réseaux ne mettent actuellement en avant aucune capacité de gel, mais leurs architectures sont telles qu’en introduire une ne serait pas difficile.
Par exemple, de nombreuses chaînes basées sur Cosmos utilisent un système de comptes de module (pour des éléments comme les comptes de gouvernance ou de collecte de frais).
Comme les chercheurs l’ont observé, ces comptes de module pourraient être ajustés pour refuser les transactions sortantes provenant de certaines adresses. Jusqu’à présent, aucune blockchain de l’écosystème Cosmos n’a utilisé cela pour mettre un utilisateur sur liste noire – le faire nécessiterait un hard fork approuvé par la gouvernance avec un petit changement de code dans la logique de gestion des transactions. Mais le fait que ce soit réalisable via une mise à jour simple signifie que le plan existe déjà, en attente d’une décision.
En pratique, l’activation d’une fonctionnalité de gel sur ces chaînes supplémentaires suivrait probablement un schéma familier : un piratage majeur ouLa pression réglementaire pourrait inciter les développeurs à dire : « Nous avons besoin de cet outil. » En effet, après le hack et le gel des 162 M$ de Sui, le réseau Aptos (une autre blockchain utilisant le langage Move) a discrètement ajouté une capacité de mise sur liste noire dans son code dans les semaines qui ont suivi. Ils avaient compris le message : sans mécanisme de gel, ils auraient peu de recours si une exploitation similaire frappait leur écosystème.
Cela montre comment le précédent établi par un projet peut influencer les autres. Si quelques autres incidents très médiatisés se produisent, il est facile d’imaginer une cascade de blockchains implémentant rapidement des commutateurs de gel latents « juste au cas où ».
La prévalence de schémas de code similaires suggère un certain degré de convergence de l’industrie sur cette question. « Ce n’est pas une anomalie – c’est en train de devenir un modèle industriel », indique le rapport à propos de la logique de gel on-chain. De nombreuses nouvelles blockchains semblent avoir tiré des leçons (pour le meilleur ou pour le pire) des hacks précédents sur des réseaux plus anciens.
Elles peuvent inclure dans leur conception des hooks qui permettent des actions centralisées optionnelles, même si elles ne les mettent pas en avant.
Dans certains cas, ces hooks ont été repérés par l’outil de scan IA de Bybit : l’équipe a exploité un modèle d’IA (Claude 4.1 d’Anthropic) pour analyser des centaines de dépôts à la recherche de mots‑clés et de structures de code liés à la mise sur liste noire et au filtrage des transactions.
Cet assistant IA a signalé des dizaines de cas potentiels à travers divers projets.
Tous n’étaient pas de véritables fonctions de gel – certains faux positifs concernaient des fonctionnalités au niveau utilisateur qui n’étaient pas réellement des contrôles au niveau du protocole. Mais le fait qu’il ait fallu recourir à l’automatisation pour trier l’ampleur potentielle du phénomène souligne à quel point les frontières du « contrôle décentralisé » sont devenues floues.
Les chercheurs ont dû vérifier manuellement chaque cas au final, illustrant que même des experts peuvent peiner à discerner là où une blockchain dissimule des leviers de contrôle.
Le rapport de Bybit insiste sur le fait que l’existence de capacités de gel dans un plus grand nombre de réseaux n’est pas hypothétique. C’est déjà la norme dans l’esprit, sinon dans la lettre. La seule différence est de savoir si un projet a déjà actionné l’interrupteur. Beaucoup pourraient le faire via un hard fork ou même un changement de configuration au runtime, ce qui signifie que l’ethos d’une immutabilité absolue est, en pratique, compromis. Nous évoluons vers un paysage où une majorité de chaînes disposent d’un certain degré de « bouton d’arrêt » – soit actif, soit en attente. Cela renforce l’enjeu de la transparence : si ces interrupteurs sont omniprésents, les utilisateurs et les investisseurs voudront savoir exactement qui peut les actionner et comment.

Sécurité pragmatique ou centralisation cachée ?
Le débat autour de ces conclusions se résume essentiellement à un dilemme classique : les bénéfices d’une intervention d’urgence l’emportent‑ils sur les coûts en matière de décentralisation ?
Les partisans des fonctions de gel soutiennent qu’il s’agit d’une mesure de sécurité pragmatique – une option nécessaire dans un monde où les hacks, les exploits et les vols sont omniprésents. Le rapport documente d’ailleurs la façon dont les gels ont permis de sauver des montants considérables. L’action rapide de Sui après le hack du DEX Cetus a potentiellement permis d’éviter que 162 M$ ne soient siphonnés à jamais.
La mise sur liste noire de BNB Chain lors de son exploit de 2022 a aidé à contenir une brèche de 570 M$, empêchant une contagion plus large dans l’écosystème Binance. Le gel par VeChain, en 2019, de 6,6 M$ de tokens volés a protégé le trésor du projet et les fonds de la communauté d’une perte irrémédiable. Chacun de ces événements aurait pu être dévastateur ; la capacité d’intervenir les a rendus douloureux plutôt que fatals.
« Sans ces mécanismes, des hacks comme celui de Cetus ou l’exploit du bridge BNB auraient anéanti les investisseurs », note le rapport pour défendre ces dispositifs.
Cependant, chaque fois qu’une blockchain exerce ce type de pouvoir d’override, elle érode un peu plus l’ethos fondamental de confiance sans intermédiaire de la technologie blockchain. La résistance à la censure – la garantie que personne ne peut empêcher des transactions valides – est une grande partie de la raison pour laquelle les gens font confiance aux réseaux décentralisés. Si les utilisateurs en viennent à penser qu’une fondation ou un comité peut intervenir et geler des fonds à volonté, la distinction psychologique (et juridique) avec les banques traditionnelles commence à s’estomper. Les chercheurs de Bybit avertissent que même des gels bien intentionnés créent un précédent :
« Une fois qu’une chaîne gèle des fonds une première fois, il est difficile d’imaginer qu’elle ne le fera plus », écrivent‑ils. La crainte est que ce qui commence comme une mesure exceptionnelle puisse se transformer en outil routinier de contrôle.
Il existe des preuves que la ligne se déplace déjà.
Selon les données du rapport, près de 70 % des événements de gel documentés se sont produits via des actions au niveau du consensus par les validateurs ou les producteurs de blocs. C’est significatif, car il s’agit du niveau le plus profond du système – ce qui signifie que la censure était intégrée à la production de blocs elle‑même, et pas seulement à un niveau applicatif superficiel. Les utilisateurs lambda ne s’en rendraient même pas compte ; la chaîne cesse simplement de traiter les transactions provenant de certaines adresses, sans aucune explication fournie on-chain.
Dans la majorité des cas, les décisions de geler ont été prises par de petits conseils de gouvernance, des équipes de fondation ou des groupes de développeurs core.
Il s’agit souvent d’organes non élus, ou, lorsqu’ils le sont (comme certains ensembles de validateurs), ils sont généralement dominés par des initiés et ne sont pas directement responsables devant des millions d’utilisateurs à travers le monde. De tels gels peuvent donc ressembler aux actions d’une banque centrale ou à un décret gouvernemental, exécuté sans les freins et contrepoids que la décentralisation était censée garantir.
L’opacité entourant ces actions d’urgence constitue une grande partie du problème.
Dans le cas de Sui, la coordination pour geler les fonds s’est faite via des accords en coulisses entre validateurs, orchestrés par la Sui Foundation. Il n’y a pas eu de proposition on-chain ni de vote préalable des utilisateurs ; c’était une réponse urgente.
De même, la nouvelle fonctionnalité de gel d’Aptos serait gérée via les fichiers de configuration privés des validateurs, et « seules quelques personnes savent » qui maintient la liste noire ou comment ces décisions sont prises. Cette approche furtive peut être efficace en situation de crise, mais elle met la communauté à l’écart et manque de transparence.
Même sur BNB Chain, qui est relativement transparente au sujet de sa liste noire codée en dur, le contrôle « repose fermement entre les mains du noyau de développeurs de Binance », relève l’analyse. Autrement dit, la décision ultime de qui est mis sur liste noire sur BNB revient de fait à la direction de Binance – une structure d’autorité qui ressemble davantage à une entreprise qu’à un projet communautaire décentralisé. Et dans le cas du gel basé sur contrat d’Heco, une clé d’administration détenue par les opérateurs du protocole peut décider quelles adresses vivent ou meurent sur le réseau.
Pour les critiques, ces réalités valident des soupçons de longue date selon lesquels nombre de blockchains prétendument décentralisées ne le sont que de nom. « Les frontières entre fondation, validateur et régulateur se brouillent rapidement », comme l’a observé un commentaire. Quand la situation se corse, la plupart des grands réseaux peuvent agir très exactement comme des intermédiaires centralisés : ils peuvent geler des fonds, annuler des transactions ou gouverner autrement l’activité des utilisateurs d’une manière dont ces derniers n’ont peut‑être pas conscience.
La communauté crypto a déjà connu des débats analogues autour de questions comme la conformité aux sanctions de l’OFAC, lorsque des validateurs Ethereum ont commencé à censurer des adresses sanctionnées dans les blocs en 2022. Là encore, cela a été perçu comme une pente glissante où des pressions externes ont conduit à l’émergence de comportements de facto centralisés au sein d’un système censé être décentralisé.
À l’inverse, les défenseurs des pouvoirs d’urgence soutiennent qu’une certaine capacité d’intervention fait simplement partie de la « maturisation » de la crypto. À mesure que les plateformes blockchain deviennent grand public et supportent des milliards en valeur, la réalité des hacks et de la criminalité ne peut être ignorée.
Même les décentralistes les plus farouches pourraient concéder que si leurs propres fonds étaient volés, ils accueilleraient favorablement un gel bien chronométré pour les récupérer. L’essentiel, peut‑être, est de garantir une bonne gouvernance et une transparence adéquate autour de ces capacités.
David Zong, responsable de la sécurité chez Bybit et auteur principal de la recherche, l’a formulé ainsi : la blockchain a peut‑être été construite sur la décentralisation, « mais notre recherche montre que de nombreux réseaux développent des mécanismes de sécurité pragmatiques pour répondre rapidement aux menaces ».
L’élément crucial, dit‑il, est que « la transparence crée la confiance » – ce qui signifie que si de tels mécanismes existent, ils devraient être divulgués ouvertement et soumis à une supervision, et non cachés dans le code.
Le pire scénario serait l’existence de portes dérobées ou de boutons de gel secrets que les utilisateurs découvrent seulement quand il est trop tard.
À l’inverse, si un projet déclare ouvertement qu’il conserve un frein d’urgence et fournit une politique claire sur la manière et les circonstances de son utilisation (par exemple uniquement pour des hacks au‑dessus d’un certain montant, nécessitant une approbation multisig, etc.), les utilisateurs et les investisseurs peuvent juger eux‑mêmes du compromis.
La réponse de VeChain, déjà mentionnée, est illustrative. Ils n’ont pas nié avoir gelé des fonds – ils ont défendu la manière dont cela a été fait, la présentant comme une action gouvernée par la communauté plutôt qu’une décision unilatérale. Cela suggère un possible juste milieu : tout gel devrait être mis en œuvre via une forme de processus décisionnel décentralisé. Dans le cas de VeChain, ils affirment que les détenteurs de tokens ont approuvé la liste noire. Dans le cas de Sui, après coup, un vote communautaire a ratifié le plan de récupération. Même si ces étapes de gouvernance peuvent être imparfaites (les critiques noteront que l’influence des fondations peut souvent orienter les votes ou que l’urgence ne permet pas de longs débats), elles tentent au moins de s’aligner sur les principes de décentralisation. L’alternative – une poignée de développeurs core qui prennent toutes les décisions – se rapproche dangereusement des systèmes centralisés que la crypto cherchait à dépasser.
Près d’un an après le « fork DAO » historique d’Ethereum en 2016 – sans doute la première intervention sur des fonds on-chain – l’industrie se débat toujours avec la même question fondamentale : les blockchains devraient‑elles jamais intervenir dans l’activité on-chain, même pour corriger une injustice ?
Il n’y aura peut‑être jamais de réponse universelle. Différents réseaux adoptent différentes positions, de l’immutabilité absolutiste de Bitcoin (même les vols datant de l’ère Satoshi ne peuvent être annulés) aux chaînes plus flexibles, fortement gouvernées comme Tezos ou Polkadot, qui permettent explicitement des altérations menées par la communauté. Ce qui est clair, c’est que la présence deces mécanismes de gel brouillent la dichotomie entre centralisé et décentralisé.
De nombreux réseaux occupent une zone grise entre les deux – décentralisés dans leur fonctionnement quotidien, mais dotés de capacités de reprise de contrôle centralisée dans des scénarios extrêmes. Que l’on voie cela comme une gestion prudente des risques ou comme un compromis fatal dépend sans doute de sa philosophie et peut‑être du fait d’avoir déjà été du mauvais côté d’un hack.
Closing Thoughts
Le rapport de Bybit a levé le voile sur une vérité dérangeante : la capacité de geler des fonds fait désormais partie du paysage blockchain, en particulier parmi les principaux réseaux.
Le choix auquel l’industrie est confrontée n’est plus simplement « centralisation vs décentralisation ». Il s’agit de gouvernance transparente vs contrôle occulte.
Les projets qui admettent ouvertement leurs pouvoirs et les placent sous des mécanismes de contrôle démocratique peuvent préserver leur crédibilité – ils diront : nous sommes largement décentralisés, sauf en cas d’urgence absolue, et voici exactement comment cela fonctionne.
À l’inverse, si ces pouvoirs restent opaques et sans contrôle, ce n’est qu’une question de temps avant qu’ils ne sèment la méfiance ou ne soient utilisés abusivement. À mesure que le contrôle réglementaire s’intensifie, certaines juridictions pourraient même imposer des capacités de gel on‑chain (l’UE et Singapour ont déjà évoqué des idées de dispositions « frein d’urgence » dans la loi). Les investisseurs institutionnels, eux aussi, pourraient préférer des réseaux capables de maîtriser le risque, même si cela implique de sacrifier une partie de la décentralisation.
Cela pourrait conduire à une scission entre des blockchains « conformes » pouvant intervenir et des blockchains « puristes » qui refusent toute intervention, ce qui transformerait en profondeur l’identité de l’écosystème crypto.
Au final, la décentralisation dans la crypto ne disparaît pas – mais elle mûrit et se confronte à des épreuves de réalité difficiles.





