Multisig en 2026 : la checklist qui sépare sécurité et illusion

Cet été 2026, le multisig est de nouveau sur la sellette

Depuis la fin juillet 2026, un bogue de génération de clés dans les portefeuilles matériels Coldcard a permis de siphonner plus de 130 millions de dollars en bitcoin, par vagues successives, sans qu’aucun signataire n’ait jamais approuvé quoi que ce soit de malveillant : la faille se trouvait dans la génération de la clé elle-même, pas dans une transaction frauduleuse. Quelques jours plus tard, le directeur technique de Ledger, Charles Guillemet, mettait en garde contre un réflexe qu’il juge dangereux, se précipiter vers un portefeuille multisignature simplement parce qu’un concurrent vient de se faire piéger. Voilà le paradoxe qui ouvre cet article : au moment même où l’actualité semble plaider pour plus de signatures, l’un des dirigeants techniques les plus écoutés du secteur des portefeuilles matériels affirme l’inverse. Ajouter des signataires n’ajoute pas automatiquement de la sécurité, cela ajoute de la complexité, et la complexité mal maîtrisée est elle-même une source de pertes.

Ce débat n’est pas nouveau, mais il arrive à un moment charnière. Depuis le piratage de Bybit en février 2025, plus de deux milliards de dollars cumulés ont été dérobés via des portefeuilles multisignature mal opérés, et non mal conçus sur le plan cryptographique. Doubler ou tripler le nombre de clés ne sert à rien si tous les signataires utilisent le même modèle d’appareil, la même interface, ou signent à l’aveugle des données qu’ils ne comprennent pas vraiment. Cet article fait le point, à partir des cas les mieux documentés de 2025 et 2026, sur ce qui distingue un multisig qui protège réellement d’un multisig qui donne seulement l’illusion de la sécurité.

Multisig, clé unique, MPC : trois logiques de garde à ne pas confondre

Un portefeuille à clé unique repose sur une seule paire de clés cryptographiques : qui détient la clé privée contrôle les fonds, sans intermédiaire. Un portefeuille multisignature (multisig) répartit ce pouvoir entre plusieurs clés indépendantes et exige qu’un nombre minimum d’entre elles, le seuil, noté m sur n, signent une transaction pour qu’elle soit valide. Sur Ethereum et les chaînes compatibles EVM, cette logique est presque toujours mise en œuvre par un contrat intelligent, et Safe (l’ancien Gnosis Safe) en est de très loin l’implémentation dominante. Sur Bitcoin, le multisig existe nativement dans le script de la transaction (P2SH, P2WSH), ou plus récemment via des politiques miniscript qui permettent des combinaisons de conditions plus fines qu’un simple m parmi n.

Le calcul multipartite sécurisé (MPC, multi party computation) répond au même problème par une méthode différente : aucune clé privée complète n’existe jamais à un instant donné. Chaque participant détient un fragment cryptographique, et la signature est calculée conjointement hors chaîne, sans jamais reconstituer la clé entière. Vu de l’extérieur, une transaction MPC ressemble à une signature unique ordinaire, alors qu’un multisig laisse une trace on-chain de chaque signataire ayant approuvé l’opération, une différence détaillée plus loin dans cet article.

Le succès de l’approche multisig se mesure aujourd’hui en échelle : au deuxième trimestre 2026, l’écosystème Safe revendiquait plus de 63 millions de comptes et environ 39,35 milliards de dollars de volume transféré sur l’ensemble des chaînes prises en charge, en hausse de 8 % sur un an, selon le rapport du deuxième trimestre 2026 de la Safe Ecosystem Foundation. C’est devenu l’infrastructure de garde partagée d’une bonne partie de la DeFi, ce qui explique pourquoi chaque piratage impliquant un multisig mal opéré a un tel retentissement.

Le fiasco Coldcard et ce qu’il révèle sur la fausse sécurité

Le bogue affectant les portefeuilles Coldcard du fabricant canadien Coinkite est un cas d’école, même s’il ne concerne pas directement le multisig. Le firmware vérifiait qu’une constante de configuration était définie plutôt que si le générateur matériel de nombres aléatoires était réellement activé, ce qui faisait basculer silencieusement l’appareil vers un générateur logiciel bien plus prévisible. Introduit en mars 2021, le défaut est resté invisible pendant plus de cinq ans.

