Multisig 2026 : plus de signataires ne veut pas dire plus sûr

Après le vol qui a frappé les porte-monnaie Coldcard fin juillet 2026, un réflexe s’est répandu dans la communauté : passer au multisig, tout de suite, pour ne plus jamais dépendre d’une seule clé. Le conseil paraît de bon sens. Il est pourtant venu se heurter à une mise en garde inattendue, signée par le directeur technique de Ledger lui-même. Charles Guillemet a pris la parole pour freiner l’enthousiasme : le multisig n’est pas, en soi, la bonne réponse.

Cette phrase résume le vrai sujet de 2026. Le multisig, la signature d’une transaction par plusieurs clés indépendantes, reste l’une des meilleures défenses connues contre le vol d’une clé unique. Mais il n’est pas un produit que l’on active pour être en sécurité ; c’est un processus, avec des règles d’exploitation, des points de défaillance nouveaux et un coût. Mal conçu, il déplace le risque au lieu de le supprimer, et peut même aggraver la situation. Les chiffres de l’année le prouvent : les plus gros vols estampillés multisig n’ont cassé aucune cryptographie et n’ont volé aucune clé au sens strict. Ils ont trompé des humains devant un écran.

La preuve que l’affaire se règle rarement dans le code : le 7 août 2026, Bybit a assigné en justice la Corée du Nord et le groupe Lazarus devant un tribunal fédéral américain et a obtenu le gel d’une partie des fonds volés lors du piratage record de février 2025, le juge estimant que la plateforme avait des chances sérieuses de l’emporter sur le fond, selon CoinDesk. Un vol de multisig peut finir en injonction judiciaire des mois plus tard ; la seule ligne de défense qui compte reste celle du moment de la signature.

Cet article n’est pas une chronologie des piratages ni une simple liste à cocher. C’est un guide de conception et d’exploitation : comment décider si vous avez besoin d’un multisig, comment fixer le seuil, comment diversifier les signataires, et pourquoi la signature claire (clear signing) est la vraie nouveauté défensive de l’année.

Multisig, rappel : ce que la signature à plusieurs protège (et ce qu’elle ne protège pas)

Un portefeuille multisignature exige que M clés parmi N approuvent une transaction avant qu’elle ne s’exécute. On parle de configuration « M-of-N » : un 3-of-5 requiert trois signatures sur cinq détenteurs possibles. Sur Ethereum et les chaînes compatibles EVM, l’implémentation dominante est le compte intelligent (smart account) Safe, anciennement Gnosis Safe, qui gère aujourd’hui plus de 63 millions de comptes selon le rapport trimestriel de la Safe Ecosystem Foundation. Sur Bitcoin, la logique passe par des scripts natifs, et de plus en plus par Miniscript, un langage qui rend ces politiques lisibles et vérifiables.

Ce que le multisig protège est précis : la compromission d’une seule clé. Si un attaquant vole un appareil, un seed ou une signature, il ne peut rien faire tant qu’il n’atteint pas le seuil. C’est une défense contre le point de défaillance unique, et contre certaines formes de contrainte physique (l’attaque à la clé à molette, où l’on force une victime à signer), puisque aucun signataire seul ne peut vider le coffre.

Ce que le multisig ne protège pas est tout aussi précis, et c’est là que 2026 a fait mal. Il ne protège pas contre la signature à l’aveugle, quand plusieurs signataires approuvent, chacun de leur côté, une transaction dont l’écran ment sur le contenu. Il ne protège pas contre la compromission corrélée, quand plusieurs clés vivent sur des machines infectées par le même logiciel malveillant. Il ne protège pas contre l’ingénierie sociale patiente, quand un opérateur est manipulé pendant des semaines. Répartir la signature ne sert à rien si l’on répartit aussi la même erreur.

Le paradoxe de 2026 : les plus gros vols multisig n’ont pas cassé la cryptographie

Le rapport de mi-année de TRM Labs le dit sans détour : sur le premier semestre 2026, environ 832 millions d’euros (près de 972 millions de dollars) ont été volés sur 207 incidents, et si les bugs de contrats forment la majorité des cas, l’essentiel de la valeur dérobée provient de la compromission d’infrastructures, de clés et de procédures. Les atteintes opérationnelles pèsent une minorité des incidents et l’immense majorité des pertes, selon TRM Labs. Autrement dit, ce ne sont pas les mathématiques qui lâchent, ce sont les organisations.

