Multisig ou MPC : bien partager la clé après le vol Bitget

Le 24 septembre 2026, une plateforme d’échange qui ne figure même pas dans le trio de tête du marché a signé, malgré elle, le plus gros vol de crypto de l’année. En moins d’une heure, l’équivalent d’environ 342 millions d’euros (387,5 millions de dollars) a quitté les portefeuilles de Bitget, dispersé sur au moins huit blockchains. Aucune clé privée n’a été dérobée. Aucun retrait client n’a été falsifié. Le système a fait précisément ce qu’on attendait de lui : il a autorisé des transferts qu’il tenait pour légitimes.

C’est, à quelques détails près, le scénario de toutes les grandes catastrophes de 2026. Bybit, Drift, Humanity, Liquid Network, Coldcard : à chaque fois, la cryptographie a tenu, et c’est la couche située au-dessus des clés qui a lâché. La bonne question, en 2026, n’est donc plus seulement « combien de signataires faut-il », mais « comment partage-t-on la clé, et à quel endroit ce partage peut-il se retourner contre nous ». Deux grandes familles se disputent la réponse : le multisig, transparent et vérifiable directement sur la chaîne, et le MPC (multi-party computation), plus rapide et plus souple mais logé dans une infrastructure que personne ne peut auditer de l’extérieur. Les deux ne cassent pas au même endroit.

Cet article part du vol Bitget pour remonter, étape par étape, jusqu’aux bonnes pratiques du partage de clé. Les montants sont convertis en euros au taux du 30 septembre 2026 (environ 1,13 dollar pour un euro, selon Trading Economics), les prix crypto proviennent de CoinGecko (Bitcoin autour de 73 700 euros, Ether autour de 2 360 euros au moment d’écrire ces lignes), et chaque chiffre renvoie à sa source. Le fil conducteur tient en une phrase : la première bonne pratique n’est pas un réglage, c’est un choix de modèle.

Bitget : le plus gros vol de 2026, sans une seule clé volée

La chronologie est brutale. Dans la soirée du 24 septembre, des transferts non autorisés commencent à sortir des portefeuilles chauds et tièdes de Bitget, ces réserves opérationnelles que la plateforme garde connectées pour traiter les mouvements courants. En une quarantaine de minutes, l’essentiel est parti. Les audits successifs ont porté la facture à 387,5 millions de dollars (environ 342 millions d’euros), ce qui en fait, selon Fortune, le plus gros vol de crypto de l’année, devant Drift et Liquid Network.

Le point important n’est pas le montant, c’est la méthode. D’après la directrice générale Gracy Chen, qui s’est exprimée pendant un long direct sur X le soir même, aucune clé privée n’a été compromise et aucun retrait d’utilisateur n’a été falsifié. Les attaquants ont visé un système de back-end chargé de traiter les transactions, l’ont alimenté avec des données de transfert falsifiées, puis ont laissé le processus d’autorisation automatisé de Bitget relâcher les fonds. Selon le récit rapporté par Fortune, les intrus ont « trompé le système d’approbation interne de Bitget pour lui faire autoriser les transferts ». Les portefeuilles froids, eux, n’ont pas bougé, et le produit d’auto-conservation Bitget Wallet n’a pas été touché.

Le butin a été éclaté sur au moins huit réseaux, dont Ethereum, BNB Chain, Arbitrum, Avalanche, TRON, le XRP Ledger et Zcash, en Ether, XRP, USDT, USDC et quelques autres jetons, une dispersion classique pour compliquer le traçage. Bitget affirme avoir absorbé l’intégralité de la perte grâce à son Protection Fund, un matelas d’environ 464 millions de dollars (près de 409 millions d’euros), et a lancé un programme de prime de 5 % pour la restitution ainsi qu’un tableau de suivi en temps réel, avec Mandiant et SlowMist en appui sur l’enquête, qui pointe vers la Corée du Nord (Startup Fortune). Nous avons détaillé le versant audit de l’affaire dans notre article « Bitget piraté : 310 M€ et le paradoxe de l’audit » ; ici, l’angle est différent, car ce vol dit surtout quelque chose sur la manière de partager une clé.

La crypto ne casse (presque) jamais : le vrai point de rupture