Une fois exploité fin juillet 2026, les dégâts se sont chiffrés en dizaines puis en centaines de millions : selon TechCrunch, plus de 130 millions de dollars (environ 113 millions d’euros) avaient été siphonnés au 4 août, avec au moins une douzaine de groupes distincts se disputant les adresses encore vulnérables, un chiffre que les analystes s’attendaient à voir encore grimper. Coinkite a suspendu ses expéditions, détruit le stock d’appareils fabriqués avec le firmware fautif, et publié des versions corrigées (4.2.0 pour la Mk3, 5.6.0 pour les Mk4 et Mk5, 1.5.0Q pour la Q). L’avertissement qui accompagne le correctif est crucial : la mise à jour ne répare pas une clé déjà générée avec une entropie faible, seule une migration complète vers une nouvelle phrase de récupération protège les fonds déjà exposés, précise Bitcoin Magazine. Le cofondateur de Coinkite, Rodolfo Novak, connu sous le pseudonyme NVK, a reconnu que « la revue de code assistée par IA peut désormais détecter des bogues latents à une vitesse qui dépasse même les experts les plus chevronnés du secteur ».

Pourquoi évoquer un bogue de clé unique dans un article sur le multisig ? Parce que c’est précisément cet événement qui a relancé le débat. Si même un appareil réputé pour son sérieux, audité, air-gapped, spécialisé Bitcoin, peut générer une clé faible pendant cinq ans sans que personne ne s’en aperçoive, la tentation est grande de répondre par plus de signatures. C’est exactement le raisonnement que Charles Guillemet a choisi de contester publiquement.

La mise en garde de Ledger : plus de signatures n’égale pas plus de sécurité

D’après Cryptonomist, Charles Guillemet a explicitement déconseillé de se précipiter vers un multisig par simple réaction à la mésaventure d’un concurrent. Son argument : complexifier une configuration ajoute des appareils, des phrases de sauvegarde et des étapes de coordination, donc autant de nouveaux points de défaillance ; un multisig mal exécuté peut rendre la récupération des fonds difficile, voire impossible, en cas de perte d’un signataire ou d’erreur de procédure. Pour la majorité des utilisateurs individuels, argumente-t-il, un portefeuille à signature unique correctement sauvegardé, associé à de la clear signing (l’affichage lisible du contenu réel d’une transaction avant signature), reste le choix le plus pratique et le moins sujet à l’erreur humaine. Il met en avant les politiques miniscript et le standard cryptographique MuSig2 comme alternatives permettant des règles de dépense sophistiquées sans la charge opérationnelle complète d’un multisig classique.

Ce point de vue fait écho à une remarque plus ancienne, mais toujours pertinente, de Vitalik Buterin sur les portefeuilles à récupération sociale et multisignature : « Les deux questions clés pour utiliser en toute sécurité un portefeuille multisig ou à récupération sociale sont : premièrement, qui choisissez-vous comme gardiens ; deuxièmement, quelles instructions leur donnez-vous ? », rapporte CryptoSlate. Autrement dit, le nombre de signatures n’est qu’une variable parmi d’autres ; la vraie question est de savoir qui détient ces clés, avec quelles compétences, quelle discipline, et selon quelles instructions. C’est précisément ce que les cas documentés depuis 2025 permettent d’illustrer.

Bybit, WazirX, Radiant, Drift, Humanity Protocol : cinq échecs, une même racine

Aucun des cinq piratages de multisig les plus coûteux de 2025 et 2026 n’a exploité une faille dans les mathématiques du schéma m parmi n lui-même. Tous ont contourné le processus humain qui entoure la signature.

Le 21 février 2025, Bybit a perdu environ 1,5 milliard de dollars (~1,3 milliard d’euros), le plus grand vol de cryptomonnaies jamais enregistré, après qu’un développeur de Safe{Wallet} a vu sa machine compromise. Du code JavaScript malveillant a ensuite modifié l’affichage de la transaction au moment de la signature, laissant les signataires approuver un transfert vers une adresse contrôlée par des pirates tout en croyant valider une opération de routine, selon l’enquête indépendante de Sygnia. Le FBI a attribué l’attaque au groupe nord-coréen Lazarus.

En juillet 2024, WazirX a perdu environ 230 millions de dollars (~200 millions d’euros), près de la moitié de ses réserves, à cause d’un écart entre ce qu’affichait l’interface de son prestataire de garde Liminal Custody et les données réelles de la transaction. Quatre signataires sur six ont approuvé une opération d’apparence anodine dissimulant une charge malveillante, d’après Halborn.

