La première question que tout projet sérieux nous pose sur la custody de trésorerie est la même : multi-sig ou MPC ?
La réponse est « ça dépend », mais les variables sont assez concrètes pour que vous puissiez décider sans agiter les mains. Ce qui suit, c'est le cadre que nous utilisons quand nous faisons une mission Wallet Setup.
Ce que chacun désigne
Les wallets multi-signature sont des smart contracts. Ils exigent m sur n signatures de signataires désignés pour exécuter une transaction. L'implémentation la plus utilisée sur les chaînes EVM, c'est Safe. On-chain, le wallet est une adresse de smart contract ; tout le monde voit ses signataires, son seuil et son historique complet.
Les wallets MPC (multi-party computation) utilisent des protocoles cryptographiques pour découper une seule clé en parts détenues par plusieurs parties. Les parts produisent conjointement une signature sans jamais assembler la clé en un seul endroit. On-chain, le wallet est une EOA normale ; personne ne voit comment la signature a été produite.
Ce sont des mécanismes différents avec des modes de défaillance différents. Choisir entre les deux, c'est choisir entre deux modèles de menace différents, pas l'option « plus sûre ».
Là où le multi-sig gagne
Transparence on-chain. Chaque signataire, chaque changement de seuil, chaque transaction est visible on-chain. Auditeurs, communauté, votre futur vous-même peuvent vérifier l'état. Pour une trésorerie de DAO, cette transparence n'est pas négociable.
Features natives smart contract. Modules, contrats de recovery, opérations time-lockées, rôles, simulation de transaction dans le front-end, l'écosystème Safe est mature.
Lisibilité opérationnelle. Un multi-sig 4-sur-7 avec une liste documentée de signataires est plus simple à expliquer à des investisseurs, à des régulateurs et à un tribunal qu'un « schéma MPC à seuil avec 5 parts sur 9 ».
Audité à grande échelle. Safe est le contrat multi-sig le plus utilisé et le plus audité en production. Les vulnérabilités qui touchent les trésoreries Safe ne sont presque jamais dans le contrat, ce sont des erreurs opérationnelles, des UX de signature, ou de l'ingénierie sociale.
Là où le MPC gagne
Chain-agnostique. Le MPC produit une signature normale, ce qui veut dire qu'il marche sur chaque chaîne, Bitcoin, Solana, chaînes Cosmos, chaque L2 EVM. Le multi-sig requiert une chaîne qui supporte les smart contracts, et même là chaque chaîne a sa propre version. Pour les dépositaires qui détiennent des actifs sur plein de chaînes, le MPC est moins coûteux opérationnellement.
Confidentialité de la structure de signature. Le seuil et les signataires ne sont pas visibles on-chain. Pour la custody institutionnelle, c'est parfois une feature.
Rotation sans changer l'adresse. Le rafraîchissement des parts ne change pas l'adresse. Vraiment utile pour les opérations institutionnelles qui distribuent des adresses de dépôt statiques aux clients.
Signing throughput plus élevé. Le MPC signe en sub-seconde ; le multi-sig demande à un quorum de signataires d'interagir avec le contrat dans le temps. Pour les opérations à haute fréquence, le MPC est le seul choix pratique.
Là où les deux échouent
Les modes de défaillance qui ont vraiment drainé des trésoreries :
Signataires sous le même toit. Un multi-sig 5-sur-9 où 6 signataires sont employés de la même société dans le même bureau, c'est en pratique du 1-sur-1. Pareil pour des parts MPC tenues sur des machines du même réseau.
Signature phishée. Les deux schémas supposent que le signataire revoit ce qu'il signe. En pratique, les signataires approuvent des transactions présentées par une UI sans les simuler. Une dApp malicieuse obtient la même signature qu'une légitime.
Devices de signature compromis. Un laptop avec un malware peut présenter une transaction à l'utilisateur et en signer une autre. Les hardware wallets neutralisent ça pour le multi-sig ; les implémentations MPC varient en isolation.
Mauvaise implémentation cryptographique. Les protocoles MPC ont livré de vrais bugs, nonces biaisés, aléa faible, recovery qui contourne les seuils. Les contrats multi-sig ont le même risque en principe, mais l'implémentation dominante (Safe) est éprouvée depuis des années.
Recovery qui contourne le seuil. Les procédures « device perdu » ont souvent une auth plus faible que le seuil lui-même. Un attaquant qui peut prétendre avoir perdu un device peut drainer le wallet par la porte de derrière.
Comment choisir
Trois questions, dans l'ordre :
1. Avez-vous besoin de transparence on-chain ?
Si oui, trésorerie de DAO, admin de protocole public, tout ce où la communauté doit vérifier la gouvernance, le multi-sig gagne. La trace on-chain est la feature.
Si non, custody institutionnelle, wallet opérationnel interne, hot wallet d'exchange, la confidentialité de structure du MPC est acceptable et parfois préférable.
2. Sur combien de chaînes opérez-vous ?
Une chaîne ou un seul écosystème EVM : multi-sig.
Beaucoup de chaînes, dont du non-EVM : MPC. La charge opérationnelle d'opérer plusieurs multi-sigs sur Bitcoin, Solana, Cosmos et EVM est réelle et s'accumule vite.
3. Quelle est votre cadence opérationnelle ?
Lente et délibérée (opérations de trésorerie, gouvernance, gros rebalances) : multi-sig. La friction d'assembler m sur n signataires est une feature, pas un bug.
Rapide et à fort volume (retraits d'exchange, opérations de market-making) : MPC.
Un pattern qui marche
Pour la plupart des projets dans notre expérience, la bonne réponse, c'est les deux :
- Trésorerie froide et admin de protocole : multi-sig, signataires hardware, distribués géographiquement, sur un Safe avec un module de revue de transaction et un timelock 48-72h pour les opérations non-urgentes.
- Hot wallet opérationnel : MPC, avec un cap bas sur le solde non utilisé, des policies programmatiques et un monitoring serré.
La perte de chaque wallet est bornée à ce qu'il détient. Un drain du hot wallet, c'est une mauvaise journée ; l'admin du protocole et la trésorerie sont intacts.
Ce qu'on fait
L'architecture est un livrable écrit. Les runbooks pour « rotation d'une clé compromise », « onboarding d'un nouveau signataire », « pause d'urgence » sont des livrables écrits. La formation des signataires est une session livrée. Rien de tout cela n'est plus sûr que ce que votre équipe peut réellement opérer sous pression, c'est ce que la mission garantit.
Une fois l'architecture en place, Wallet Surveillance garde un œil sur chaque adresse pertinente : transactions en file dans le multi-sig, patterns de signature inhabituels du wallet MPC opérationnel, approvals à des contrats inconnus. Les 30 premières minutes d'un incident, c'est là que la bataille se gagne ou se perd.
Multi-sig vs MPC n'est pas une question religieuse. C'est une question d'architecture avec une réponse défendable pour chaque équipe, une fois qu'on a écrit ce qu'on défend réellement et comment on compte opérer.