Pour comprendre pourquoi le choix du modèle prime sur tout le reste, il faut regarder où l’argent part réellement. Le rapport de mi-année 2026 de TRM Labs recense 207 piratages sur le premier semestre, pour environ 972 millions de dollars (près de 857 millions d’euros) de pertes, en recul de 57 % sur un an. Mais la répartition est le vrai enseignement : les failles de smart contract représentent la majorité des incidents en nombre, et une part minime de la valeur volée ; à l’inverse, les compromissions d’infrastructure, de clés et de procédures pèsent environ 15 % des incidents et près de 76 % de la valeur.

Autrement dit, ce ne sont pas les bugs de code qui vident les gros coffres, ce sont les défaillances humaines et opérationnelles autour des clés. Bybit, Drift, Humanity, Liquid, Bitget : pas une de ces affaires n’est une rupture de la cryptographie. Les signatures étaient valides. Les seuils étaient respectés. Le problème est que ce qui a été signé, ou ce que le système a cru signer, n’était pas ce que les propriétaires pensaient approuver.

Ce constat déplace le centre de gravité des bonnes pratiques. Pendant des années, la discussion tournait autour de la solidité des clés : matériel, entropie, sauvegardes. Elle reste nécessaire (le fiasco Coldcard l’a rappelé cet été), mais elle ne suffit plus. En 2026, la question décisive est celle de l’autorisation : qui approuve, sur quel écran, avec quel délai, et qui peut mentir à ce moment précis. Le partage de la clé, multisig ou MPC, est justement la mécanique qui décide de tout cela.

Multisig et MPC : deux façons de couper une clé en morceaux

Le multisig est le plus ancien et le plus lisible des deux. Un portefeuille multisignature est un compte, le plus souvent un smart contract (Safe, ex-Gnosis Safe, domine l’écosystème EVM), qui exige M signatures valides parmi N clés pour bouger des fonds. Chaque signataire détient une clé complète et autonome ; la règle « M-de-N » vit sur la chaîne, où tout le monde peut la lire, la vérifier et l’auditer. C’est sa grande force et sa faiblesse : transparent, mais rigide, et chaque clé existe pour de bon, donc une clé volée reste une clé valide.

Le MPC (multi-party computation) prend le problème par l’autre bout. Ici, la clé privée complète n’est jamais assemblée. Comme le résume Fireblocks, la clé n’est « jamais créée, jamais stockée et jamais reconstituée », ni à la génération du portefeuille, ni au moment de signer. Des fragments de clé sont répartis entre plusieurs parties ou machines, et un nombre seuil de ces fragments coopère pour produire une seule signature, sans jamais révéler la clé entière. Sur la chaîne, une transaction signée en MPC ressemble à une transaction ordinaire à une seule clé, ce qui la rend compatible avec n’importe quel réseau, sans support natif du multisig.

La différence de philosophie est nette. Safe la formule ainsi : « Le multisig externalise la confiance dans du code vérifiable ; le MPC l’internalise dans des systèmes et une infrastructure qui ne peuvent pas être entièrement vérifiés on-chain. » Le premier vous demande de faire confiance à un contrat public et immuable ; le second, à un fournisseur et à son infrastructure. Les signatures à seuil (threshold signatures) comme MuSig2 ou FROST sont un cousin du MPC au niveau de la signature elle-même, avec le même compromis : efficaces et discrètes, mais moins vérifiables de l’extérieur qu’un multisig on-chain.

Multisig contre MPC : le tableau comparatif

Aucun des deux modèles n’est « meilleur » dans l’absolu. Ils déplacent le risque à des endroits différents, et c’est précisément ce qu’il faut cartographier avant de choisir. Le tableau ci-dessous résume les arbitrages, ligne par ligne.

Le carnet des sinistres 2026 : qui a cédé, et à quelle couche

Huit affaires suffisent à dessiner la carte. Elles n’ont pas grand-chose en commun côté cryptographie, et tout en commun côté autorisation. Le tableau les classe par modèle et par couche défaillante, ce qui est bien plus instructif qu’un simple palmarès des montants.

Le fil rouge saute aux yeux. Sur huit dossiers, sept relèvent d’un partage de clé (multisig ou back-end à la MPC), et un seul, Coldcard, tient à une clé unique mal générée. Dans tous les cas de multisig, les clés étaient bien réparties et les signatures parfaitement valides. Chez Bybit, du code JavaScript malveillant injecté dans l’interface de Safe a fait signer aux dirigeants une transaction déguisée (BleepingComputer). Chez WazirX, l’écart entre l’interface du conservateur et les données réelles de la transaction a suffi. Chez Radiant, un malware macOS a affiché des données saines pendant qu’une transaction malveillante partait en arrière-plan, et même la simulation semblait propre.