En octobre 2024, Radiant Capital a perdu environ 50 millions de dollars (~43 millions d’euros) : un logiciel malveillant distribué via un faux PDF sur Telegram a compromis les ordinateurs de plusieurs développeurs, faisant apparaître des données légitimes à l’écran pendant qu’une transaction malveillante était signée en arrière-plan, d’après Halborn.

Le 1er avril 2026, Drift Protocol, une plateforme de produits dérivés sur Solana, a perdu environ 285 millions de dollars (~247 millions d’euros) selon TRM Labs, ce qui reste le plus important piratage DeFi de l’année. Les attaquants avaient passé des mois à convaincre des signataires de son Security Council de pré-signer des transactions à nonce durable, une fonctionnalité Solana légitime permettant de signer une fois et d’exécuter plus tard. Le conseil venait de migrer vers un seuil de 2 sur 5 sans aucun délai de sécurité quelques jours avant l’attaque, supprimant la fenêtre de détection qui aurait pu permettre de repérer l’anomalie, rapporte CoinDesk.

Enfin, le 9 juin 2026, Humanity Protocol a perdu environ 36 millions de dollars (~31 millions d’euros) via ses clés d’administration de pont, réparties en 3 sur 6 sur Ethereum et 3 sur 5 sur BNB Chain, deux seuils censés être indépendants. En pratique, plusieurs clés des deux chaînes avaient été sauvegardées sur l’ordinateur portable d’un seul employé, si bien qu’un unique appareil compromis suffisait à franchir les deux seuils simultanément, a reconnu le fondateur Terence Kwok, cité par CoinDesk.

Selon le rapport H1 2026 de TRM Labs, les compromissions d’infrastructure et de clés ne représentent qu’environ 15 % des incidents recensés au premier semestre 2026, sur un total de 207 piratages et un peu moins d’un milliard de dollars dérobés, mais elles concentrent à elles seules environ 76 % de la valeur volée. Le message est clair : les bogues de smart contracts font la une plus souvent, mais ce sont les processus de signature mal gouvernés qui coûtent le plus cher.

Choisir un seuil qui protège vraiment

La Security Alliance, un collectif de chercheurs et de praticiens de la sécurité connu sous le sigle SEAL, recommande un plancher simple dans ses lignes directrices sur les multisig : au minimum trois signataires avec un seuil d’au moins 50 % plus une voix, et au moins sept signataires pour tout multisig détenant plus d’un million de dollars. La recommandation écarte systématiquement le schéma N parmi N, où toutes les clés sans exception doivent signer : il paraît intuitivement plus sûr, mais la perte définitive d’une seule clé bloque irrémédiablement les fonds, exactement le risque de récupération que Charles Guillemet met en avant.

Pour les équipes plus modestes, un schéma 2 sur 3 reste un point de départ raisonnable. Pour une trésorerie ou un protocole gérant des sommes importantes, un 3 sur 5 ou un 4 sur 7 offre une marge contre la perte ou la compromission simultanée de deux clés, sans multiplier excessivement les points de coordination. Un seuil trop bas expose à la compromission d’une minorité de signataires, le scénario Humanity Protocol ; un seuil trop élevé, ou trop proche de N, expose à l’indisponibilité en cas de voyage, de maladie ou de perte de matériel. Entre les deux, il n’existe pas de nombre magique valable pour toutes les organisations, seulement un compromis à documenter explicitement et à revoir à mesure que les sommes en jeu évoluent.

Répartir signataires, matériel et emplacements géographiques

Le nombre de signatures ne veut rien dire si tous les signataires partagent le même point de défaillance. Le fiasco Coldcard l’illustre involontairement bien : un multisig dont tous les signataires auraient utilisé le même modèle d’appareil, sur le même lot de firmware vulnérable, n’aurait offert strictement aucune protection supplémentaire face à ce bogue précis. La recommandation SEAL est donc de diversifier délibérément les marques et modèles de portefeuille matériel entre signataires, de varier les logiciels clients utilisés pour construire et vérifier les transactions, de séparer géographiquement le stockage des sauvegardes de clés, et de confier les clés à des personnes de confiance distinctes plutôt qu’à une seule équipe ou un seul foyer.