Le tableau ci-dessous rassemble cinq échecs multisig de référence. Aucun n’est une rupture de la cryptographie. Dans chaque cas, des signataires légitimes ont approuvé quelque chose d’autre que ce qu’ils croyaient signer, ou une seule intrusion a franchi plusieurs seuils à la fois. Les autopsies détaillées de plusieurs de ces affaires, comme celles menées par Halborn, montrent le même schéma : la couche d’affichage a été manipulée, pas le protocole.

Le cas Bybit reste le plus instructif. Selon l’enquête de Sygnia, du code JavaScript malveillant avait été inséré dans l’interface Safe{Wallet} via la machine compromise d’un développeur ; au moment de signer un transfert de routine depuis le portefeuille froid, l’écran montrait la bonne adresse tandis que la transaction réellement signée modifiait la logique du contrat. Les clés n’ont jamais été volées. Le FBI a attribué l’attaque au groupe Lazarus. Le cas WazirX, un Safe 4-of-6 sous la garde de Liminal, procède de la même logique : les quatre signataires ont approuvé une transaction anodine dont l’interface masquait la charge malveillante, comme l’a reconstitué l’autopsie de Halborn.

Le cas Humanity Protocol illustre l’illusion de deux seuils indépendants. Le fondateur Terence Kwok l’a reconnu au sujet de la mise en place : « some of the keys were accidentally backed up to a compromised device during setup » (certaines clés avaient été accidentellement sauvegardées sur un appareil compromis lors de la configuration), a-t-il expliqué à CoinDesk. Sur le papier, un 3-of-6 sur Ethereum et un 3-of-5 sur BNB Chain. En pratique, plusieurs clés des deux chaînes réunies sur un seul portable : une intrusion, deux seuils franchis.

« Plus de signataires » n’est pas « plus de sécurité »

C’est le contresens le plus répandu, et il coûte cher. L’intuition dit que plus il y a de clés, plus le coffre est solide. La réalité est en U : au-delà d’un certain point, chaque signataire supplémentaire ajoute surtout de la complexité, des appareils à sécuriser, des seeds à sauvegarder, des humains à coordonner, et la complexité est précisément l’endroit où l’on perd des fonds.

Le directeur technique de Ledger, Charles Guillemet, l’a formulé sans détour après l’affaire Coldcard : « Multisig is not automatically the right answer » (le multisig n’est pas automatiquement la bonne réponse). Il observe régulièrement, dit-il, des utilisateurs qui s’enferment dans des configurations difficiles ou impossibles à récupérer en toute sécurité. Ajouter des clés protège contre le point de défaillance unique, mais introduit de nouveaux points de rupture. Pour la plupart des particuliers, un seul portefeuille matériel bien sauvegardé, doublé de signature claire, reste plus sûr qu’un multisig bricolé ; pour les cas plus avancés, il recommande Miniscript sur Bitcoin, qui permet d’exprimer un 2-of-3, des clés de secours à timelock ou un héritage, tout en gardant la lisibilité de ce que l’on signe, rapporte U.Today.

Ce principe rejoint une règle plus large en sécurité : l’annonce n’est pas la réalité. De la même façon que, sur le marché des primes, le prix affiché n’est pas la prime versée, la configuration affichée d’un multisig ne dit rien de sa sécurité réelle tant que l’on n’a pas vérifié la diversité des signataires, l’isolement des appareils et l’existence d’un plan de reprise. Un 7-of-11 dont sept clés dorment sur le même ordinateur portable est moins sûr qu’un 2-of-3 correctement distribué.

Modéliser la menace avant de choisir un seuil

Aucun seuil n’est bon dans l’absolu. Il découle d’un modèle de menace, c’est-à-dire d’une réponse honnête à la question : contre qui, et contre quoi, se défend-on ? Les réponses ne mènent pas au même dispositif.

Contre le vol externe (phishing, malware, intrusion à distance), on veut de la redondance et de la diversité : plusieurs clés, sur des matériels et des personnes différentes, pour qu’aucune intrusion unique ne suffise. Contre le risque interne (un employé malveillant, un signataire retourné), on veut un seuil élevé et au moins un signataire externe à l’organisation, pour qu’aucune coalition minoritaire ne puisse agir seule. Contre la contrainte physique et l’attaque à la clé à molette, on veut des seuils qui rendent une seule victime insuffisante, et des signataires géographiquement séparés. Contre la perte accidentelle de clés, on veut éviter le N-of-N (où la perte d’une seule clé gèle tout) et prévoir des chemins de récupération.

