Liquid : comment près de 4 000 BTC ont quitté la réserve sans vol de clés

Liquid Network a suspendu l’activité de son pont après le retrait d’environ 4 000 BTC — valorisés autour de 320 millions de dollars à ce moment-là — depuis le portefeuille de la fédération qui garantit le L-BTC. Ce retrait représentait environ 95 % de la réserve alors déclarée. Les éléments disponibles renvoient à un supposé bug d’inflation du logiciel Elements, et non au vol des clés d’autorisation de la fédération ou de SideSwap. Les détails techniques publics restent toutefois incomplets. 413

Le scénario rapporté

La chronologie rapportée est relativement simple, même si la faille elle-même n’a pas été entièrement détaillée :

1. Un acteur aurait créé du L-BTC sans BTC verrouillés en garantie, en exploitant un défaut du logiciel Elements.
2. Ce L-BTC aurait été présenté au service habituel de peg-out de SideSwap.
3. Le retrait aurait emprunté la clé d’autorisation de peg-out (Peg-out Authorization Key, ou PAK) de SideSwap, que Liquid et SideSwap disent ne pas avoir été compromise.
4. L’infrastructure de la fédération Liquid aurait alors autorisé un retrait sur Bitcoin : les informations disponibles évoquent environ 3 996 BTC versés, pour un événement proche de 4 000 BTC au total. 26

Autrement dit, le problème rapporté ne serait pas le vol des clés qui contrôlent la réserve. Le système aurait plutôt accepté un retrait parce que les contrôles d’autorisation le considéraient comme valide, alors que le L-BTC présenté n’aurait pas eu de garantie économique légitime.

Pourquoi les HSM ont pu signer sans compromission de clé

Liquid repose sur un modèle de Strong Federation : des membres de la fédération exploitent collectivement la sidechain et contrôlent la réserve BTC via des signatures à seuil. La documentation technique de Liquid décrit ce modèle de consensus comme une Strong Federation.

Les modules matériels de sécurité, ou HSM (hardware security modules), protègent les clés de signature et appliquent des règles préconfigurées. Ils ne constituent pas pour autant un arbitre indépendant de toute l’historique nécessaire pour déterminer si un actif est réellement couvert.

Si une demande de peg-out présente des éléments que le système reconnaît comme valides — dont un parcours d’autorisation valide — les HSM peuvent signer sans qu’aucune clé privée ait été dérobée.

C’est la distinction centrale de cet incident :

• Autorisation : le peg-out aurait été traité au moyen de la PAK légitime de SideSwap.
• Origine et garantie : le L-BTC présenté au rachat aurait, selon les allégations, été créé par un bug d’Elements et non par l’émission normale contre des BTC verrouillés. 2

SideSwap a indiqué que le peg-out d’environ 4 000 BTC était passé par son service comme une commande client, que sa PAK n’avait pas été compromise et que le L-BTC provenait d’un bug d’Elements, non de ses propres systèmes.

La leçon n’est donc pas que la cryptographie des HSM ou les signatures à seuil auraient échoué. Un défaut partagé dans la validation ou l’émission peut amener des signataires automatisés fonctionnant correctement à approuver un retrait qui n’aurait jamais dû être admissible. Une signature valide prouve que la politique de signature a été satisfaite ; elle ne prouve pas, à elle seule, que l’actif racheté était correctement garanti.

Les auteurs sont-ils vraiment des « white hats » ?

Les acteurs ont laissé un message on-chain : « we are whitehats. contact us on chain » (« nous sommes des white hats, contactez-nous on-chain »). 16

Selon les informations publiées, Blockstream/Liquid les a contactés via des messages on-chain signés. Les acteurs auraient proposé de restituer « la plupart » des fonds après le déploiement du correctif de vulnérabilité sur l’ensemble du réseau. 418

Ces éléments montrent qu’ils revendiquent une démarche de recherche en sécurité et ont laissé un canal de communication. Ils ne démontrent pas indépendamment leur statut de white hats. Au moment des informations citées, aucun retour des fonds, correctif public ni redémarrage du réseau n’avait été confirmé. 13

L’expression la plus exacte reste donc « prétendus white hats ». Cette qualification ne devrait pas être considérée comme établie avant une restitution effective des fonds, une publication des détails de l’exploit et une remédiation vérifiable.

Réponse de Liquid, SideSwap et des plateformes

Liquid a désactivé les nœuds du pont et suspendu ses opérations, empêchant les mouvements habituels entre Bitcoin et Liquid. Les plateformes d’échange ont été informées afin de suspendre, ou de se préparer à suspendre, les dépôts et retraits de L-BTC. 48

SideSwap a précisé avoir interrompu les peg-ins et les peg-outs tant que Liquid reste en pause.