SEAL recommande également qu’au moins un signataire soit externe à l’organisation, un tiers indépendant capable de refuser une transaction suspecte sans subir la même pression hiérarchique ou le même piratage de messagerie interne que le reste de l’équipe. C’est aussi la logique qui sous-tend le Security Council d’EigenLayer et d’autres comités multisignatures utilisés dans le restaking, censés répartir le pouvoir d’urgence entre des entités qui n’ont pas toutes intérêt à collaborer entre elles en cas de dérive.

Le blind signing, toujours le maillon faible

Le blind signing, ou signature à l’aveugle, consiste à signer un bloc de données brutes, un hash ou un calldata, sans qu’aucune interface ne traduise ce contenu en une information compréhensible : destinataire, montant, fonction appelée. C’est très exactement le maillon qu’ont exploité Bybit et WazirX : dans les deux cas, l’interface affichait une chose pendant que la transaction réellement soumise à la signature en faisait une autre, sans qu’aucun signataire ne dispose d’un moyen simple de vérifier l’écart.

Le 12 mai 2026, la Fondation Ethereum, à travers sa Trillion Dollar Security Initiative, a repris la direction du chantier de la clear signing initié par Ledger et publié un ensemble coordonné de standards, selon son annonce officielle. L’ERC-7730, encore au statut de brouillon, définit un format JSON permettant de décrire une transaction en langage humain plutôt qu’en données brutes, appuyé sur un registre public partagé. L’ERC-8176 ajoute un cadre d’attestation, construit sur l’Ethereum Attestation Service, qui permet à des auditeurs indépendants de certifier qu’un descripteur correspond bien à la fonction réelle du contrat. L’ERC-8213, enfin, introduit une empreinte courte et reproductible du calldata, qu’un signataire peut recalculer sur un second appareil totalement indépendant pour vérifier que rien n’a été altéré entre l’affichage et la signature. Ledger, MetaMask, Trezor, Fireblocks, WalletConnect et plusieurs autres éditeurs de portefeuilles et cabinets d’audit contribuent à cet effort commun.

En complément, des outils indépendants comme clearsig, développé par le cabinet d’audit Cyfrin, ou le projet communautaire SafeLens permettent de recalculer hors ligne le vrai hash d’une transaction Safe et de le comparer à ce qu’affiche l’interface principale. La règle à retenir est simple à énoncer, plus difficile à appliquer avec discipline : ne jamais signer ce que son appareil ne peut pas afficher en clair, et recalculer le hash de la transaction sur une machine propre et isolée avant d’approuver quoi que ce soit d’inhabituel.

La certification SFC Multisig Ops, une nouvelle référence d’audit

Au-delà des recommandations générales, la Security Alliance a formalisé en 2026 une certification opérationnelle ouverte et détaillée, la SFC Multisig Ops, actuellement en révision 1.1, organisée en six catégories de contrôle.

Cette certification va nettement plus loin qu’une simple liste de bonnes pratiques : elle impose des délais précis, une conservation des journaux d’audit sur trois ans, et des exercices réguliers plutôt qu’une documentation qui prend la poussière. C’est ce type de cadre, vérifiable par un tiers, qui commence à distinguer une organisation qui affirme avoir un multisig sécurisé d’une organisation qui peut réellement le démontrer.

Timelocks, vérification indépendante et communication hors bande

Un délai de sécurité, ou timelock, imposé entre l’approbation d’une transaction et son exécution effective donne un temps de réaction : un signataire, un observateur externe ou un système de surveillance automatisé peut repérer une anomalie et déclencher l’alerte avant que les fonds ne bougent réellement. C’est précisément la protection que le Security Council de Drift Protocol venait de supprimer au moment de son piratage, en migrant vers un seuil 2 sur 5 sans aucun délai associé : sans cette fenêtre, il n’y avait tout simplement rien à observer avant l’exécution.

SEAL recommande également une vérification indépendante sur deux interfaces distinctes avant chaque signature, jamais uniquement celle fournie par un seul prestataire, ainsi que des canaux de communication chiffrés et protégés par authentification multifactorielle entre signataires, avec une révision semestrielle des contacts d’urgence. Ce dernier point compte plus qu’il n’y paraît : plusieurs incidents documentés dans le secteur trouvent leur origine dans un canal de communication usurpé ou compromis, bien avant l’étape de signature elle-même, un signataire recevant une instruction en apparence légitime d’un collègue dont le compte a en réalité été détourné.

Multisig contre MPC : deux philosophies de la confiance