Ces objectifs se contredisent parfois. Un seuil élevé protège contre l’interne mais fragilise la disponibilité ; une large distribution protège contre l’intrusion mais complique la coordination et la reprise. Le travail de conception consiste à arbitrer explicitement, en fonction du modèle de menace, et non à empiler des signataires par précaution. Choisir un seuil sans avoir nommé l’adversaire, c’est se protéger contre une menace qu’on n’a pas comprise.

Le seuil et le nombre : la règle des 3 signataires et du 50 %

Une fois le modèle de menace posé, des repères chiffrés existent. Le référentiel de la Security Alliance (SEAL), qui fait autorité dans le milieu, fixe un plancher clair : au minimum trois signataires, un seuil d’au moins 50 %, et sept signataires ou plus pour tout multisig gardant l’équivalent de plus d’un million de dollars (environ 850 000 euros). Le référentiel proscrit explicitement les schémas N-of-N, qui transforment la perte d’une seule clé en blocage définitif des fonds.

Le seuil doit rester strictement supérieur à la moitié pour qu’aucune minorité ne puisse agir, tout en laissant une marge de disponibilité : un 4-of-7 tolère la perte de trois clés sans blocage, là où un 3-of-3 ne tolère rien. Le nombre de signataires doit être assez grand pour la diversité, assez petit pour rester coordonnable. Passé sept à onze signataires, la valeur défensive marginale décroît et le coût opérationnel grimpe : c’est le U évoqué plus haut.

Diversité des signataires : matériel, géographie, personnes

Un seuil ne vaut que si les signataires sont réellement indépendants. Le référentiel SEAL recommande une diversité sur plusieurs axes : des modèles et des fabricants de portefeuilles matériels différents (pour qu’un bug d’un seul fournisseur, comme celui de Coldcard, ne touche pas toutes les clés), une séparation géographique des appareils, un mélange de rôles (dirigeants, développeurs, opérations), au moins un signataire externe à l’organisation, une adresse dédiée par multisig pour lever toute ambiguïté, et des logiciels clients variés.

Comme l’a écrit Vitalik Buterin, « Two key questions in using multi-sig wallets and social recovery wallets securely are: (i) whom do you choose as guardians, and (ii) what instructions do you give them? » (les deux questions clés pour utiliser un multisig en sécurité sont : qui choisissez-vous comme gardiens, et quelles instructions leur donnez-vous), selon CryptoSlate. La diversité des signataires est la première de ces réponses.

La raison est écrite dans les autopsies. Chez Radiant Capital, un logiciel malveillant macOS, glissé via un PDF piégé sur Telegram, a compromis plusieurs machines de développeurs à la fois ; l’interface Safe affichait des données légitimes pendant que la transaction malveillante se signait en arrière-plan, et même la simulation ne montrait aucune anomalie puisque les machines elles-mêmes étaient infectées, détaille Halborn. Chez Humanity Protocol, deux seuils nominalement séparés partageaient un même ordinateur. Dans les deux cas, la diversité affichée cachait une corrélation réelle.

La leçon opérationnelle est simple à énoncer, difficile à tenir : si deux signataires utilisent le même modèle d’appareil, le même système d’exploitation, le même canal de communication et le même bureau, ils comptent pour un seul signataire face à une attaque bien conçue. La diversité n’est pas un luxe esthétique, c’est ce qui donne un sens au seuil.

L’appareil de signature : dédié, isolé, jamais l’ordinateur du quotidien

Toute signature devrait se faire sur un appareil dédié, durci ou isolé (air-gapped), jamais sur l’ordinateur qui sert au courriel et à la navigation. Le référentiel SEAL en fait une exigence : portefeuille matériel obligatoire pour chaque signataire, appareil de signature séparé, et vérification des données brutes de la transaction (adresse cible, fonction appelée, paramètres) avant tout accord.

L’affaire Coldcard de l’été 2026 a rappelé une nuance que beaucoup oubliaient : un portefeuille matériel est nécessaire, mais pas suffisant. Un défaut du générateur d’aléa, introduit par une mise à jour de mars 2021, avait affaibli la génération de certaines clés au point de les rendre devinables sans jamais toucher l’appareil ; environ 1 816 BTC (près de 99 millions d’euros, soit à peu près 116 millions de dollars) ont été siphonnés de plus de 5 200 adresses en quatre vagues à partir du 30 juillet, selon TRM Labs. Le matériel isole la clé, il ne garantit pas qu’elle a été bien engendrée, ni que l’écran dit la vérité.