Les affaires de 2026 ne font que raffiner la recette. Drift a perdu environ 285 millions de dollars parce que des attaquants ont patiemment poussé les membres du conseil de sécurité à pré-signer des transactions « durable nonce », un mécanisme Solana qui permet de signer une fois et d’exécuter plus tard (The Hacker News). Humanity a vu ses deux seuils, nominalement indépendants sur Ethereum et BNB Chain, tomber d’un coup parce que des clés des deux chaînes avaient été sauvegardées sur le même ordinateur (CoinDesk). Liquid Network a signé, avec son multisig 11-de-15, une sortie de fonds que ses propres nœuds jugeaient valide, à cause d’un bug de cache dans la validation des preuves d’Elements (Halborn). Et Bitget, on l’a vu, a laissé son back-end autoriser des transferts fantômes. Huit couches différentes, une même leçon : la clé n’était pas le maillon faible.

La faiblesse du multisig : l’écran d’approbation

Le talon d’Achille du multisig n’est pas la clé, c’est l’instant où l’humain approuve. Un portefeuille matériel affiche une transaction, le signataire regarde, valide, et sa clé produit une signature. Tout l’édifice repose sur une hypothèse fragile : que l’écran dise la vérité. La signature à l’aveugle (blind signing), où l’appareil ne peut montrer qu’un condensé illisible de données, transforme cette hypothèse en pari.

Les quatre plus gros vols de multisig de ces deux dernières années exploitent exactement cette faille. Bybit, WazirX et Radiant sont trois variantes d’un même tour de magie : faire croire au signataire qu’il approuve A alors qu’il signe B. Peu importe que la clé soit froide, que le seuil soit élevé ou que les signataires soient dispersés sur trois continents ; si l’écran ment, la répartition ne protège de rien. Drift ajoute une torsion temporelle : la transaction malveillante est signée à l’avance, en toute bonne foi, puis dégainée au moment choisi par l’attaquant.

C’est aussi le terrain de chasse des « drainers », ces kits de vidage de portefeuille qui piègent l’utilisateur au moment de la signature, un phénomène que nous avons décortiqué dans « Phishing crypto 2026 : dans l’usine à wallet drainers ». La bonne nouvelle, c’est que cette faiblesse a un antidote clair, et qu’il porte un nom en 2026 : le clear signing (nous y venons). La mauvaise, c’est qu’aucun réglage de seuil, aussi prudent soit-il, ne remplace la vérification de ce que l’on signe.

La faiblesse du MPC : le back-end invisible

Le MPC corrige la faille la plus visible du multisig : comme il n’existe aucune clé complète à voler et que le nombre de signataires se change hors chaîne, il supprime le point unique de défaillance matérielle et la friction des rotations. C’est pour cela que la plupart des conservateurs institutionnels s’appuient dessus. Mais il déplace le risque, il ne le supprime pas.

Là où le multisig échoue sur un écran que l’on peut au moins apprendre à lire, le MPC échoue dans un endroit que l’on ne peut pas voir : le back-end. La politique de signature (qui peut déclencher quoi, dans quelles limites) vit dans l’infrastructure du fournisseur, pas sur la chaîne. Quand cette infrastructure est compromise ou trompée, comme le système d’autorisation de Bitget, rien sur la chaîne ne permet, en amont, de repérer l’anomalie : la transaction sort avec une signature parfaitement valide, indiscernable d’une opération légitime. C’est exactement le compromis que décrit Safe, une confiance internalisée dans des systèmes qui ne peuvent pas être entièrement vérifiés on-chain.

Bitget est le miroir, côté MPC, des affaires de blind signing. Aucune clé volée, une autorisation détournée, et une absence de trace publique qui complique l’enquête et la récupération. Le MPC n’est donc pas « plus sûr » que le multisig ; il est sûr différemment, et il faut le protéger différemment, en durcissant et en surveillant précisément la couche d’autorisation que le multisig, lui, expose au grand jour. Le choix entre les deux n’est pas un choix entre risque et sécurité, mais entre deux risques que l’on n’affronte pas avec les mêmes armes.

Bonne pratique n°1 : choisir le modèle avant le réglage

Voilà pourquoi la première décision n’est pas « 2-de-3 ou 4-de-7 », mais « multisig, MPC, ou les deux ». Le bon modèle dépend de ce que l’on protège et de qui l’utilise. Une trésorerie de DAO qui a besoin de transparence et de gouvernance publique n’a pas les mêmes contraintes qu’un pupitre de trading qui doit signer mille fois par jour sur vingt chaînes.