Multisig et calcul multipartite répondent au même besoin, éviter qu’une seule personne ou un seul appareil ne contrôle des fonds, mais reposent sur des philosophies de confiance différentes. Un multisig place sa confiance dans du code on-chain, public, vérifiable par n’importe qui, au prix d’un coût en gas plus élevé et d’une certaine rigidité pour changer de signataires, puisque chaque changement est lui-même une transaction on-chain visible par tous. Le MPC déplace cette confiance vers une infrastructure hors chaîne : les fragments de clés et le calcul de signature dépendent du logiciel et des serveurs du fournisseur choisi, ce qui permet une rotation des participants plus rapide et moins coûteuse, mais qui est intrinsèquement plus difficile à auditer de l’extérieur puisque le processus ne laisse pas la même trace publique.

Aucune des deux approches n’est universellement supérieure. Les grandes plateformes d’échange et les dépositaires institutionnels ont largement adopté le MPC pour sa flexibilité opérationnelle, tandis que les DAO et les trésoreries de protocoles DeFi restent très majoritairement sur du multisig on-chain de type Safe, précisément parce que la transparence publique de chaque signature fait partie de leur promesse de gouvernance envers leur communauté.

Ce que BonkDAO rappelle sur les seuils de gouvernance

Le multisig n’est qu’un cas particulier d’un problème plus général : fixer un seuil d’autorisation et s’assurer qu’il ne peut pas être atteint par surprise. Les organisations autonomes décentralisées affrontent exactement la même question à travers leurs seuils de quorum. L’attaque contre BonkDAO en juillet 2026 en est une illustration frappante : un attaquant a accumulé discrètement une part suffisante de jetons via des portefeuilles d’échange, puis fait adopter une proposition avec une participation extrêmement faible, sans qu’aucun délai de sécurité ne vienne retarder l’exécution du transfert de trésorerie qui a suivi. En remplaçant seuil de vote par seuil de signatures multisig, le mécanisme de défaillance est rigoureusement identique : une autorisation atteinte sans diversité réelle des participants et sans fenêtre de détection.

Cette parenté n’est pas qu’une analogie : de nombreux protocoles utilisent un comité multisignature, souvent baptisé Security Council, pour exercer des pouvoirs d’urgence que la gouvernance on-chain classique serait trop lente à actionner. Les intégrations de restaking Bitcoin comme celle qu’Aave V4 prépare avec Babylon reposent elles aussi, à un moment ou un autre de leur architecture, sur ce type de comité restreint. Le débat sur le bon seuil, la bonne diversité de signataires et le bon délai de sécurité dépasse donc largement le seul cadre du multisig au sens strict.

Le cadre réglementaire en France après la période transitoire MiCA

En France, la période transitoire qui permettait aux prestataires de services sur crypto-actifs enregistrés sous la loi PACTE de continuer à opérer sans agrément MiCA complet s’est achevée le 1er juillet 2026. L’Autorité des marchés financiers a rappelé à plusieurs reprises, la dernière fois début février 2026, que les acteurs incapables d’obtenir leur agrément à temps devaient préparer une sortie ordonnée du marché français, d’après l’AMF.

Pour un prestataire de services sur crypto-actifs qui conserve les fonds de ses clients dans un multisig, cette échéance n’est pas une formalité abstraite : ses contrôles de signature deviennent un sujet directement opposable au régulateur, dans le cadre du régime de responsabilité de l’article 75 de MiCA et des exigences de résilience opérationnelle du règlement DORA. En cas de défaillance de ses procédures de garde, y compris une mauvaise configuration de multisig, un prestataire agréé engage sa responsabilité et son autorisation elle-même. C’est précisément la question que pose cet article de HOGE Wire sur qui paie réellement lorsqu’un piratage survient : la réponse dépend largement du statut réglementaire de l’entité qui détenait les clés.

À l’inverse, un multisig utilisé pour de l’autoconservation véritablement décentralisée, une trésorerie de DAO ou un portefeuille personnel qui ne dépend d’aucun prestataire enregistré, échappe entièrement au champ de MiCA. Aucun régulateur ne viendra dédommager les victimes ni sanctionner une mauvaise configuration ; la discipline opérationnelle décrite dans cet article devient alors la seule ligne de défense, sans filet réglementaire derrière elle.

Plan de reprise : anticiper la perte ou la compromission d’un signataire