Car c’est bien l’écran le maillon décisif. À chaque grand vol multisig, la couche d’affichage a menti : l’interface montrait une transaction, l’appareil en signait une autre. Le glissement vers l’audit assisté par IA, que documentent des acteurs comme Trail of Bits, aide à débusquer ce genre de faille latente plus vite, mais il ne remplace pas la règle d’or : ne jamais signer ce que le matériel ne peut pas afficher en clair, et recalculer l’empreinte de la transaction sur une machine propre et séparée.

Clear signing : la vraie nouveauté de 2026 contre la signature à l’aveugle

Si un seul fil relie Bybit, WazirX et Radiant, c’est la signature à l’aveugle (blind signing) : approuver des données que l’on ne peut pas lire. La réponse structurée de l’année s’appelle la signature claire (clear signing), et elle a changé de dimension le 12 mai 2026, quand la Ethereum Foundation a annoncé en prendre la responsabilité via son initiative Trillion Dollar Security, reprenant le flambeau de Ledger.

Le principe est résumé par un mot d’ordre : WYSIWYS, « What You See Is What You Sign », ce que vous voyez est ce que vous signez. L’annonce le formule crûment : approuver une transaction est censé être la dernière ligne de défense sur ce qui arrive à vos actifs, et « when it is done blindly, that defense does not hold » (faite à l’aveugle, cette défense ne tient pas). Le dispositif repose sur ERC-7730, un format JSON qui décrit en langage humain le contenu d’un appel de contrat (calldata EVM), d’un message typé EIP-712 ou d’une opération de compte (ERC-4337), aujourd’hui au statut Draft en version 2.0.0, initié par des contributeurs de Ledger dont Laurent Castillo et Derek Rein. Autour du format, un registre public partagé stocke ces descriptions, dont l’exactitude est vérifiée par des relectures et des attestations indépendantes, chaque portefeuille choisissant les sources auxquelles il fait confiance. Parmi les contributeurs figurent Ledger, MetaMask, Trezor, Fireblocks, WalletConnect, Keycard, Cyfrin, Sourcify, Zama, ZKnox et Argot.

Pour un multisig, l’apport est direct : si chaque signataire voit, en clair et sur l’écran sécurisé de son propre appareil, la même description lisible de la transaction, l’attaque par interface trafiquée devient beaucoup plus difficile. Un mécanisme complémentaire d’empreinte de calldata permet même de recalculer un court condensé reproductible sur un second appareil et de le comparer, exactement la contre-mesure qui manquait à Bybit et Radiant. Des outils indépendants existent déjà pour cela : clearsig, développé par Cyfrin, et l’outil communautaire SafeLens recalculent le vrai hash d’une transaction Safe sur une machine séparée, pour comparaison. La règle pratique tient en une ligne : si le portefeuille ne sait pas vous montrer ce que vous signez, ne signez pas.

Timelocks, simulation et surveillance : gagner du temps pour dire non

Une bonne conception de multisig ne mise pas seulement sur la signature ; elle mise sur le temps. Trois mécanismes donnent aux signataires la possibilité de dire non avant qu’il ne soit trop tard.

Le premier est le timelock, un délai obligatoire entre l’approbation d’une transaction et son exécution. Ce délai crée une fenêtre de détection : si une transaction anormale passe le seuil, l’équipe a des heures, parfois des jours, pour la repérer et l’annuler. L’affaire Drift Protocol montre le prix de son absence. Quelques jours avant le vol d’environ 244 millions d’euros (près de 285 millions de dollars), le conseil de sécurité avait migré vers un 2-of-5 sans aucun timelock, supprimant précisément la fenêtre de détection ; les attaquants, qui avaient patiemment obtenu des transactions pré-signées via la fonction « durable nonce » de Solana, n’avaient plus qu’à les exécuter à la demande, a raconté CoinDesk.

Le deuxième est la simulation : rejouer la transaction avant de l’exécuter, avec des outils comme Tenderly ou la simulation intégrée de Safe, pour voir son effet réel sur l’état de la chaîne. La limite, révélée par Radiant, est que la simulation ne vaut rien si la machine qui la lance est elle-même compromise. Le troisième est la surveillance active : être alerté en temps réel de toute activité on-chain sur le multisig, et vérifier hors bande (par appel vidéo et message signé) toute opération sensible avant de l’approuver. Un multisig sans surveillance est un coffre sans alarme.