Charles Guillemet, directeur technique de Ledger, a lancé une mise en garde utile après le fiasco Coldcard, quand beaucoup se sont rués vers le multisig par réflexe : « Le multisig n’est pas automatiquement la bonne réponse » (U.Today). Sa complexité (plus d’appareils, plus de sauvegardes, plus d’étapes de coordination) crée de nouveaux points de rupture et peut rendre la récupération plus difficile, voire impossible. Pour beaucoup de particuliers, un seul portefeuille matériel bien sauvegardé, avec clear signing, reste le choix le plus robuste.

Ce tableau n’est qu’un point de départ ; le principe qui compte est qu’un modèle mal ajusté à l’usage devient lui-même une faille. Un multisig 20-de-20 « pour faire sérieux » est une bombe à retardement (perdre une clé bloque tout), et un MPC confié à un fournisseur que l’on ne surveille pas revient à recréer, en pire, le point unique de confiance que l’on croyait avoir supprimé.

Bonne pratique n°2 : le seuil et la diversité des signataires

Une fois le modèle choisi, les réglages comptent, et il existe désormais un socle documenté. Le référentiel de la Security Alliance (SEAL) fixe des planchers clairs : au minimum 3 signataires, un seuil d’au moins 50 %, et 7 signataires ou plus pour tout multisig gardant l’équivalent de plus de 1 million de dollars (environ 880 000 euros). Le référentiel proscrit explicitement les schémas N-de-N, où la perte d’une seule clé condamne définitivement l’accès aux fonds.

La diversité compte autant que le nombre. SEAL recommande que tous les signataires utilisent des portefeuilles matériels, de modèles et de fabricants différents, répartis géographiquement, avec au moins un signataire externe à l’organisation pour les portefeuilles à forte valeur, et une adresse dédiée par multisig. L’idée est de casser les corrélations : si toutes les clés vivent sur le même modèle d’appareil, dans le même bureau, gérées par les mêmes personnes, alors « cinq signataires » n’est qu’un seul point de défaillance déguisé, exactement le piège de Humanity Protocol.

Vitalik Buterin dit la même chose côté portefeuilles à récupération sociale. Il ramène la sécurité de ces dispositifs à deux questions : qui choisir comme gardiens, et quelles instructions leur donner (CryptoSlate). Sa réponse : des gardiens qui ne perdront pas leur clé et ne se ligueront pas pour voler, aussi décorrélés que possible, idéalement au moins trois et plutôt sept ou plus, dans des pays différents, sur des types de portefeuilles et de systèmes différents. Plus de signataires n’aide que si chacun ajoute une indépendance réelle ; sinon, on empile du risque corrélé.

Bonne pratique n°3 : vérifier ce que l’on signe

Si la faille numéro un du multisig est l’écran d’approbation, alors la bonne pratique numéro un côté exécution est de vérifier ce que l’on signe. C’est précisément le chantier ouvert en 2026 par la Fondation Ethereum, qui a repris à Ledger la coordination du standard de clear signing, lancé le 12 mai 2026 dans le cadre de son initiative Trillion Dollar Security (blog.ethereum.org). Le mot d’ordre : « What You See Is What You Sign », ce que vous voyez est ce que vous signez, doit devenir la norme, et la signature à l’aveugle l’exception.

Concrètement, le standard s’articule autour de plusieurs briques. L’ERC-7730 définit un format JSON de descripteurs lisibles par un humain, pour que le portefeuille affiche « vous envoyez X à Y » plutôt qu’un bloc hexadécimal (eips.ethereum.org). Un registre public partagé héberge ces descripteurs, un cadre d’attestation (ERC-8176) permet à des auditeurs indépendants de garantir qu’un descripteur est fidèle, et un condensé de calldata (ERC-8213) donne une empreinte courte que le signataire peut recalculer sur un second appareil pour comparer.

En attendant que ce standard couvre tout, la discipline manuelle reste incontournable : toujours vérifier les données brutes de la transaction (adresse cible, fonction appelée, paramètres), recalculer le hash de la transaction sur une machine propre et isolée, et confirmer hors bande, par un canal indépendant, un appel vidéo doublé d’un message signé, comme le recommande SEAL. Aucune de ces étapes n’aurait exigé une cryptographie plus forte chez Bybit ou WazirX ; elles auraient simplement montré aux signataires ce qu’ils étaient réellement en train d’approuver.