Ces mesures visent à contenir l’incident : elles limitent les mouvements supplémentaires pendant que les opérateurs examinent la vulnérabilité signalée, la situation des réserves et les conditions d’une reprise sûre. Le plan de rétablissement rapporté dépendait d’un correctif, de la mise à jour des nœuds affectés et de la résolution du statut des BTC retirés. 1318

Ce que cela implique pour les détenteurs de L-BTC

Le L-BTC est conçu comme du bitcoin sur Liquid. Mais son équivalence pratique avec du BTC immédiatement récupérable sur la blockchain Bitcoin dépend de la disponibilité du pont et de la crédibilité de sa garantie.

Avec environ 4 000 BTC retirés d’une réserve annoncée autour de 4 200 BTC, et le pont suspendu, le rachat ordinaire de L-BTC a été perturbé. Le déficit de réserve rapporté est ainsi devenu le problème immédiat pour les détenteurs. 313

Cela ne permet pas de conclure au résultat final. En revanche, pendant l’incident, détenir du L-BTC n’était pas opérationnellement équivalent à détenir du BTC librement retirable sur la couche de base de Bitcoin. L’issue dépendra de la récupération éventuelle des fonds, de la correction du bug allégué, des décisions de la fédération et des politiques des prestataires.

Les autres actifs émis sur Liquid

Les autres actifs sur Liquid ne sont pas automatiquement retirés des réserves de leurs propres émetteurs parce que des BTC ont quitté le portefeuille de la fédération. Liquid a déclaré que des actifs comme USDT, DePix et les RWA n’étaient pas directement affectés par l’incident.

Mais « non affecté » ne signifie pas « sans risque ». Une suspension du réseau peut perturber l’accès aux portefeuilles, le soutien des plateformes, la liquidité, la disponibilité des transactions et l’utilisation du L-BTC — actif servant aux frais et aux transferts via le pont. La garantie directe de chaque actif dépend toujours de son émetteur et de son dispositif de conservation, tandis que son utilisabilité dépend du retour à la normale de l’infrastructure Liquid.

La leçon d’architecture : fédération actuelle contre pont BitVM envisagé

Le design actuel de Liquid repose sur une fédération connue et autorisée, qui contrôle la réserve Bitcoin via des signatures à seuil. Ce modèle diffère d’un système dans lequel le consensus Bitcoin vérifierait directement que chaque rachat est couvert.

Pont fédéré actuel	Piste BitVM de type 1-sur-n envisagée
Une fédération fixe contrôle la réserve Bitcoin par signatures à seuil.	Blockstream présente cette approche comme un programme de recherche à plus long terme, et non comme un remplacement déjà déployé de Liquid.
La sécurité dépend de la protection des clés, des opérations des signataires et de la fiabilité du logiciel partagé de validation et de politique.	L’objectif est de réduire les hypothèses de confiance par rapport aux modèles conventionnels à signatures à seuil.
Un défaut logiciel commun peut potentiellement conduire tous les signataires automatisés à accepter la même interprétation invalide.	Les systèmes de type BitVM s’appuient sur une vérification optimiste et des mécanismes de contestation ; leur sécurité dépend d’un protocole correct et d’au moins un acteur honnête et actif capable de contester.

Un modèle de type BitVM ne supprime pas le risque des ponts. Il le déplace vers d’autres hypothèses : les contestataires doivent pouvoir et vouloir intervenir, le mécanisme de preuve de fraude doit être correct, et les retraits peuvent devenir plus complexes ou plus lents. Les travaux sur les ponts fondés sur BitVM décrivent un modèle de sécurité nécessitant au moins un participant honnête ; BitVM2 vise pour sa part à permettre à n’importe qui de contester une assertion invalide durant l’exécution.

Si le mécanisme rapporté est confirmé, l’incident Liquid illustre l’importance de cette différence. Une fédération à signatures à seuil peut résister au vol de clés tout en restant exposée lorsqu’un défaut logiciel partagé amène chaque signataire à valider à tort qu’un actif est admissible au rachat.

À retenir

L’événement Liquid estimé à 320 millions de dollars ressemble davantage à une crise de validation du pont qu’à un vol classique de clés privées. Un lot de L-BTC prétendument non garanti aurait emprunté un parcours de peg-out pourtant autorisé, poussant la fédération à libérer de vrais BTC. 24

Les questions encore ouvertes sont majeures : la nature exacte de la vulnérabilité d’Elements, la situation définitive des réserves et de la couverture du L-BTC, le retour éventuel des fonds et les contrôles à modifier avant une reprise sûre du pont. Tant que ces réponses ne sont pas vérifiées publiquement, cet épisode doit être considéré comme non résolu — et non comme une divulgation white hat achevée ou une simple interruption de service.