Rotation des clés, offboarding et plan de reprise

Un multisig n’est pas un objet que l’on installe et oublie ; c’est un dispositif vivant qui exige de l’entretien. La certification SEAL SFC Multisig Operations, une norme opérationnelle ouverte et auditable, en donne le détail : un propriétaire des opérations nommé, un registre complet des signataires tenu à jour, des revues d’accès trimestrielles, une rotation et un retrait (offboarding) rapides des signataires qui quittent leurs fonctions, une piste d’audit conservée plusieurs années, et des procédures d’urgence testées régulièrement.

La rotation compte autant que la configuration initiale. Un signataire qui part, un appareil perdu, un canal de communication compromis : chacun de ces événements doit déclencher un retrait et un remplacement. Sur un multisig on-chain, ce changement a un coût en gaz et en coordination, ce qui pousse trop d’équipes à repousser l’opération ; c’est une erreur, car un signataire fantôme est une porte laissée ouverte.

Le plan de reprise est le volet le plus négligé. Que fait-on quand un seuil de clés devient indisponible ? Quand on soupçonne une compromission en pleine transaction ? Un dispositif sérieux prévoit à l’avance les réponses : comment atteindre le quorum en mode dégradé, qui contacter, comment geler les opérations. Sans ce plan écrit et répété, la première crise se gère dans la panique, et la panique signe mal.

Le coût caché : gaz, friction et le piège de la récupération

Le multisig a un prix, et l’ignorer fait partie des raisons pour lesquelles il déçoit. Chaque changement de signataire, chaque exécution, coûte du gaz et du temps de coordination. Cette friction n’est pas neutre : elle pousse à repousser les rotations, à réutiliser des appareils, à contourner les procédures, c’est-à-dire à saboter lentement la sécurité que l’on croyait acheter.

Le coût peut même devenir explicite. En octobre 2025, le premier multisig natif de Ledger a introduit des frais de transaction, un forfait d’environ 10 dollars sur les transferts standard et 0,05 % sur les transferts de tokens ERC-20, en plus du gaz réseau. Le développeur pcaversaccio, contributeur du réseau de réponse SEAL-911, a qualifié le modèle de tactique de « cash-cow » et reproché à Ledger de vouloir devenir « the single choke point for all crypto » (le point de passage obligé de toute la crypto), tandis que Charles Guillemet justifiait ces frais par le coût de l’infrastructure et des audits nécessaires, rapporte The Block. Le débat déborde le cas Ledger : sécuriser sérieusement un multisig a un coût récurrent, en argent comme en attention.

Le piège le plus dangereux reste la récupération. Un multisig mal pensé peut devenir irrécupérable : seeds perdus, signataires injoignables, seuil impossible à réunir. C’est précisément le scénario que redoute Guillemet quand il parle de configurations impossibles à récupérer en toute sécurité. Un coffre que personne ne peut plus ouvrir n’est pas un coffre sûr, c’est une perte à retardement.

Multisig ou MPC : deux façons de répartir la confiance

Le multisig n’est pas la seule manière de supprimer le point de défaillance unique. Le calcul multipartite (MPC, multi-party computation) répartit lui aussi le pouvoir de signature, mais différemment : au lieu de plusieurs clés distinctes validant on-chain, une seule clé est fragmentée en parts détenues par plusieurs parties, qui coopèrent pour produire une signature sans jamais reconstituer la clé complète.

Safe résume l’arbitrage d’une formule : le multisig « externalise la confiance dans du code vérifiable », là où le MPC internalise la confiance dans des systèmes et une infrastructure qui ne peuvent pas être entièrement vérifiés on-chain. Fireblocks, côté institutionnel, rappelle que le MPC est reconnu par des régulateurs comme valable pour l’auto-conservation depuis 2019, mais que le multisig conserve la piste d’audit la plus longue et la plus éprouvée. Le choix n’est pas idéologique : il dépend de qui doit pouvoir vérifier quoi.

C’est aussi une question de contrepartie. Comme pour un perp DEX, où savoir qui est la maison derrière vos positions change tout au risque réel, choisir entre multisig et MPC revient à choisir à qui, et à quelle infrastructure, vous déléguez la garde de vos clés. La transparence a un coût ; l’opacité aussi.

Gouvernance et responsabilité : DAO, CASP et le rôle de l’AMF