Bonne pratique n°4 : gagner du temps (timelocks, simulation, surveillance)

Un signataire trompé signe en une seconde ; une organisation bien conçue se donne le temps de rattraper l’erreur. Le délai obligatoire (timelock) entre l’approbation et l’exécution est l’un des outils les plus sous-estimés. Il crée une fenêtre pendant laquelle une transaction anormale peut être repérée et annulée avant qu’elle ne devienne irréversible.

Drift en est la démonstration par l’absence. Quelques jours avant le vol, le conseil de sécurité avait migré vers une configuration sans le moindre timelock, supprimant justement la fenêtre de détection qui aurait pu neutraliser les transactions pré-signées. La simulation, elle, n’est pas une garantie : chez Radiant, les outils de simulation affichaient une transaction saine parce que c’étaient les machines des signataires elles-mêmes qui étaient compromises. Simuler sur un poste infecté revient à demander à un menteur s’il ment.

Reste la surveillance. SEAL recommande des systèmes de monitoring et d’alerte capables de signaler immédiatement toute activité on-chain du multisig. C’est le complément naturel du timelock : le délai ne sert à rien si personne ne regarde pendant que le compteur tourne. Bitget a d’ailleurs répondu à son vol par un tableau de suivi en temps réel et une prime de restitution, une surveillance devenue, faute de mieux, une course-poursuite après coup. Mieux vaut regarder avant que les fonds ne partent qu’après.

Bonne pratique n°5 : isoler, faire tourner, récupérer

La dernière famille de bonnes pratiques concerne le cycle de vie des clés. Isoler d’abord : chaque signature devrait se faire sur un appareil dédié, idéalement air-gapped, sur un système durci, jamais sur la machine qui sert aussi à lire ses e-mails et à ouvrir des PDF reçus sur Telegram (le vecteur exact de Radiant). Faire tourner ensuite : revues d’accès régulières, retrait rapide des signataires qui partent, rotation des clés compromises ou suspectes.

Récupérer, enfin. Humanity Protocol a perdu environ 36 millions de dollars non pas parce que son schéma 3-de-6 et 3-de-5 était mauvais sur le papier, mais parce que des clés des deux chaînes avaient été sauvegardées sur un seul ordinateur, transformant deux seuils nominalement indépendants en un unique point de défaillance. La leçon n’est pas « plus de clés », c’est « des clés réellement séparées », avec un plan de reprise écrit pour le jour où un seuil de clés devient indisponible ou suspect.

Quand tout échoue malgré tout, la récupération devient juridique et opérationnelle. Bybit a porté plainte le 7 août 2026 devant un tribunal fédéral de Washington contre la Corée du Nord et le groupe Lazarus, et a obtenu le gel d’une partie des actifs volés, avec environ 48,4 millions de dollars déjà récupérés et 30,5 millions gelés sur plus de 28 plateformes (crypto.news). Nous avons suivi cette course à la restitution dans « Après le hack : la course pour récupérer les cryptos volées », et l’entraide entre protocoles dans le sauvetage du pont KelpDAO. Mais récupérer après coup reste une loterie ; le plan de reprise sert surtout à ne pas en arriver là.

Le modèle hybride : quand multisig et MPC se rejoignent

Le débat « multisig contre MPC » est en train de se dissoudre. La plupart des systèmes de conservation de niveau production combinent déjà les deux, chacun là où il est le meilleur. Safe le reconnaît sans détour : de nombreuses solutions modernes empilent les deux approches sur des couches différentes, le MPC gérant l’exécution et l’automatisation, le multisig imposant la gouvernance, les approbations et la politique.

Le schéma qui se généralise ressemble à ceci : un multisig on-chain, public et auditable, fixe la règle de haut niveau (qui peut faire quoi, avec quel seuil), et chaque clé de ce multisig est elle-même protégée par du MPC ou un module matériel de sécurité. On obtient la transparence du multisig et la souplesse du MPC, et surtout deux couches de nature différente qu’un attaquant doit franchir toutes les deux. C’est la traduction concrète du principe de défense en profondeur : ne pas parier la totalité sur une seule mécanique, parce qu’on a vu, en 2026, chacune céder à tour de rôle.