Même un multisig correctement configuré doit prévoir ce qui se passe quand un signataire disparaît, perd l’accès à son appareil, ou devient lui-même suspect. La certification SFC impose un délai de 48 à 72 heures pour retirer les droits d’un signataire en cas de procédure d’urgence, des tests de joignabilité trimestriels pour vérifier que chaque signataire répond bien dans les temps, et des exercices de simulation annuels plutôt qu’un document jamais testé en conditions réelles.

Cette discipline rejoint une préoccupation plus large du secteur pour se doter de filets financiers face aux défaillances opérationnelles. La course à l’assurance décrite à propos du slashing en cascade sur les protocoles de restaking illustre la même logique appliquée à un risque différent : accepter qu’aucun contrôle préventif n’est infaillible à 100 %, et donc budgétiser aussi la réponse à l’incident et, si possible, une couverture financière partielle. Le marché de l’assurance spécifiquement dédiée aux échecs opérationnels de multisig reste embryonnaire en 2026, mais la direction est la même : gouvernance préventive d’un côté, capacité de réponse et de compensation de l’autre.

Un plan de reprise écrit doit répondre à des questions précises avant qu’une crise ne survienne.

• Qui a l’autorité pour déclencher une rotation d’urgence des clés
• Quel est le délai maximal toléré avant qu’un signataire injoignable soit considéré comme compromis
• Quelles preuves suffisent pour geler une transaction en attente plutôt que de la laisser s’exécuter par défaut

Ce sont des décisions bien plus faciles à prendre à froid, avant l’incident, qu’au milieu d’une compromission en cours.

Foire aux questions

Qu’est-ce qu’un portefeuille multisig et comment fonctionne-t-il ?

Un portefeuille multisig exige que plusieurs clés privées indépendantes, détenues par des personnes ou des appareils différents, signent une transaction avant qu’elle ne soit valide. On le note généralement m sur n, où m est le nombre minimum de signatures requises et n le nombre total de signataires autorisés. Sur les chaînes compatibles Ethereum, cette logique est le plus souvent mise en œuvre par un contrat intelligent comme Safe. Sur Bitcoin, elle existe nativement dans le script de la transaction.

Combien de signataires faut-il pour sécuriser un multisig ?

Il n’existe pas de nombre universel, mais la Security Alliance recommande un minimum de trois signataires avec un seuil d’au moins 50 % plus une voix, et au moins sept signataires pour tout multisig détenant plus d’un million de dollars. Un schéma 2 sur 3 convient à une petite équipe, tandis qu’un 3 sur 5 ou un 4 sur 7 est plus adapté à une trésorerie importante. Le schéma N parmi N, où toutes les clés sans exception doivent signer, est généralement déconseillé car la perte d’une seule clé bloque définitivement les fonds.

Le multisig est-il plus sûr qu’un portefeuille à clé unique ?

Pas automatiquement. Le multisig réduit le risque qu’un seul appareil ou une seule personne compromise entraîne la perte totale des fonds, mais il ajoute de la complexité opérationnelle : plus de signataires signifie plus de canaux de communication, plus d’appareils à sécuriser et plus d’occasions de mal configurer le système. Plusieurs des plus gros piratages de multisig, dont Bybit, WazirX et Humanity Protocol, n’ont pas exploité une faiblesse cryptographique mais un défaut de processus humain ou de diversification.

Qu’est-ce que le blind signing et pourquoi est-il dangereux ?

Le blind signing désigne le fait de signer des données de transaction brutes, un hash ou un calldata, sans qu’aucune interface ne les traduise en termes compréhensibles comme le destinataire réel, le montant ou la fonction appelée. C’est le mécanisme exploité lors des piratages de Bybit et WazirX, où l’interface affichait une opération anodine pendant qu’une transaction différente était réellement soumise à la signature. Le standard émergent de clear signing, notamment l’ERC-7730, vise à éliminer ce risque en imposant un affichage lisible et vérifiable du contenu réel de chaque transaction.

Le multisig est-il obligatoire ou réglementé en France ?

Non, MiCA n’impose pas explicitement l’usage d’un multisig. En revanche, depuis la fin de la période transitoire le 1er juillet 2026, tout prestataire de services sur crypto-actifs opérant en France doit être agréé par l’AMF et répond de ses procédures de garde des clients, y compris de la configuration de ses multisig, dans le cadre du régime de responsabilité de MiCA et des exigences de résilience opérationnelle de DORA. Un multisig d’autoconservation personnelle ou de DAO totalement décentralisée reste en dehors de ce cadre réglementaire.

Par Camille Aubert, rédaction HOGE Wire.