Au-delà de la technique, un multisig est une structure de gouvernance, et sa sécurité dépend de qui décide. Les conseils de sécurité (Security Councils) des protocoles en sont l’illustration : leur composition, leurs seuils et leurs délais sont des choix politiques autant que techniques. La migration de Drift vers un 2-of-5 sans timelock, juste avant son vol, était une décision de gouvernance avant d’être une faille technique ; c’est le même engrenage que décortiquent les autopsies d’attaques de gouvernance, où une structure de décision mal pensée devient l’outil de sa propre exploitation.

Le volet réglementaire change selon qui détient les fonds. Un prestataire de services sur actifs numériques (le CASP au sens de MiCA, l’ancien PSAN en France) qui conserve les avoirs de ses clients dans un multisig répond de ses contrôles de signature. Le régime de responsabilité de l’article 75 de MiCA et les exigences de résilience opérationnelle de DORA s’appliquent, et un client lésé dispose d’un recours via son régulateur national, l’AMF pour la France. Le régime transitoire PSAN a d’ailleurs pris fin le 1er juillet 2026, l’AMF ayant prévenu dès février 2026 que les acteurs non conformes devaient organiser une sortie ordonnée, comme le rappelle l’autorité.

Mais cette protection s’arrête à la porte de la finance décentralisée. Un utilisateur d’un multisig pleinement décentralisé, sans intermédiaire régulé, tombe hors du champ de MiCA : aucun CASP responsable, aucun régulateur à saisir, ses propres procédures pour seule défense. Et quand tout échoue, il reste la justice, longue et incertaine : le 7 août 2026, Bybit a obtenu d’un tribunal fédéral américain le gel d’une partie des fonds volés en poursuivant la Corée du Nord et Lazarus, le juge reconnaissant une « likelihood of success on the merits » (des chances sérieuses de l’emporter sur le fond), selon CoinDesk. Aucun des grands vols de cette année n’a frappé un dépositaire régulé ; la meilleure gouvernance reste celle qui évite d’en arriver là.

Foire aux questions

Combien de signataires faut-il pour un multisig ?

Le référentiel SEAL recommande un minimum de trois signataires et un seuil d’au moins 50 %, et sept signataires ou plus dès que le multisig garde l’équivalent de plus d’un million de dollars (environ 850 000 euros). Pour un particulier, un 2-of-3 suffit souvent ; pour une équipe, un 3-of-5 ; pour un gros trésor, un 4-of-7 ou plus. Évitez les schémas N-of-N, où la perte d’une seule clé gèle tout.

Le multisig est-il plus sûr qu’un portefeuille matériel simple ?

Pas automatiquement. Le multisig supprime le point de défaillance unique, mais ajoute de la complexité, donc de nouveaux points de rupture. Le directeur technique de Ledger a mis en garde en 2026 contre l’adoption réflexe du multisig ; pour beaucoup de particuliers, un seul portefeuille matériel bien sauvegardé avec signature claire reste plus sûr, et Miniscript offre un intermédiaire pour les besoins plus avancés.

Qu’est-ce que la signature à l’aveugle et comment l’éviter ?

Signer à l’aveugle, c’est approuver une transaction dont l’appareil ne peut pas afficher le contenu lisible ; c’est le fil commun des plus gros vols multisig, où l’écran montrait une chose et la transaction en signait une autre. On l’évite par la signature claire (clear signing, standard ERC-7730), qui décrit la transaction en langage humain, et en recalculant l’empreinte de la transaction sur un appareil séparé avant d’approuver.

Multisig ou MPC : quelle différence ?

Le multisig fait valider une transaction par plusieurs clés distinctes, avec une logique on-chain transparente et auditable, mais un coût en gaz à chaque changement. Le MPC fragmente une seule clé en parts détenues par plusieurs parties, ce qui est plus souple et confidentiel, mais dépend de l’infrastructure d’un fournisseur, moins vérifiable on-chain. Le choix dépend de qui doit pouvoir vérifier quoi.

Qui est responsable en cas de vol sur le multisig d’un prestataire ?

Si les fonds étaient conservés par un prestataire régulé (un CASP au sens de MiCA, supervisé par l’AMF en France), celui-ci répond de ses contrôles de signature au titre de l’article 75 de MiCA et de DORA, et le client dispose d’un recours réglementaire. En revanche, un utilisateur d’un multisig pleinement décentralisé tombe hors du champ de MiCA : il n’a ni CASP responsable ni régulateur à saisir, et ses propres procédures sont sa seule protection.

Par Anneke de Vries, rédactrice sécurité et exploits, HOGE Wire.