Ce n’est pas une baguette magique. Un hybride mal conçu additionne les surfaces d’attaque au lieu de les diviser, et ajoute de la complexité, donc des occasions de se tromper. Mais bien fait, il répond à la seule question qui vaille : si une couche tombe, qu’est-ce qui reste debout. Un blind signing sur le multisig ne suffit plus si la politique MPC exige une confirmation hors bande ; un back-end MPC trompé ne suffit plus si un timelock multisig retarde la sortie assez longtemps pour la repérer.

Multisig, MPC et l’AMF : qui répond quand ça casse

Reste la question du recours. En Europe, le règlement MiCA encadre les prestataires de services sur crypto-actifs (les PSCA, ou CASP), pas les protocoles eux-mêmes. Une plateforme qui conserve les fonds de ses clients dans un multisig ou en MPC est responsable de ses contrôles de signature : son régime de responsabilité relève de l’article 75 de MiCA, et sa résilience opérationnelle (systèmes, sous-traitants informatiques) du règlement DORA. En cas de défaillance, le client dispose donc d’un interlocuteur et d’un recours, en France via l’Autorité des marchés financiers (AMF).

Le calendrier français est net : la période transitoire du régime PSAN, hérité de la loi PACTE, a pris fin le 1er juillet 2026. Les acteurs non conformes doivent s’être mis en règle ou avoir organisé une sortie ordonnée ; l’exercice sans agrément expose désormais à des sanctions pénales prévues par le Code monétaire et financier. Pour l’utilisateur, cela veut dire qu’un conservateur régulé qui laisserait son back-end autoriser des transferts fantômes, comme dans le scénario Bitget, n’est pas hors d’atteinte du régulateur.

L’angle mort est ailleurs : le multisig d’un particulier, ou celui d’un protocole réellement décentralisé, sort du périmètre de MiCA. Pas de PSCA, pas d’agrément, pas de régulateur à appeler. Le seul filet de sécurité, ce sont vos propres procédures : seuil correct, signataires diversifiés, clear signing, timelock, surveillance. Aucun des huit sinistres de notre carnet ne s’est produit chez un acteur supervisé par l’AMF, et ce n’est pas un hasard : là où personne ne répond à votre place, la discipline de partage de clé est votre unique défense.

Foire aux questions

Multisig ou MPC, lequel est le plus sûr ?

Aucun n’est intrinsèquement plus sûr ; ils échouent à des endroits différents. Le multisig est transparent et vérifiable on-chain, mais il casse à l’écran d’approbation (la signature à l’aveugle). Le MPC supprime la clé unique à voler, mais il casse dans un back-end que l’on ne peut pas auditer de l’extérieur, comme l’a montré le vol Bitget. La meilleure pratique en 2026 consiste souvent à combiner les deux en défense en profondeur.

Combien de signataires faut-il pour un multisig ?

Le référentiel SEAL fixe un plancher de 3 signataires et un seuil d’au moins 50 %, et recommande 7 signataires ou plus pour tout multisig gardant plus de 1 million de dollars (environ 880 000 euros). Il faut éviter les schémas N-de-N, où perdre une clé bloque tout, et surtout s’assurer que chaque signataire ajoute une indépendance réelle : appareils, lieux et personnes différents.

Qu’est-ce que le clear signing et pourquoi est-ce important ?

Le clear signing consiste à afficher une transaction en clair et lisible (« vous envoyez X à Y ») plutôt qu’un bloc de données illisible, pour que le signataire approuve ce qu’il croit approuver. La Fondation Ethereum en a fait un standard le 12 mai 2026, autour de l’ERC-7730. C’est l’antidote direct aux vols de type Bybit, WazirX et Radiant, où des signataires ont approuvé une transaction déguisée.

Le vol Bitget a-t-il exposé les clés des utilisateurs ?

Non. Selon la plateforme, aucune clé privée n’a été volée et aucun retrait client n’a été falsifié ; les attaquants ont trompé un système de back-end pour lui faire autoriser des transferts frauduleux. Bitget affirme avoir couvert l’intégralité des pertes, environ 342 millions d’euros, grâce à son Protection Fund d’environ 409 millions d’euros.

Un particulier a-t-il vraiment besoin d’un multisig ?

Pas nécessairement. Le directeur technique de Ledger, Charles Guillemet, rappelle que le multisig n’est pas automatiquement la bonne réponse : sa complexité crée de nouveaux risques et peut rendre la récupération impossible. Pour beaucoup de particuliers, un seul portefeuille matériel bien sauvegardé, avec clear signing, offre un meilleur rapport entre sécurité et simplicité.

Par Anneke de Vries, correspondante sécurité et enquêtes, HOGE Wire.